50 million PCs are running Sciter or HTMLayout code.


Quite conservative estimation of number of PCs and Mac’s running either Sciter or HTMLayout code is 50 million worldwide so far.

Thanks to Sciter/HTMLayout customers and their great applications.

UPDATE: I’ve been told that at least one of companies from the list has 90 million registered users. So the total number is way above 100 mln computers.

10 years road to Sciter

Last year it was a jubilee of my BlockNote editor – it is 10 years old now. Quite a serious age for software product I think.


BlockNote, in particular its HTML WYSIWYG editing engine, was the very first version of H-SMILE core that works now inside the Sciter. H-SMILE core was used in other software products, for example in EverNote. In fact I was one of four developers who implemented excellent idea of Stepan Pachikov (EverNote idea-monger and founder) and created first public versions of EverNote.

In parallel and after that I was designing various UIs and editing components. WordProcessor engine that I’ve created for Top Producer Systems (The move.com company). That WordProcessor still works in their flagship product AFAIK. Current stack of Web technologies still does not provide facilities for page oriented WYSIWYG editing so there is nothing to replace WordProcessor yet. I’ve got quite interesting experience implementing text layout and editing algorithms there. Ideas from there have found their way in Sciter code in one way or another.

At some point I’ve got an impression that C++ is not the best language for UI programming. In particular GC as a memory management mechanism is significantly better suitable for typical UI tasks – many small objects with quite non-trivial ownership graphs. I’ve started looking on Java but having dependency on installed Java VM didn’t look right at the moment. So I’ve created so called j-SMILE JavaVM (based on SuperWaba) that was tailored specifically for UI purposes – designed to be combined into executable of the applications together with bytecodes it is running. J-SMILE demo (buggy but works somehow) and sources of class files are available here.
J-SMILE screenshot.

In J-SMILE I started experimenting with HTML as a UI layout manager and sinking/bubbling event propagation mechanism used in Web browsers. These mechanisms were proven to be highly useful for desktop UI purposes too.

Pretty much at the same time with my J-SMILE development Sun-Microsoft “Java Wars” had begun. And this immediately put the end to my J-SMILE development. I realized that I have no chances on this front and started looking for other options.

Some time later D-language raised in the sky and gave me real hope for the best ever language-behind-UI. GCable, natively compileable so fast and with pretty sufficient functional features. So I’ve started porting J-SMILE to it under the name Harmonia framework.

Harmonia testbed application
Harmonia testbed application

For those who are interested to see Harmonia in action: Harmonia demo, Harmonia sources and class tree.

D is really very cool and convenient language but after some time I’ve decided to stop Harmonia development for the following reasons:

  1. It was time when D-language was changing very frequently. Pretty much each nightly build was changing core grammar. So Harmonia development was similar to shooting a moving target. Far from being normal development process.
  2. Having each and every object manageable (garbage collectible) is far from being optimal. HTML DOM tree is a large set of small objects. All these small objects are flooding manageable heap making GC cycles very CPU intense. That’s not about Harmonia only by the way – I believe Android suffers from this problem too when its UI freezes noticeably.
  3. I’ve got very strong feeling that each part of UI framework shall use its own memory management and ownership principles that are optimal for the role they are playing. HTML DOM tree has very regular structure with clear one parent – many children ownership graph. Life cycle of DOM elements (read “UI elements”) is also quite deterministic. There is absolutely no need for GC if to speak about HTML/CSS.
  4. But code-behind-UI – code that does UI automation in “on-click-here-push-item-there-and-collapse-panel-over-there” fashion has to be manageable. GC there is the must – ownership graph is unknown upfront and frequently contains loops.

So I reverted back to C++ and created pure DOM and rendering implementation – HTMLayout. And started looking on embeddable languages that can be used with it as “language behind UI”. Here are languages that I considered for that purpose:

  1. Ruby and Python – were rejected almost immediately. HTML friendly language shall have syntax that is not dependent on tabs, line feeds, etc. For quite many reasons. And yet Python was using C/C++ heap for object allocations, UI objects lifecycle require compacting GC – objects created and destroyed frequently.
  2. Lua – pretty much for the same syntax reasons. But it was a good candidate. I even started creating JS syntax alike compiling front-end for its VM. But discovered in process that Lua’s object/class model is too rudimentary I would say.
  3. JavaScript – as a natural choice was always there. But its prototyping schema, “hackish” way of doing classes there and that famous “automatic semicolon injection” problem were stopping me each time I was trying to consider it. Only ECMAScript version 6 has started to appear solid enough. But that’s just recently.

Needless to say that my investigation ended up in creation of first C-SMILE and then TIScipt. TIScript is almost JavaScript (JavaScript++ if you wish) but with modular system (namespaces) and classes. It also got built-in persistence. And it inherits base syntax and runtime library from JavaScript.

HTMLayout combined with TIScript became Sciter as you see it now.

Oh, and in parallel with all this I was working as UI Architect and team lead at Top Producer Systems (move.com company) on various desktop UI, Web and mobile applications projects. And yet participated in HTML5 and CSS3 specification development as invited expert in W3C HTML Working Group.

History of one web UI component

10 or so years ago I was asked to design Word Processor WYSIWYG editing component. The editor should handle editing of paged documents. It has notion of pages where document text is replaced. The text can wrap around absolutely positioned (page box related) blocks – images, text boxes, etc. To be short – something like micro-Word but lighter and PDF-output oriented.

The target application, where it was used initially, was online Web application with UI written as a quite large Java Applet. These days such a technology is know as “single page web applications”. But 10 years ago browsers (actually it was just one at that moment) were simply not ready for productive applications – applications that people are opening in the morning and closing when they leave workplace.

Even at that moment of time Java handled that type of UI pretty well. We just did our own UI framework/set of widgets for it but still.

The Word Processor component was written in C++ and integrated with the rest of Java application through JNI.

We were happy with the app and so did 70,000 users of the application. But joy was lasting only couple of years. As one day Microsoft and Sun did not reach an agreement on Java destiny inside the browser and so our application literally became deprecated in one day. Doh!

So the development of the UI of the application started from scratch again. At this moment of time Microsoft added almost accidentally AJAX support to IE and that gave a hope to the team that they can finally use HTML/CSS for UI of the app. And development started.

But it was still not clear what to do with our nice Word Processor and HTML WYSIWYG editor that used BlockNote editing engine for e-mails. Users already created tons of documents so we cannot simply drop editing functionality from the app. Web platform hadn’t and still has no means to support WYSIWYG editing of paged documents. And even HTML WYSIWYG editing (a.k.a. contenteditable) is still quite far from ideal (e.g. to insert an image you need to upload it to the server first, and so on).

At that moment I almost had Sciter v.1 ready and we’ve decided to wrap it as an ActiveX component (for IE) and so called Netscape Plugin (NPAPI, for Firefox). I’ve created editor’s chrome as Sciter’s HTML/CSS/tiscript and wrapped the editors as Sciter’s DOM behaviors. And we’ve got our application up and running again. As the same Sciter engine run in different browsers we saved a lot of time on cross-browser testing of the editors, it just worked in each of them. And even in Google Chrome that arrived later.

Word Processor in Sciter screenshot
Word Processor running in Sciter ActiveX on web page

Joy of having convenient and stable application lasted little bit longer this time. Up to couple of months ago when Google Chrome and Mozilla pretty much at the same time declared that, basta!, they are not going to support NPAPI starting next(!) year.

Their motivation is in principle quite understandable: 95% of internet users do not use any plugins at all so why to bother. But, hey, what about our 70,000 users? What they should do? Except of NPAPI there is simply no other means to run native components on the web page in GC and FF… And, again, that happened with 3 months notice… Cool, eh?

So the team is in this interesting position again – what to do with our app.

People, seriously, I believe it is time to consider Sciter as a front-end for even online (productive, business) web applications. Just create HTML/CSS/tiscript once and it will work in all Windows versions and Mac OSX (coming). Linux version will be ready shortly after OSX version.

And forget about testing everything separately in IE, FF, GC, Safari and Opera. Sciter does not require installations – just copy and run it.
Enough is enough, no?

And yet, if you not convinced yet then check this news for IE 11. If in your Asp.Net you happen to rely on things like
if(request.browser.ActiveXControls) ... else ... apply hot-fixes from the article above. Otherwise your app will not work properly in IE 11.

Just in case: here is an example of Word Processor document shown above saved as PDF.

Usability of tree and paged lists

I’ve found first answer in this topic on StackExchange extremely representative.

That reminded me discussion we had when were designing the first version of Evernote application.

Initially the Evernote has UI organized as “endless tape of notes”. Here is one of sketches that I did at that time:

Challenge there was to provide UI that allows the user to find notes quickly without need of excessive scrolling.

Each note may have so called tags (a.k.a. labels) assigned. By clicking on tag (left side bar) the tape will get filter applied – only notes with such tag are shown.

By expanding the tag (“+” sign) you can see intersection of notes that have this tags and some others. For example here click on hello->world (on the left) will give you set of notes with the condition has-tag:"hello" AND has-tag:"world" (see top bar):
Note tape with filter applied

And if you type “wonderful” in the search field you will get filter has-tag:"hello" AND has-tag:"world" AND has-text:"wonderful" applied.

This will give you single note:
tape with text filter

Pretty convenient I would say.

Comments in source code considered harmful

In the file ResourceFontFileLoader.h (offical Windows SDK samples) you can see variable declared as:

static IDWriteFontFileLoader* instance_;

As you see it is a raw pointer here.

And in the file ResourceFontFileLoader.cpp it is initialized with this:

// Smart pointer to singleton instance of the font file loader.
IDWriteFontFileLoader* ResourceFontFileLoader::instance_(
    new(std::nothrow) ResourceFontFileLoader()

Note the comment. “Smart pointer” there is just a good wish. I believe someone reviewed that code and according to the comment all this passed code review. But the code leaks memory. So that comment does quite opposite to what it supposed to do actually – it is not helpful but rather harmful.

V.I.Lenin with Mao balancing on his head and myself.

Full name of this sculpture
Mysef, Lenin and Mao
is “Miss Mao Trying to Poise Herself at the Top of Lenin’s Head”. It is installed here in Richmond, BC, Canada.

Standing near it was thinking a lot. The idea has something in it. I grew up with these names everywhere in USSR. And it is history now. Sic transit gloria mundi?

UI programming you said?

Usually business applications are split in three tiers: user interface layer (UI), business logic layer (BLL) and data access layer (DAL). That split is also known as Model-view-controller architectural pattern.

Ideally each layer should be isolated from the rest. For many good reasons. In any case each layer operates using its own vocabulary (namespace if you wish). For example “Account” in UI means some set of fields (<fieldset> literally). In BLL it is an instance of some class with attributes and methods describing logic. And in DAL it could be just a record in DB with associated triggers and stored procedures.

Code that works on each layer(domain) is serving different tasks. Ideally each such layer may require different programming languages that are optimal for each particular layer. E.g. DB layer as a rule uses TSQL as it better suits DB manipulation needs.

The same thing is about UI. Usually UI tasks are just sequence of rules like “if user clicks here than enable that thing over there”. Such tasks may or may not be handled equally well by universal languages like C++.

Ideally UI layer should have its own language that is better suitable for UI needs. In the same way as DB has its own language (couple of them actually: DB schema definition language and transaction definition language).

Consider following task: you have toolbar with “save” button and two widgets that do different things in onSave() methods. In C++/htmlayout you would need to create separate dispatcher that knows about “current” element and reroutes “save” button clicks to different widgets. That will require separate external entity for these two widgets.

And in Sciter you would write this as:

class MyWidget: Behavior
  function onFocus()
    var me = this;
    // bind toolbar buttons to this widget methods:
    self.$("button#save").onClick = function() { me.doSave(); }
    self.$("button#new").onClick = function() { me.doNew(); }
    self.$("button#open").onClick = function() { me.doOpen(); }
  function doSave() { ... }

when MyWidget gets focus the code in onFocus() replaces onClick event handlers of the toolbar buttons by new functions like function() { me.doSave(); } that will call methods of this particular widget.

You can simulate things like this in C++ of course but it will be significantly more complex. Try to imagine how you would do this in WTL or MFC or any other GUI toolkit. Less code – less errors and so on.

After many years of designing various UI and UI toolkits I shall admit that UI automation/programming is not quite OOP task in general. Usually it is better describable in terms of something close to functional programming but with the ability to define classes/objects.

UI is an assembly of sometimes very different UI components/controls. That requires language that is flexible enough to glue them together. That is my vision on TIScript in Sciter.

And of course markup and CSS are also Good Things for the UI. Especially CSS.

CSSS! and computational complexity of selectors.

Lets say we have following markup:

   <li>Second (with <a href=#>hyperlink</a>)</li>
   <li>Fourth (with <a href=#>hyperlink</a> too)</li>

and the styling task: all <li> that have <a> elements inside have yellow background.

If we would have hypothetic selector :with-child(selector) then we could write this as:

li:with-child(a:link) { background:yellow; }

Problem with this selector lies in its complexity – to compute such selectors you need to scan whole subtree of the element (<li> here). That is a task of complexity O(n). n here is a number of children of the element. Potentially it could be the whole DOM ( html:with-child(a:link) ).

And again that O(n) is not that bad if it happens only once but for the case:

html:with-child(a:hover) p { ... }

all <p> elements of the document should get new styles each time when some <a> in document will get :hover state. And that is really bad. Standard methods of optimizing such cases (e.g. caching) may not be acceptable as they may require significant amount of RAM and/or again CPU resources.

… back to the original task of styling "<li> that have <a> elements inside". It is still possible to solve it while keeping resource consumption at the same level.

Imagine that we would have some magic engine that will assign, say, attribute has-a-inside to such <li> elements. Then our task of styling <li>s will turn into simple rule that is known to be effective:

li[has-a-inside] { background:yellow; }

In real world scenarios people these days use JavaScript for that. Requires some programming but works reasonably well.

But our desire to do this solely by CSS as JS is not always available. Here is the method of how to accomplish this by CSSS! (so called active CSS) introduced in recent versions of h-smile core (htmlayout and the Sciter).

In CSSS! we need to create one helper rule that will create attribute has-a-inside for each <li> with <a> inside:

  assigned!: self.has-a-inside = self.$1( a[href] )? "true" # null;

This rule simply means:

When element li will get this style declaration first time (so when assigned!) this statement do:

  1. assign "true" to the attribute has-a-inside if that li element (self) has at least one element inside matching the selector a[href].
  2. or assign null to that attribute – so to remove it form the element.

The only rule left is the one that I’ve already mentioned:


Thus after loading such document all <li>s with hyperlinks will have yellow background. Done.

Of course it is not so abstractedly perfect if to compare with with-child(a[href]). E.g. our solution will not reflect dynamic DOM updates but that was the problem we were trying to solve anyway.

Nevertheless it will allow to solve the task in most of practical cases and will at least not make selectors matching implementation worse than it is now.

CSS, selectors and computational complexity

CSS (Cascading style sheets) has pretty extensive set of so called selectors. Example:

ul[type="1"] > li
  list-style-type: decimal;

Selector here means the following: each li element that is immediate child of ul that has attribute type with the value "1" has that style.

Selectors and assosiated styles constitute static system of styles. And so they obey following rule (the law of CSS selectors):

At any given moment of time all elements in the DOM that satisfy set of selectors have corresponding styles applied.

Such static nature of CSS selectors establish some obvious (and not so) limitations on what could be done with selectors and what types of selectors CSS can support. For example:

  • Selectors cannot use information defined by styles. Imagine hypothetical selector and style:
    div:visible { visibility:hidden; }

    Such pseudo-class always fails and so breaks the rule defined above. There is simply no such moment of time when the rule above is valid.

  • Selectors can use only those features/characteristics of the DOM that can be evaluated at constant (or near) time. Otherwise observer will be able to catch moment of time when the rule will not be true.
    • Consequence of this: selectors that require scan of number of elements of the DOM unknown upfront ( have complexity O(n) in other words ) are "persons non grata" in CSS.

There is nothing wrong in principle with O(n) complexity. At the end resolution of all styles of the DOM that has n number of elements is O(n). The problem arises when you use selectors that each has O(n) complexity. Total complexity in this case will be O(n*n) and that is the cause of troubles.  In case of frequent dynamic updates each such update may require re-computation of all styles of all elements so web page may easily become non-responsive – CPU will be busy resolving styles without doing any good to the user.

Imagine that we have selector like:

ul:not-exist(a:hover) {color:red;}

where :not-exist(…) is true when DOM does not contain element in brackets.

Computation of such pseudo-class is a task of complexity O(n) where n is a number of elements in the DOM.

No one of currently supported selectors in CSS selector module (http://www.w3.org/TR/css3-selectors/) have complexity of O(n). But there are selectors like : only-of-type pseudo-class that are "not good" as in some conditions their computation are as complex as O(n).

Next article will explain what could be done in CSS to overcome complexity problem and still be able to accomplish tasks like ul:not-exist(a:hover) {color:red;}

Some numbers if you wish:

Let’s assume that we have

  1. DOM with 1000 elements and
  2. single selector that has complexity  O(n) that requre 1 microsecond for computation.

Total time requred for the DOM to get its styles will be:

1000 * 1000 * 1μS = 1000000 μS = 1 S (one second)

Lets double number of elements in the DOM so we will get:

2000 * 2000 * 1μS = 4000000 μS = 4 S.

So by simply doubling number of elements we’ve increased time needed by four.

In real time scenario (on complex sites) it will easily make such sites too heavy to deal with.