HTML/CSS desktop UI solutions, distribution sizes

As was mentioned, I’ve added scapp.exe to the SDK distribution. The Scapp is a monolithic executable with Sciter engine inside.

The question: Having the scapp what if to create IDE using it? How that IDE will compare with other existing on the market?

To answer on this question I’ve created simple IDE sketch in Sciter (sdk/samples/ideas/ide/) :

ide-windows ide-osx
As you see it is pretty close to, let’s say, Brackets editor from Adobe: brackets-windows

My quick sketch implements just basic functionality: loading file, basic editing and syntax highlighting. All together HTML/CSS/scripts are about 40k (uncompressed). Full implementation will definitely have more of those. Let’s assume that we will be creative enough to produce 1mb of scripts, styles and HTML.

Together with the executable it will give us:

Binary (scapp.exe) HTML/CSS/scripts total
on disk 4.1mb 1mb 5.1mb
1.8mb 0.29mb 2.09mb

So the whole IDE could be of just 2 megabytes !

Let’s compare it with other behemoths then:

IDE/vendor distribution size installation size ratio to largest
(the less – the better)
Brackets / Adobe 48.1mb 114mb 51%/31%
Visual Studio Code / Microsoft 31.9mb 135mb 34%/37%
Atom / GitHub 93.6mb 366mb 100%/100%
Sciter / Terra Informatica Software 2.1mb 5.1mb 2%/1.4%

So for each of us, users, it takes 50 times more of traffic to download these things that it should be… Is it fair?

scapp.exe – standalone Sciter executable.

Adding scapp.exe to the SDK.

The ScApp is an executable that contains Sciter engine linked statically – has no external dependencies.

scapp.exe can be started without parameters or with a file name that has either .htm, .tis or .scapp extension:

> scapp.exe


> scapp.exe tetris.scapp

If it starts without parameters then it will try to look for either main.htm, main.tis or main.scapp in current folder.

If .htm[l] file is given Sciter window will be created and the document will be loaded to it.

The .scapp file is a zip file containing /main.tis at root. The main.tis is expected to contain code creating windows and calling; – GUI message pump loop:

  // create first window, it may call Sciter.requestQuit(0) to exit from the loop below
  var window = View.window { ... };
  // run message pump loop of the application

Essentially it will just execute the script in the same way as tiscript.exe does.

At the mean time, event handler assignment…

Sciter supports event handler assignment in jQuery style:

element.on("event", "selector", function(evt) {...});

That looks mostly OK but for some reason I feel it as “aesthetically non pleasant” so thinking about alternatives.

One feasible option/idea may look like this:

// subscribe function for "click" event on element
element << function "click" (evt) {...};

That above is a direct equivalent of

element.on("click", function (evt) {...});

And in full form, with selector

// subscribe function for "click" event on <button id=first> element
self << function ["click","button#first"] (evt) {...};

The main challenge here is to stay in constraints of JS syntax/grammar …

Components, React.js style…


I am thinking about adding @component feature to Sciter a la React.js

Consider this construct:

@component Toggler {

  :root { flow: stack; }
  :root > option:nth-child(1) { ... }
  :root > option:nth-child(2) { ... }
  :root[on][off] :
    <option>{ attributes.on }</option> 
    <option>{ }</option> 

  :root[on][off][mixed] :
    <option>{ attributes.on }</option> 
    <option>{ }</option> 
    <option.mixed>{ attributes.mixed }</option> 

  // event handler 
  on :root click(evt) {
  // event handler on child element
  on option mousedown(evt) {

  // method  
  function foo() { ... }

  // property  
  property bar(v) { ... }


The @component is essentially a @set that contains not only style declarations but also [optional] markup of the component and code equivalent of

class Toggler:Behavior { 

   function attached() {

   function foo() {  ... }
   property bar(v) { ... }

So if you have this markup:

    <link rel="components" href="components/">
    <toggler on="yey" off="ney">

you will see that component instantiated and initialized in the DOM.

CSS variables support

I am adding support of CSS variables. In Sciter this is pretty much about the same feature set as defined in CSS Variables Working Draft but with slightly different syntax:

Declaration of the variable:

body {
   var(foo): #f00;       /* declaring variable with name "foo" 
                            having color value */
   color: var(foo,#000); /* using the variable */

Variables are inheritable so everything inside <body> can use that variable:

div {
   background-color: var(foo,#00f);

Note that variable usage contains two pieces: name of the variable and default value that will be used when variable is not defined.

DOM API in script will also get methods to get/set variables in runtime:

$(body).style.variables { 
    foo: color(0,255,0) 

After that all elements that use the variable in their styles will get new color.

Sciter and OpenGL

Sciter with Skia/OpenGL backend adds an ability to render HTML/CSS directly onto OpenGL window mixing HTML content with 3D content.

Here is a screen cast of one of one of stock GLFW demos with Sciter additions.

OpenGL integration uses the same approach as used in Sciter/DirectX – document in the window may contain two HTML layers with 3D scene in between:

sciter DOM layers on OpenGL window

Sciter with Skia backend, v.

Sciter with Skia backend, closer to the final. The feature set matches official Sciter version

This build fixes issues with layered (transparent) windows.

Update: Skia backend is a part of main SDK distribution since v.

The version is 100% API compatible with previous builds – drop-in replacement.


  • /bin/ – Windows binaries, Direct2D and GDI+ backends.
  • /bin.skia/ – Windows binaries, Direct2D and Skia backends.
  • /bin.osx/ – OSX binaries, CoreGraphics and Skia backends.

All Windows samples and Sciter itself are compiled with MSVC 2015.

Note that on Windows Sciter includes as Direct2D as Skia backends. There are four backend modes (configured by SciterSetOption(NULL,SCITER_SET_GFX_LAYER, mode); ):

  1. GFX_LAYER_WARP – Direct2D WARP mode, CPU rasterization;
  2. GFX_LAYER_D2D – Direct2D H/W mode, GPU rasterization;
  3. GFX_LAYER_SKIA – Skia CPU rasterization mode;
  4. GFX_LAYER_SKIA_OPENGL – Skia OpenGL rendering backend, default for now.