What is Reddit's opinion of
Sciter?
From 3.5 billion Reddit comments
➔ Sciter website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
Just for the note...
10 or so years ago I did an experiment of creating standalone JavaVM bundled with basic graphics and UI primitives.
So final GUI executable contains that JVM (80kb) plus bundled .class files combined together into single exe file without external dependencies. The whole project was quite promising until Sun-MS Java wars, sigh.
More on that story: https://sciter.com/10-years-road-to-sciter/
First, if you statically link against musl, you have to do that for all your dependencies, which prevents things like:
- Using Rust to write
cdyliblibraries that can be loaded by other things on the system. (eg. GStreamer plugins, Python/Ruby/Node.js/etc. extensions, etc.) - Sharing the system versions of huge and/or hard-to-bundle dynamic library dependencies like Qt and the user's selected Qt theme. (Yes, like in GTK+ 2.x, Qt themes are dynamic libraries... and do the libre releases of Qt even support static linking? I think I heard somewhere that they didn't.)
- Using things that are only offered as glibc-built dynamic libraries, like the free version of Sciter.
It's basically the same situation as using the MinGW builds of Rust on Windows that way.
Second, apparently musl's allocator has major flaws in multi-threaded situations.
Not open source and most likely has a shit-ton of incompatibilities when compared to browsers (the Monaco editor has to work on the web as well) - is there a list of what it supports (something like https://caniuse.com) somewhere?
I would also be skeptical of its drawing and JS performance, given how much work went into those things in major browsers. Benchmark links welcome.
EDIT: So after googling a bit, web compatibility doesn't even seem to be a goal of the project. Even the home page says it only supports "JS-like scripts", so it's really just a desktop UI framework that you have to target individually, with no aspirations of using the existing JS ecosystem or sharing any code between desktop and the web.
There are tools what follows this approach more closely. For instance Sciter, which don't offer the entire browser, but only the HTML/CSS rendering with DOM and scripting on top. The download and memory usage is smaller. Because it is not open source and you have to also write some C++ some organisations might not find it viable.
The article misses one and probably the main reason of GC existence: memory management in systems with complex ownership graphs that may include loops. Especially in dynamic systems when that ownership graph cannot be defined upfront.
Neither Rust (static analysis) nor reference counting (RC) approaches can really help in these cases. Check Why Writing a Linked List in (safe) Rust is So Damned Hard
Ownership problem is especially tough in UI use cases where ownership graph may be even unknown upfront.
As of practical solution...
The very first attempt to create my Sciter was made in D. Early tests showed that "GC everywhere" approach used by D leads to far from optimal results - even harmful I would say.
Sciter has DOM implementation that has regular and strict parent-children ownership graph of relatively small and static objects. GC is not needed to manage such constructs - RC is perfectly adequate for that.
Parsers allocate a lot of temporary objects - memory pools and stack allocated memory (as a generalization of memory pool idea) suit them perfectly well.
And only script, as a language behind UI, is GCable to enable use of callbacks of first class functions - closures.
So ideal solution is, as always, in between of two poles - in hybrid systems. Ideal practical language shall support two paradigms natively: as explicit memory management (RC) as to naturally allow GC approach on selected domain of objects.
Voice from trenches of practical programming.
As an author of Sciter Engine (embeddable HTML/CSS/JS engine that implements good chunk of browser functionality) I think I can qualify to answer on this question.
HTML/DOM/CSS/JS is relatively easy thing to do. I did it by myself after all.
The complexity problem had arisen when "the company" that is built on providing services/business over internet decided to compete with OS vendors. So they need close to native performance in browser in order e.g. Docs to compete with Word/Excel.
Initially, at Netscape and IE4 times, browsers were dead simple.
The performance and extensibility problems there were solved by using <applet>s. And as it appears now that was right thing to do - compact and relatively stable core with extensibility-on-demand mechanism to add functionality when you need performance or something special / non-existent in browsers.
But for various esoteric reasons <applet>s did not go through. And so we've ended in current situation:
Simple JavaScript VM implementation (around 400k) needs to be now 40M because of JIT to make absolutely weird things like compiling C++ code to JS to JIT to achieve some performance (emscripten). You will need WebRTC as part of browser, WebGL/WebGPU, SQLite, etc. All these can be done by <applet> extensibility mechanism - delivered only when and where needed. Far not all of us and sites/applications need all these features.
So we've ended up in single almighty blink that de facto defines Web client specification.
Possible solution: to return to HTML Basics specification + make better WebAssembly (for <applet>/<object> extensibility) that is better interfaceable with host JS and DOM. In principle I can provide Sciter as jumpstart of this. It is 5~6 Mb now so is manageable.
Speaking about HTML/CSS in desktop UI ...
Sciter Engine is a dll of about 3.9mb. It includes ( https://sciter.com/developers/engine-architecture/ ) :
- Core HTML/CSS handling (HTML5, CSS2.1 with some CSS3 modules);
- Graphics backend (On Windows: Direct2D and GDI+ or Skia);
- Script compiler and VM (tiscript) - 0.5mb;
- Scriptable DOM implementation - 0.5mb;
- Desktop UI specific features like "HTML windows" and "windowed popup DOM elements".
So in principle it is possible to make something like electron.dll that will weight 5-6mb and use conventional JS (V8 or Chackra). It will use compatible DOM implementation so things like jQuery,etc will run out of the box.
Is this interesting at all?
No, that simply means that I know the price of CSS filter property.
Check my article here: https://sciter.com/sciter-4-2-support-of-acrylic-theming/
To support that I've added :theme(dark) and :theme(light) CSS selectors so single document may have dark and light UI islands as on this UI: https://notes.sciter.com/.
I wouldn't say that 8 MB compressed is ultralight.
Just for the comparison, Sciter Engine that includes:
- HTML/SVG/CSS rendering engine;
- Script VM and compiler;
- Built-in NoSQL database;
- Desktop/windows support;
- WYSIWYG HTML editor;
- HTML printer and print preview;
has binaries of these sizes (non-compressed, sic!):
- Windows: DirectX/Direct2D + GDI+ gfx backends: 4.9 Mb;
- Windows: DirectX/Direct2D + Skia/OpenGL backends: 7.2 Mb;
- MacOS: Skia/OpenGL + CoreGraphics backends: 11.7 Mb;
- Linux/GTK: Cairo/GLIB backend: 10.1 Mb;
- Linux/ARM and Android: Skia/OpenGL + 12.2 Mb;
DirectX and OpenGL backends are H/W accelerated - rendering is done by sending batch commands to GPU.
I used to have pure html/css renderer without other stuff (HTMLayout who remembers it) that had binary less than 1Mb.
Here are couple thoughts from the browser's dev trenches.
Let's agree that HTML 3.2 + CSS 2.2 (+ some layout modules of CSS3) + ES5 are quite adequate for 98% modern web sites.
Executable that implements all this can be of 10 Mb max. And originally browsers were of that size.
Problem is in the rest 2% of use cases.
Originally, when those of us who needed functionality of those 2%, we used plugins in form of ActiveX, <applet>, NPAPI components. These native modules were pluggable/downloadable. This kind of modularization was quite good (modulo security issues) - it allowed to keep spec clean and so to have compact and manageable implementations.
For the note: 10 years ago, web standard to be accepted as a recommendation of W3C, should have 3 (three) independent feature implementations.
Not anymore. With the honest respect to Google Chrome developers Chrome code base is de facto live specification of Web technologies. The spec now is C++ code of particular browser but not what is written on W3C walls. That is bad.
Problem is that to get those 2% we need to move good portion of OS functionality under Web browser umbrella. Just in case.
No surprise, zipped Chromium code base is of 1.5 Gb right now. For the comparison: Linux kernel is 0.22 Gb and zipped sources of my Sciter are of 0.023 Gb (23 Mb - Sciter reuses OS services as much as possible).
Resume: Web browser used to be so called "thin client" on top of OS... And here we go, now an OS is a thin layer for launching the Chrome
Hmm... it seems that I really need to consider Open Source'ing my Sciter. Sciter uses H/W accelerated rendering on Win/Mac/Lin ...
Yet it can be used as for high-level UI declarations as for low-level immediate mode graphics rendering.
Yet it can be integrated into pretty much anything, like Sciter in Unreal Engine for example.
> In this release, the minimum supported Windows version is bumped from 7+ to 8.1+, following the extended support lifecycle of Microsoft.
I am not sure I understand why language, even its runtime, shall follow these lifecycles ... What is so special you need from Windows that Zig will need exactly W8.1?
Just in case, in Sciter I've fixed recently Windows XP and Windows Server 2003 compatibility issues that were requested by customers. This stuff still works. You'd be surprised how many Windows XP Embedded systems are out there. Each passenger train car traversing Europe have at least one, how many in total?
So why limit yourself?
Is there such thing as embeddable Dart VM ?
This https://github.com/google/embed-dart-vm is 6 years old.
Thinking about adding Dart to my Sciter as these combined can be more useable than Flutter ( that repeats same mistakes as WPF, IMO )
> i think sciter is a thing actual programs use, which is nice. however, we need not only the sciter sdk installed and available, but also GTK+, and god damn i do not want to do that.
Only for Linux. From the readme:
- Direct2D/DirectWrite graphics backend (Windows);
- GDI+ graphics backend (Windows);
- CoreGraphics backend (Mac OS X);
- Cairo backend (GTK on all Linux platforms);
- Skia/OpenGL backend (all platforms)
More information on https://sciter.com/developers/engine-architecture/
Basically, it's a HTML/CSS (yet natively looking) GUI with a really compact runtime.
Sciter's author here...
Speaking about note taking app. Just recently I've added Sciter Notes as technology demo to the SDK: https://sciter.com/sciter-notes/
When running it takes 40-50 mb and distribution size : notes.exe + sciter.dll is 1.8mb - nothing these days - times less than comparable web page / web application.
Data (notes) is stored locally in file system - Sciter has built-in persistence (adds 40kb to the DLL, can be excluded) that is comparable with MongoDB by feature set but it uses normal script objects (Object,Array,etc.) for data access.
That's why it takes less than 100ms for Sciter notes to start.
Sciter Notes sources are here: https://github.com/c-smile/sciter-sdk/tree/master/notes where /res/ folder contains whole UI (html/css/scripts). Binaries are also in SDK , in /bin/ subfolder.
Browser is not suitable for running UI of desktop applications for the simple reason: main goal of the browser is to provide safe environment for browsing. Rendering stuff on the screen is also a main goal but only after the first one.
The security goal implies that browser uses sub-optimal mechanism of UI rendering - UI is forced to run in separate process - isolated secured sandbox.
So de-facto even supposed to be small "Hello world" is actually a full blown client-server application where one process (server) contains string "<body>Hello world</body>" and other process (client) renders it. This implies need of marshalling data between these two - so you have subset of HTTP between them anyway.
That's why I did my Sciter Engine ( https://sciter.com ) - it just does HTML/CSS UI in process and takes almost nothing for that (4-5mb dll without external dependencies).
Title is misleading.
"... vs HTML5 implementation in one particular browser on Embedded".
Here is HTML/CSS/script engine running on standard Raspberry Pi 2 with 60FPS full screen (1024x768): https://sciter.com/sciter-on-raspberry-pi-2/
Graphics backend: Skia with OpenGL.
>Yes but that should not be a business of CSS. It is rather a runtime functionality.
According to CSS specifications, it actually is the business of CSS. The specs define everything you need for the total number of pages, cross references, PDF bookmarks, crop marks, and more. Not having these features in major browsers doesn't mean that they don't exist: they are implemented in rendering engines dedicated to print, like WeasyPrint or Prince, and they work well.
>Like in my Sciter printing involves two documents: page-template and the document itself.
Interesting, I'll check this!
Just in case, here is another German team that created their UI with Sciter : https://sciter.com/sciters-industrial-ui-with-german-quality/ By just one UI developer (from Germany). But CSS styling was outsourced to some design shop.
If you haven't written any WYSIWYG editors then that may sound crazy to you, indeed. I did, at least four different editors (last one that is coming: https://sciter.com/sciter-notes-revision-5312-progress-report/) so have an idea of what is going on inside.
> You'd want something like a model as a source of truth, which the DOM then automatically reflects as changes come in.
That automatic reflection is the last thing you would need in editor code, trust me.
> appears to perform that computation on the GPU
and ClearType too or just grayscale AA?
DirectWrite is pretty good with font rendering https://sciter.com/images/sciter-text.png ( that's DirectWrite output in Sciter) so is my question above.
There are two distinct groups of UIs in Windows distribution.
- "Windowed UI" (loose name) group.
These are UIs based on CreateDialog and resource templates. Resource template is binary version of HTML I would say. It is language/format to define window tree (a.k.a. DOM tree) structure and its layout (fixed, nailed down to dialog units but still).
- "Windowless UI" (another loose name) group.
This group represent as modern UI efforts like UWP as remnants of previous attempts like DirectUI, WPF, etc.
First group is in Windows from the very beginning and will work as soon as Windows APIs like CreateWindow, CreateDialog will work. Those UIs are battle tested and I don't think they will be replaced (if it makes sense at all).
Main problem of pretty much all Windows UIs efforts is that they do not obey separation of concerns principle. Ideally it should be a mechanism that allows to define style and layout separately from application code. This would allow to maintain consistent UI with lot less efforts. In Windows XP they made an attempt to implement that by introducing uxtheme.dll but that just about mostly color schemes - layout was left in hands of particular application and applet.
In principle it is possible to modernize CreateDialog template handling so it will use some sort of CSS but I have no idea why Microsoft is not doing that.
For the illustration, here is history-in-screenshots of Norton 360 application in last 15 years. It is transitioned from Skeumorphism of Windows XP to flat UIs of Windows 10. By mostly changing CSS declarations.
Hmm...
As far as I remember we did first production ready EverNote version (v 2.0) in 9 months.
Here is the story.
First EverNote version (v.1.0) was just MFC-based sketch: MS RichText as notes renderer/editor. File based storage, etc.
And EverNote v.2 (the one that went viral) was full rewrite (in those 9 months):
- Local data storage + sync with server (optional);
- my HTMEditor, that later become Sciter, for notes rendering and editing;
- OCR engine by Paragraph;
All that in barebone C++.
At some point it was attempt to use WPF/C# for it (v 3.5 AFAIR). Year of dev time wasted. Shipped 5 months only.
IMHO: Too much time wasted in permanent search for technological silver bullet while core set of features really stayed the same as in v2.0 ...
Wearing my Sciter's author hat and with full respect to Qt craftsmen...
Qt's motivation is understandable from "we all need to pay our bills" point of view. OpenSource does not offer any help to pure software product companies - the ones that are focused merely on their products and nothing else. There is no Open Source Community Bank or something like this that might finance socially valuable software projects. And/or no Communism, yet.
Ah, OK.
Yet, I've found that using "inverted NaN" is more convenient in many cases.
With inverted NaN double value is stored as uint64 = ~float64 - all bits of double value inverted.
In this case 0ull value can be used as "nothing" value - non-initialized thing. So you can use calloc's, memset(0), etc. Simplifies code in many places of Sciter script.
Check this for example: https://docs.flutter.io/flutter/widgets/Padding-class.html And now think about two devices with different screens and so layouts of your app - in one you will need those paddings - in other paddings are not needed. In Flutter you will need to change code to add different representations of the same UI.
With Sciter we are using different paradigm:
markup (superset of HTML5) defines big picture and semantic of UI. Among others accessibility layer consumes this data directly.
Styles (superset of CSS), as a separate set of declarations, style that markup (DOM), UI layout and its changing state.
Script (language behind UI) reacts on events and changes state of the DOM - normally it has nothing with UI styles.
Such separation allows this application for example to survive 10 years pretty much intact (modulo style changes).
Sciter is not a browser. It is embeddable HTML/CSS/script engine designed specifically for desktop UI development. While it's script is quite close to JS it is not JS. Check : https://www.codeproject.com/Articles/33662/TIScript-Language-A-Gentle-Extension-of-JavaScript
As of PWAs...
Norton Antivirus exists as PWA more than 10 years already. Symantec started using it in 2006. This UI is HTML/CSS all these years and styles:
https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-one-application/
I'm going to be "that person" and say that you really shouldn't use HTML+CSS for a native GUI. Including an entire Chromium rendering engine adds quite a bit of bloat to your app.
Based on your requirements, I'd say Sciter might be great. It's a GUI library that uses a subset, slightly modified version of HTML and CSS along with a JavaScript dialect (TIScript). There are Python bindings available. In addition to being far lighter, it's also incredibly flexible and easier to use than manually building a REST API.
> disallowing commercial distribution without purchasing a commercial license.
What's the point then of the first part of your conclusion (... allowing a more permissive open source non-commercial use) ?
Why it should be open source at all?
I am not trying to make fun of it, just considering options for my Sciter Engine
I mean that nothing prevents HTML to be rendered in the same way as QML or whatever. Here is an example of HTML rendering inside DirectX pipeline (in this case the engine uses Direct2D primitives): https://sciter.com/sciter-and-directx/ - that's on desktop and 300+ FPS ...
That precisely what my Sciter is - separate embeddable HTML/CSS library for desktop UIs. Single dll/dylib/so of 4-8mb without any dependencies. Yet it already has Rust bindings: https://github.com/sciter-sdk/rust-sciter
Just in case, this year I am celebrating 10 years of Sciter in production.
I don't think that "flowing" is a correct word here. Semantic - yes, defines meaning and so accessible.
HTML is "not a GUI language" but "GUI structure language". CSS does the rest. Modern CSS (and especially CSS in Sciter) is more powerful than XAML.
"You don't need paragraphs and bulleted lists in a GUI."
Check this: https://sciter.com/wp-content/uploads/2017/07/snotes.png , everything there is HTML - façade UI and notes content. Do you see paragraphs and lists there?
GTK - uses CSS : https://developer.gnome.org/gtk3/stable/chap-css-overview.html Qt - uses CSS alike constructs: http://doc.qt.io/qt-4.8/stylesheet.html, not cascading but better they should. Swing - nobody cares.
> The styles used in syntax highlighting do not usually cascade or involve inheritance.
They do. String literal in markup, string literal in <script> section and so on. CSS and script islands should have distinct style systems: https://sciter.com/wp-content/uploads/2015/08/colorizer.png
All modern UI systems have some markup and styling in one form or another. Qt Quick, GTK, WPF/XAML - why not to use unified markup and styling mechanism?
At the end HTML UI is different from just UI by only existence of HTML parser. HTML parsing is nothing if to compare with UI rendering per se on GPU.
Just in case Sciter Engine ( https://sciter.com , HTML/CSS/script engine, de facto full blown browser) is a project of single person who started programming with FORTRAN, punchcards, etc. in university.
Sciter is a multi-discipline project: parsers, layout algorithms, graphics, bytecode virtual machines, GC, etc. so to create something like this you need quite a lot of experience in different areas so it is not for average junior or even senior programmers.
Quite interesting consequence: single person design allowed to make Sciter compact (5mb dll versus 140mb of Electron) - a lot of code is shared between different parts: like script and DOM are using common i18n primitives (otherwise split between V8 and WebKit) and so on.
There are quite few developers around who know Web UI (frontend programming) with that depth of knowledge of the technology. So not a surprise to see those resource greedy web monsters as we do.
Sciter has built-in support for so called virtual lists and tables.
See illustration.
As it is HTML/CSS then content of cells may have arbitrary content and can be arbitrary styled including text-overflow:ellipsis and text-overflow:path-ellipsis
At work we use Rust for low-level access to Windows APIs (we wanted more control than with C#, but without the pain of C or C++). It works decently well for everything from low-level Windows API tricks, over GUI (ok, we are cheating and using Sciter bindings) up to the server side.
Some packages are a pain to get running (like randomly requiring perl); some frustration, installing stuff with chocolatey and occasional PRs are the norm especially for web stuff. But most things are pretty smooth sailing.
The most exciting windows project I'm following is /u/ColinFinck's NTFS implementation. It's exciting for what it's doing, and exciting for the kinds of GUIs and tools that can be built on top of it
Just for the comparison:
FreeConferenceCall is video/audio/chat/phone/screensharing conferencing application. It supports meetings with up to 1000 participants.
Some facts:
It is native portable application - monolithic executable of 22 Mb in size without external dependencies.
UI uses my Sciter engine (HTML/CSS/JS) with native bridge to WebRTC, Voip, etc.
UI Architecture: Sciter's built-in Reactor that is native version of ReactJS.
- RAM consumption while running 12 input video streams: 110 Mb; - CPU load 3-5 % ("measured on my machine"); - GPU load - 7% ("measured on my machine");
I think that my Storage implementation that is built-in into JavaScript in QuickJS and Sciter is still unbeatable as an integrated JS Storage solution:
const storage = Storage.open("...");
if(!storage.root) { // these will be stored on disk: storage.root.list = [1,2,3]; // stored array storage.root.map = { foo: 1, bar: 2 }; // stored map storage.root.index = storage.createIndex("date",false); // index date -> value, non-unique keys. }
Idea is that every object/value reachable from storage.root a) is persistent on disk and b) is ordinary JS object.
Data manipulations in storage is made by plain JS means, so this can be used in libs like ReactRJ directly.
Electron is not the best option to integrate with native code to be honest.
I'd suggest Sciter that was specifically designed to be integrated with native code.
Custom native objects like this are directly callable from JS - without marshalling between different processes.
Also you can pass to and use in JS raw C functions as they are.
>Sciter, Sciter Lite and Sciter Quark all support Linux. Quark is something else entirely: it's for packaging a pure HTML+Javascript application together with the Sciter engine. That's useful in many cases, but you can't write your application logic in Rust (or anything else but Javascript).
I don't think that's correct. From what I understand the only difference between Scitter.JS (aka Quark) and Sciter is that the custom scripting language in Sciter was replaced with JavaScript (using Fabrice Bellard's QuickJS interpreter).
You can call your Rust functions from JavaScript, for example, someone in the forums asked about doing this: https://sciter.com/forums/topic/cannot-call-rust-function-from-sciter-js/
Regarding Sciter.Lite - yeah, you are correct.. it really does have issues.
In Sciter you can do
:root { var(color): green; } div { color: var(color); } @media screen and (max-width: 768px) { :root { var(color): red } }
so that weird -- are not needed.
And here is Sciter based Teams application (HTML/CSS/JS): https://sciter.com/25-video-streams-with-frame-rate-30-each-in-sciter/
On the screenshot it shows 25 video streams simultaneously, numbers:
- CPU consumption ~ 7% of four cores;
- Memory ~120 Mb
Stay tuned.
Sciter uses its own HTML/CSS implementation that I did by myself.
As of dev tools...
Sciter.dll does not include devtools as does ElectronJS/Chrome - absolutely no need for that on end user side (why do we all need to pay by bandwidth for devtools in VS Code for example? No one uses it there).
Instead sciter.dll and scapp.exe (standalone exe form of sciter) contain very small debugging peer that allows to communicate with inspector.exe.
Inspector allows to inspect DOM, files, see console output, and script debugger, see: https://sciter.com/sciter-js-inspector-debugger-preactjs/
> established choice
Just in case, Sciter (circa 2006) was established long before ElectronJS (circa 2013).
Norton Antivirus for example is using Sciter for its UI since 2007. Norton AV alone has 150 mln or so installations. And they are not changing architecture of their applications since then. All 15 years it is HTML/CSS UI adjusting to follow modern trends.
Depends on project, configuration and willingness to configure it properly.
It takes 55 seconds on my pretty average machine to do full rebuild of my Sciter - HTML/CSS/script engine. This time is spent to compile following modules: tool, uv, dybase, gool, zlib, png, jpeg, webp, rlottie, htmlcss, svg, xdomjs, quickjs, d2d. scapp that constitute Sciter.JS.
VS debugging is the best (features and speed) among: VS, XCode and CodeBlocks. Haven't tried CLion because of their highly controversial decision to use CMake as a project definition language (that was designed for the opposite task).
I am generating projects for these IDEs and make system by Premake5, which is conceptually better than CMake as premake is Lua - full , complete language with normally extendable runtime. While CMake is not clear what: it is neither declarative as make files nor a language (in "programming language" sense).
> Windows is a horrible environment to develop in
I have quite contrary experience.
I am developing Sciter for various platforms. Windows, MacOS, Linux and others.
Windows is my primary development platform. For many reasons. Especially in and for GUI development when you deal not just with linear command line style code but with event handlers and other highly async stuff.
We all should agree that Visual Studio is the best IDE ( combination of editor + debugger ) around especially considering its performance. In fact many Open Source projects are done primarily in VS with secondary Linux ports.
The worst dev platform is MacOS, at least for me personally. XCode is too slow and not that native dev friendly. And unfortunately for some GUI dev tasks it is unavoidable.
> the next wave of desktop development ...
For that matter Sciter appeared long before ElectronJS.
First version of Norton Antivirus with Sciter UI on board appeared in 2007 - so it is 14 years old so far. And ElectronJS is 7 years old.
For anyone interested in clarification on this point, yes it's closed source, but appears to be free (even for commercial use) under the following condition:
> Your application shall include link to Terra Informatica site in "About" dialog or similar place in your application.
Here are the pricing plans.
gool is just a set abstract classes :
namespace gool { class graphics { virtual void fill(argb c, const rect &dst) = 0; virtual void fill(argb c, const rect &dst, const size &radius) = 0; virtual void fill(argb c, const path *dst) = 0; virtual void fill(image *img, const path *dst) = 0; virtual void fill(const brush *lb, const rect &dst) = 0; ... };
And there concrete implementations for the mentioned backends.
So, if needed, other backends can be added there. For example I used to have JUCE backend.
As of directx ... current Direct2D works on top of DirectX just fine. OpenGL is also supported over Skia. Vulkan is planned, I need to use another backend with recent Skia that supports it. For now I am using last Skia version that supported GDI because of cases like this.
Steps in right direction but there are problems.
The whole setup requires upfront script declarations:
handleEntryPoints([ { els: '.flexy-container', load: () => import('./flexy'), }, ])
Yet it is based on one time DOMContentLoaded event. What if content will be modified later?
All this really shall be a business of CSS as in Sciter where you can define all this on CSS level:
.flexy-container { prototype: FlexyClass url(flexy.js); color: red; ... }
the above will load flex.js, a) issue Object.setPrototypeOf(element,FlexyClass) and b) call FlexyClass.attached() (a.k.a. "didMount" ) on it.
So no matter how and when the element matching the selector will appear in the DOM it will have that class assigned to it. Easy, no?
Looking on tuples: https://rescript-lang.org/docs/manual/latest/tuple
And do not see how they conceptually different from arrays (modulo immutability).
If to compare ReScript::tuple and SciterScript::tuple from script used in Sciter then there is a small but principal difference: tuples in Sciter are tagged (Tuple.tag).
This alone allows to express many HTML and CSS constructs in script aimed to be a language behind HTML/CSS UI.
For example "functions" in CSS are in fact named tuples, so this CSS:
{
color: rgb(255,0,0);
}
is represented in script as:
{ color: [rgb:255,0,0]; }
I mean that ReScript::tuple, in it's current form, does not provide any principal benefits over JS::array's so their purpose is not exactly clear.
No, you can use it with native apps too. SpaceX used javascript to code the interface of dragon 2. So many antivirus providers used javascript/html and css for their pretty interfaces. Some game developers does that too.
I was in your exact position searching for cool GUI library for c++ and I found this library called https://sciter.com/ that's allow you to use web technologies with native apps. So many products use this library but the most prominent are Eset security/node32, Norton 360, Avast, Comodo antivirus use this library for their UI.
That HTML/CSS/script based animation runs at standard 120 FPS under Unreal.
On Windows Sciter uses DirectX/Direct2D and so output is as fast as Unreal itself.
In fact things like kinetic scrolling in standalone Sciter run as animation at VSYNC rate (usually it is 60 FPS). You can try that in e.g. usciter.exe -> help browser.
Yet, it is technically possible I think to configure Sciter to use native Unreal rendering primitives instead of Direct2D , but that needs some time.
> Can it be used with the free Sciter license/binary?
Yes.
Does this script language have good IDE support (VS Code, IntelliJ)? If not, what should be used? Also, do you recommend using https://sciter.com/docs/content/script/language/ssx.htm (JSX-equivalent) or plain script?
I've been a huge proponent for a browser layer for normal native development purposes. Of course there are downsides, but it's enormously powerful and has proven to be more ergonomic and portable than many of the native solutions.
With web assembly (& GL) and smart design, every operating system could have an interface so developers can truly write once and run everywhere. That gives us built-in security through sandboxing (with explicit break-outs), extremely convenient installation, etc. The introduction of supporting hardware would also make a big improvement.
And this isn't a call for the death of native development, to be clear. There are clearly many tasks more suited to such development.
Sciter has been an interesting, and from what I can tell successful, experiment in this model well before Electron was conceived. Though I'm not sure how well it has held up in the last couple of years relative to Electron and the larger standards.
> Anything CSS selectors can do you simply implement via property bindings ...
Why do you need that binding in this case: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-one-application/ ?
Again, CSS is one of the best things that Web as a platform brought to UI development. If used appropriately of course.
HTML/XML defines UI structure and semantic (Section 508 is here too).
Code-behind-UI handles events and modifies UI structure and state.
CSS defines how that structure and states are presented.
Lambdas are only one side of the story. Yes, they are quite natural as event handlers but you may end up with loops in UI elements ownership graph. GCable systems handle this naturally. In C++ though... #1 below may help, but not always.
The power of HTML/CSS UI architecture is in these:
Sinking/bubbling events propagation schema. Containers know about events dispatched to children.
UI is made of uniform and relatively lightweight "Lego bricks" (DOM Elements). Overall API that your code uses to drive UI is quite simple. Compare that with Qt where each type of widget is a separate entity with bunch of methods - hard to maintain on the long run.
Those Lego bricks are styled independently from your code. And that is right thing to do - separation of concerns.
Because of #1, #2 and #3 UI is highly composable construct - few simple building blocks allow to build very complex things. Compare with Qt, MFC, native OS widgets or whatever. Just try to make component that combines input text field and a button with those frameworks ... that will be near a month task for skilled developer to do it right : think about focus management, accessibility, styling, etc. No surprise that Qt is that complex thing.
Again HTML/CSS (DOM based UI) is here not just because we have browsers or Sciter. But because quantity and quality are dependent from each other. Compact API and basic mechanisms gives different quality and so on.
> look at tableGet() ...
In fact hash-table is not always needed. Quite contrary - it may slow down properties retrieval, yet to increase memory consumption needlessly.
While ago I have written "When linear search O(N) is faster than hash table O(1) lookup".
It is exactly about implementation of object-as-a-property-rack in Sciter's script. For small objects they are just single linked lists, for large ones - hash table.
> license/cost is probably a big reason
Sciter is free in the same way as Electron. You will need to pay if you need access to it sources and/or technical support. Yet if you want to compile Sciter statically with your application, Electron by the way does not provide this option at all.
Sciter is a C++ extension (Rust, Go, Python, Delphi for that matter) . Sciter based applications use these languages for application cores - means that if you need performance/compactness you will do that in those languages and use Sciter as a UI layer. While in Electron you are stuck with JS only (or anything transpileable to it).
As of why AV vendors using it...
Imagine that you will need something small and as less CPU greedy as possible. Yet flexible and maintainable as you need to adjust your UI regularly to modern UI trends. HTML/CSS is a perfect combination for that. Check this as an illustration.
"No" on all hypotheses above.
Sciter is not a browser engine. It is rather UI engine that uses HTML/CSS in places where, for example WPF, uses XAML.
Sciter works on Windows (starting from XP), MacOS, Linux, Android, IoT devices, etc. So is no IE as you can imagine.
I wrote this article 6 years ago - history of Sciter creation and its design decisions.
Sciter supports HTML5 (as markup language), CSS 2.1 in full, some usable modules of CSS3.
And that is completely independent implementation of HTML/CSS rendering that I did by myself only. I even limited myself from looking into WebKit or Gecko implementation details.
It was created to be embeddable by design - compact and extendable from app side - these are primary design goals.
> deciding on the technology behind the SlothTracker
As for me that task is perfectly suitable to be implemented using Sciter. All UI components used there (looking on screenshots) are represented in Sciter SDK already - available out of the box.
And it is perfectly suitable for C++, yet applications that use Sciter are native ones, even their UI is declared in HTML/CSS. These applications are definitely native ones.
> it only works in chrome
It works everywhere. And, yes, it uses DOM, what is the problem with it?
Here is the demo of Sciter running on Android / OpenGL with 62 FPS (check video there).
Some screens are purely DOM based, some demonstrate mix - retained mode (DOM tree) with the use of immediate drawing on some widgets where it makes sense.
Yet there is a demo there of again virtual list with kinetic scroll animation (62 FPS list rendering).
I am still looking for multi-paradigm language that supports as deterministic as GC-based memory management.
In complex systems (especially UI ones) object ownership graph could be very complex and unknown upfront, may contain loops, and so GC is very beneficial in this respect. But GC shall not put brakes on code that can manage memory deterministically.
In fact modern D lang is quite close to that. I even started doing Sciter in D initially.
In fact D
If the browser is embedded, that is not an issue. You wouldn't even know its a browser, because the CSS/HTML is so perfectly tuned that it looks like an real application.
The anti-virus crowd use html guis for ages, also in very secure environments: https://sciter.com/
Check this: https://sciter.com/developers/sciter-docs/native-behaviors/ - in Sciter all input elements are ordinary DOM elements with native behaviors (a.k.a. controllers) attached to them.
Yet samples in SDK/samples/forms/ : https://github.com/c-smile/sciter-sdk/tree/master/samples/forms
I think it makes sense to walk through sdk/samples/ using usciter.exe demo browser from SDK.
This is a weird product. I went to the Sciter.com site and couldn't find any examples of the UI controls?! Usually when I look at UI stuff I look at the drop-down control, the tree control, and the data grid control, then one sample form. These four give me a good overview of what the components/tool looks like. Here I don't even see a button control much less examples of the available UI controls. What am I missing?
> Making a simple / ergonomic GUI in Rust
Yes, UIs are known by quite complex ownership graphs that can be quite complex, contain loops, etc.
Yet all these graphs are dynamic by nature - are not known at compile time. To handle all this GC is definitely required. Rust, and C/C++ for that matter, is not the best "language-behind-UI" - some other means are required to glue all these parts together. In Sciter that is script and its GC-able nature that handles cyclic graphs by design.
So I have some doubts about Pure Rust's UI Holy Grail.
Conceptually D lang is more suitable for being a UI language, IMO.
> work on desktop, in the browser, on Android, IOs,
Sciter, with Sciter.Lite, works on all these already. And does "themes, anti-aliasing, sub-pixel ClearType rendering, animations, translations, transitions" already on all of them.
Yet Sciter got Reactor recently - native implementation of RectJS core functionality: native JSX parser/compiler and native implementation of DOM/vDOM reconciliation algorithm.
Yes, in Sciter it is known as Reactor
In Sciter v. 4.4 I've added native implementation of SSX (a.k.a. JSX) and native implementation of reconciliation algorithm in Element.merge(vdom). So SSX is an integral part of script syntax now - no transpilers are required for React in Sciter.
You can do such desktop with Sciter.Lite that I've published recently (v.4.4.0.2).
Sciter.Lite is a "windowless" engine - on devices it spans whole desktop area - so desktop is a DOM tree that you can style from top to bottom.
If to think about OS UI based on it then we can imagine root HTML defined as:
<html.desktop shows="twitter"> <head><style src="user and system styles" /></head> <body> <navbar /> <statusbar /> <frame src="https://twitter.com/happ">place for applications to live</frame> <body> </html>
This way user can define styles that will apply not just to default screen but override styles of loaded applications. All sorts of things.
Interesting :)
While ago I started thinking from exactly opposite direction - having designed Sciter Engine (HTML/CSS/Scripting) already I dreamed that it would be cool to make OS from it.
So UI of the whole desktop can be defined in terms of HTML. Sciter supports custom native DOM elements so these could be windows of other applications.
Will it make sense to join our efforts? Having written Sciter by myself I shall admit that it takes quite a lot of time to write more or less complete HTML5/CSS3 engine.
Basic drawing is not a problem: CSS2 rendering required just two functions DrawGlyphs and FillRect. But transitions, transformations, opacity, <canvas> need decent graphics backend. Yet all those flex/grid layout algorithms ...
I've heard that Sciter solves some problems with Electron (much smaller in download size - ~8MiB runtime library, less runtime memory) and it also doesn't require JS on the backend at least - has quite a variety of language bindings. Of course it's not perfect but perhaps if more people knew about it, they'd elect to use it instead of Electron.
Aha... the scent is familiar...
Participated in one project recently for modernizing information system that was developed at Ramses II times.
The only parseable exhaust from the system was set of 80x24 screens - char arrays. And the team designed clever DSL to get data from them and HTMLize the data to be put in Sciter based UI.
I highly suspect that it is a COBOL system on the mainframe that no one will even try to redesign as half of US is dependent on it.
What I meant by "controlled" was that css wasn't from random websites on the internet that were expected to "just work" like they are in a full blown browser.
https://sciter.com/ has a mini browser effectively and I think this works because its not designed to work on all the broken html and css on the web but instead only what a local developer needs (and debugs).
It would seem like Servo should be pretty capable of this level of html and css support even if it isn't ready for the larger web.
In last 12 years...
EverNote started as Win32 app. Then some smart managers there decided that it shall be a WPF one. EverNote WPF version (EN 3.5 AFAIR) died at 6 months of age. Together with the WPF itself. Then another smart manager decided that it will be CEF. Original CEF (single process) has died too at some point...
Bloomberg Terminal, pretty much the same trajectory: Win32, Silverlight, WPF, CEF, Chromium custom build ...
Any other examples of that fascinating process - creation of problems to yourself to overcome them heroically?
In the the same 12 years Norton Antivirus is using the same Sciter Engine ... https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-one-application/
Sigh.
Not always large companies.
I have customers with 4-10 devs teams that use my Sciter for multiplatform applications with most of their code shared between platforms (Windows, MacOS, Windows). Shared code is C++ (backend), UI is HTML/CSS and script-behind-ui.
No surprise as that simply reflects the price of function call in JS (which is high).
With the constructor to create an instance JS will do the following, on each iteration:
var newInst = Object.create(MyClass.prototype); MyClass.constructor.call(newInst)
And MyClass.constructor will dynamically expand initially empty object (takes something too):
newInst.x = ...; newInst.y = ...
Case without constructor is significantly simpler. This run once, at class declaration:
MyClass.prototype.x = …; MyClass.prototype.y = …;
And instance creation is just this:
var newInst = Object.create(MyClass.prototype);
As you see first case takes: 1 JS function call and two property creations for each instance. Second case does nothing other than calling native function that allocates empty object.
BTW, in Sciter script I am using :
class Foo { this var a = 1; // member variable, a.k.a. "this variable" var b = 2; // static, class variable const c = 3; // static constant, seen in member and class functions }
OK, but why?
Each actual DWMs on Windows, MacOS and Linux allows to create windows with such decorations by standard means, for example:
Yet, such decorations are and shall be configurable by the user.
Yet there are Acrylic/Vibrant effects related to this - example
> to pull out the C++ classes Chromium uses to represent elements on a web-page
Sciter does that: sciter::dom::element.
Try my Sciter, it uses H/W accelerated graphics on all platforms (DirectX and OpenGL) so it is pretty good on HighDPI monitors.
You can try Sciter Notes and HTML-NOTEPAD applications to get an idea of what can be achieved with Sciter.
I honestly don't think I'd pick Ultralight for commercial stuff in a moderately successful business. Sciter is far more developed with bindings to almost every language. It's not quite HTML, but it's stable and sees a lot of use. That's where most people go who have money to burn and don't want to brave uncharted territory. Unless they want to work directly with CEF or Qt (or language bindings to them).
On the other hand, for contributing to experimental stuff, I'd rather support the Lexbor guy than this guy (who ran the Awesomium project and pulled a Houdini years back on his customers). At least that way I'm contributing to someone building a new engine rather than someone gutting WebKit. Ultralight seems like it runs the risk of being abandoned again after building your product around it. Browser-based-UX abandonware isn't fun.
Hopefully Servo will be easier to embed as it gets built.
checkbox + label is ugly of course.
Just in case, in Sciter I've made an option to use basic input "behaviors" for any elements, not just <input>s
So if you have these rules
ol > li { behavior:radio; /li's behave as radio buttons */ } ol > li:checked { color:red; / current in the group */ }
you will have one <li> of many selection in your list.
In the same way you can use
behavior:checkbox; /* basic :checked trigger / behavior:edit; / single line editor / behavior:select; / behavior of built-in <select>/ behavior:frameset; / resizable panels with splitters */
and others.
Surprisingly how many tasks can be accomplished with these basic blocks (a.k.a. "behavior styles") without even touching script in any form.
As of GUI, I tried that 10 years ago while considering options for Sciter.
J-SMILE project mentioned there was exactly that - micro JavaVM + GUI native runtime packaged into binary that was meant to be appended by class files to produce final GUI application.
Hello,
Avast, Bitdefender, Comodo, Dr. Web, Emsisoft, ESET, Qihu 360, SPAMfigher, Symantec and Webroot all use Sciter from Terra Informatica Software, so I would expect their user interfaces to perform similarly.
Regards,
Aryeh Goretsky
I would also suggest Sciter if you're looking at the Electron route.
Qt is going to be faster and less resource intensive. You should have good flexibility with either framework.
Such art make not that much practical sense of course but ability to define graphics directly in CSS is definitely needed.
I've implemented vector images in Sciter
and shall admit that they are quite handy.
Yet they are lightweight - you don't need to load/parse external images or fonts to do basic things. All icons in Sciter.Notes are such vectors - scalable for different screen resolutions.
> but in detail they aren't really anything alike
You'd be surprised how close they are in fact.
I designed as Java as JavaScript(++) VMs so know internals pretty well as you can imagine.
That hackernoon article is misleading.
You cannot use JIT on iOS devices - Apple's appstore rules prohibit that. That's why Mozilla uses platform web view on iOS. Neither Dart can use JIT.
But the question still stands, why Dart and not Java or JavaScript in Flutter? I've compared Dart with JS and script used in Sciter and do not see any principal differences that are worth of throwing Java away, at least on Android.
> I highly doubt that.
You've missed the point. On Linux Sciter Engine is wrapped into GtkWidget/GtkWindow. And there is nothing GTK specific inside the Sciter instance, check this on RPI and this on Mac - same HTML/CSS.
Yes, when Sciter needs to render DOM element outside window canvas, e.g. for rich popup, it will create GtkWindow for that on Linux. In the same way it will create HWND on Windows and NSWindow on Mac.
Concepts of desktop, desktop window, keyboard, mouse are common to all desktop platforms. Set of standard UI components is unique for each platform. Sciter uses common mechanisms: window, dialog (modal and modaless), popup (out of canvas DOM elements) are implemented natively.
Why not Sciter then?
All Windows versions starting from XP, Mac OS starting from 10.7, all Linuxes with GTK3 including Raspberry Pi...
Sciter uses HTML/CSS for UI definitions in the same way as WPF uses XAML but as it is designed to be embeddable and run desktop UIs. It allows to use C++ to implement custom UI elements - that is not just to run some native functions but to implement efficient native UI elements.
So to get best of two worlds - flexibility of HTML/CSS for 90% of UI and custom/native components for 10% of UI where you need maximum performance. And all that with 5mb dll or static library linked directly into an application.
I think that my sciter can be considered as a browser engine to some extent. And I did it by myself and without any external financing.
In principle I can make yet-another-browser of it in reasonable time frame - 6-8 months. Time is needed mostly for replacing my Sciter Script VM by something like V8 or Chakra as JavaScript is the must.
So technically basic web browser is doable even for indie developer.
But practically... not clear what for? It will not bring any financial benefits. So this is not a viable task for current economic formation of "developed democracy" societies.
I understand why Google finances Chrome development. Google is an Internet company - they provide their services through the browser and so the richer is the browser - the better for them - more services they can provide through the browser.
AJAX popped up in IE5 by Microsoft when they needed it for Office. Now Google is pushing WebRTC, WebWorkers, WebAssembly, etc. in order web platform to compete with desktop applications.
All those together and on top of existing pileup of cultural layers of previous semi-obsolete technologies makes task of creation of Chrome-compatible-thing to be comparable with the creation of yet another OS. And that, even for Microsoft, makes it far from being business attractive - why to bother if Google needs it anyway?
So we have Chrome == Internet and that is inevitable.
> For example, there is no provision in CSS right now to display on the total number of pages.
Yes but that should not be a business of CSS. It is rather a runtime functionality.
Like in my Sciter printing involves two documents: page-template and the document itself.
The page-template contains as content box where the document portions appear as special fields like total number of pages, current page number, odd/even modifiers, etc.
I did look into electron. It seemed a bit too complicated of a process though, at first glance, and somewhat over my head in terms of skill and concepts. Do you know of any "soft" entry points for it?
Also, during my search I happened to stumble upon sciter, and downloaded their sdk. They have a huge bunch of examples included. I played with it a bit, and it seemed really easy to implement local web applications in it. Though it has its own scripting language, so that's the downside.
Not SVG but rather something else. Web needs some vector image format that can be used directly in CSS and not just as border-radius.
Like inline vector images in Sciter or something as effective as that.
Oh, thanks for the advice... But did I say anywhere that I don't know how to use makefiles?
I am already compiling my Sciter for five different platforms + maintaining samples for 4 different IDEs.
I am using several external libraries other than my own. I see that zoo each day in real life. As an example: Skia uses GYP build system. Some other library uses premake, another one uses jam ... Legion is the name of them.
Sciter has three graphic backends Direct2D/DirectX - the one used by MS Edge and Skia - the one used by Chrome.
So technically rendering speed is at least on par with Skia backend.
As of using browser engines for desktop UI in general.
Main goal of the browser is to provide safe browsing experience, and rendering pages is just the second goal. That's why to render "Hello world" in Electron you need at least two processes (not even threads, sic!). That involves data marshalling between processes, etc. That costs as you can imagine.
Yet browser is about rendering stuff inside single canvas. But desktop UI is slightly more demanding - you need real windows in some cases: https://sciter.com/html-window/ And https://terrainformatica.com/w3/sciter-tooltip.png - DOM element rendered out-of-canvas.
>Sciter draws things faster than Electron as e.g. on Windows it uses DirectX directly. Electron uses Skia that is mostly CPU based rasterizer.
I don't know all the details, but the Chromium graphics stack is pretty complicated and differs between platforms. Here are some relevant documents describing parts of it
You can open chrome://gpu/ in browser to see which parts are enabled on your system.
I remember the massive jump in performance going from the old WebView in Android 4.3 to the Chromium-based one in 4.4.
Either way, benchmarks would be better than this theorizing.
>Yet to make syntax highlighting I've introduced "marked runs" - https://sciter.com/tokenizer-mark-syntax-colorizer/ . This allows to do syntax highlighting without change of DOM.
It's true that the DOM likely slows things down a lot compared to how they could be, but I haven't experienced any issues with VS Code performance.
Anyway, I'm not saying your framework doesn't have practical uses, just that it's often not an alternative to Electron.
It's more like an alternative to QML,or XAML, or other desktop libraries with a separate GUI language.
The main draw of Electron is getting access to the JS ecosystem (including TypeScript) and reusing parts of the same code on the web. Given VS Code's architecture and history (previous comment), they really didn't have any other viable options, and its success speaks for itself.
Delayed reply, but...
What about Sciter? It uses an extended variant of HTML and JavaScript (Sciter version is called TIScript), it's super mature, and it's been successfully used by lots of major companies (many AVs, including Comodo, Avast, Norton, Bitdefender, and others). It's also quite lightweight and fast.
> You can't compare 2d rendering with 3d mesh rendering.
Why not? In HTML/CSS you may have many semi-transparent layers that are object in 3D space strictly speaking. Yet animated 2D and 3D transformations. Yet kinetic scroll of the content that is an animation with 60 FPS rate.
All modern browsers use hardware acceleration (DirectX and OpenGL).
If still in doubt consider this: https://sciter.com/sciter-and-directx/ - 3D and HTML/CSS on the same pipeline - DirectX 60 FPS. Or this https://sciter.com/sciter-and-opengl/ - the same but on OpenGL.