With the introduction of Sciter.Lite in v 4.4.0.2 the engine becomes an universal UI solution that covers:

all active desktop OSes : Windows, MacOS, Linux, BSD, etc.

: Windows, MacOS, Linux, BSD, etc. mobile devices : Android, iOS, potentially on Tizen, and others that will come up;

: Android, iOS, potentially on Tizen, and others that will come up; any embeddable device , like IoT or automotive display panels, that has graphical display attached;

, like IoT or automotive display panels, that has graphical display attached; game alike application s that need UI layer embedded into main scene;

s that need UI layer embedded into main scene; yet in principle Sciter can be used as an OS graphical layer. I can imagine mobile OS that has Sciter UI with a <frame> where applications (HTML/CSS/script+native) are loading.

Sciter.Lite is built from the same sources as the Sciter. Both expose the same native and script API.

The major difference between [desktop] Sciter and Sciter.Lite is in how these two use windows.

Windowing

All desktop OSes have a concept of separate [desktop] windows.

[Desktop] Sciter knows and uses HWND , NSWindow* , GtkWindow* . Sciter can create separate windows and dialogs using view.window() , view.dialog() and view.msgbox() functions. Yet it supports out of canvas windowed popup DOM elements by using Element.popup() function.

knows and uses , , . In contrary, Sciter.Lite usually spans whole device surface – device display is just one big window if you wish. And so there is no need for Sciter.Lite to use window handlers. In Sciter.Lite context, HWINDOW type is typedefed as void* – pointer that is not interpreted internally as a window handler. Applications that integrate Sciter.Lite are free to use it as a pointer to some internal structure associated with the instance of Sciter engine. view.window() , view.dialog() are subjects of emulation – either on engine side or on application side. The work on these functions is ongoing. Element.popup() is also a subject of emulation. Work on popups is in progress too.

usually spans whole device surface – device display is just one big window if you wish. And so there is no need for Sciter.Lite to use window handlers. In Sciter.Lite context, HWINDOW type is typedefed as – pointer that is not interpreted internally as a window handler. Applications that integrate Sciter.Lite are free to use it as a pointer to some internal structure associated with the instance of Sciter engine.

UI Themes

Sciter includes “unisex” default style system (so called master.css) that is modelled after Bootstrap. And Bootstrap theming is quite widespread and familiar to most of users.

But of course each OS/device has its own distinct styling so in order an application to look native on the platform proper styling should be applied. In Sciter UIs styling is a subject of designing proper CSS declarations.

Here, for example, is the basic Material theme from Sciter’s SDK with some animation samples of Sciter.Lite running on pretty average Android device:

In any case, core of the application that uses Sciter UI will be the same on different platforms – only styles need to be tweaked.

Extensibility

Initially Sciter was designed as multiplatform UI layer for C/C++ applications. While now there are a lot of Sciter wrappers for different programming languages, C and C++ are the main integration targets.

Extensibility by and integrability into C/C++ applications is what I mean by “embeddable UI engine”. It is easy to define native function and expose it to script. So instead of adding heavy JITs and WebAssembly mechanisms to the engine Sciter simply offers you to use battle tested C/C++ for functions that require heavy computations. After all C and C++ works on all platforms where term “UI” makes sense.

[desktop] Sciter and Sciter.Lite share the same API (modulo HWND related functions) and so the same native C/C++ code that communicates with the UI will work on all platforms supported by Sciter and Sciter.Lite.

That means you can really design native C/C++ applications that will work on any device that has graphical display. CSS and script will allow to tune UI up for specifics of particular device or PC – your native code may stay exactly the same.