Sciter v.2 technology preview

You can download Sciter v.2 SDK preview from here

/bin/sciter.exe in the archive is a demo application to play with. Its sources are in /demos/sciter/ folder. After start you should see something like this:

Note: this version works only on Vista/W7 as it uses Direct2D/Write graphics backend. Aero and W7 Basic DWMs only for a while.

New features in this version:

  • Direct2D/Write graphics backend – pretty fast on some operations. Expect animations to work faster.
  • Support of CSS 2D Transforms Module Level 3: – everything except matrix() function. Will add it later if needed.
  • Internal DOM representation was redesigned to avoid need of that ugly <text> element injected by the parser. DOM is more standard now and in principle H-SMILE core can pass ACID2 test (if I will have a time to tweak it for that). DOM is represented by Element and Node entities. Node wraps text and comment nodes in HTML.
  • TIScript got support of "tagged n-tuples" data type. with optional tag (a.k.a. name).

Some observations about Direct2D/Write:

Font rendering

Font rendering as I’ve mentioned already is significantly different in GDI and DW. Small an basic UI fonts looks better in GDI mode. Larger fonts are better in DW. For white text on black background with small and medium font sizes the GDI rendering is the only option I think. Just load /samples/basics/test-font-rendering.htm into the Sciter and you will see what I mean.

I was forced to introduce font-rendering-mode proprietary property for applications to be able to tweak this aspect.

Direct2D performance

While it is good on medium/high-end graphic cards it may behave very badly on low-end graphic cards or when there are applications on desktop that do graphic intense operations. Notably running Adobe Flash may affect speed of rendereing of other applications. That is not only about Sciter per se but other applications. Windows Live application suite is an example of graphics sensitive application. You may notice frame drops in animations inside Windows Live Mail or Messenger.

It appears as Direct2D/Write is a foundation for future high-DPI displays. As for now that font-rendering-mode workaround is the must I believe.

The KiTE – template engine for JavaScript


Modern Web applications frequently use AJAX kind of client/server interaction. They receive data from the server in pure JSON format. That means instead of generating markup on the server such applications are composing HTML inside the browser (on client side).

Straightforward approach is to use string concatenation spagetti like : "<b>" + data + "</b>".  But this almost always will end up in non-maintainable mess. Real Jedi use markup templates. Typical PHP page is a script with embedded HTML – typical template the gets "instantiated" for the particular GET request/data/user.

PHP or plain old ASP are not only possible template formats. There are a lot of template engines and template languages in the wild. All of them fall into four major groups:

  1. Minimalistic, logic-less: {{mustache}} and (probably) PURE;
  2. Still simple TDLs but with some simple logic like if/else construcs: jQuery.tmpl() and the KiTE,
  3. PHP or ASP alike templates: JavaScript constructs embedded in HTML using <% %> brackets: jQote, John Resig’s Micro Templates, EJS, etc.
  4. Group of template engines based on #haml/Ruby ideas – they use special non-HTML markup.

In general: as simple language, less syntax noise it creates – as better. Easier to comprehend and so easier to maintain. The worst case from this perspective is actually PHP (group #3) – mix of two different syntaxes in single source (script and markup) can easily become not readable.  

Speed of template instantiation is on other axis of "templates space". Implementation of PHP alike templating (group #3) is relatively straightforward with JavaScript. Basic idea is to replace all text between
"%> ... some markup... <%"  
by something like
 out += "... some markup...";  
and wrap the template into
 compiled = new Function(transformed_template).

Template instantiation in this case is a matter of calling such function. This approach potentially is as fast as JavaScript itself. But as I said the template source is too "dirty" even in simple cases. I believe that code from this article is a good example of how messy it can be with just few if/else’s.

On other side {{mustache}} templates are pretty clean but current {{mustache}} implementation is extremely slow. According to it is 150 times slower than the most effective jQote2. Too bad to be honest.

Another problem with the {{mustache}} is its logic-less nature. I understand the motivation but in reality some simple logic is required. Something like "if fieldA > 10 then render the record one way otherwise in some other".

So I came up with …

The KiTE.

KiTE is lightweight (180 lines of code) and fast JavaScript template engine. It uses template defintion language (TDL) that is close to {{mustache}} but with few additions: conditional sections and custom formatting functions.

Here is an example of KiTE template that emits simple list of contacts:

    <li><b>{{firstName}}</b> <i>{{lastName}}</i></li>

When given by JS data in following format:

{ contacts:
  [ { firstName: "Ernest", lastName:"Hemingway" },
    { firstName: "Scott", lastName:"Fitzgerald" } ]

the template will be instantiated as this list:

  • Ernest Hemingway
  • Scott Fitzgerald

KiTE templates can be placed in

<script type="text/x-kite">

sections on the page so they will not polute JavaScript code.

You can use this document to get a feeling of the KiTE templates.

Idea behind KiTE implementation, defintion of TDL and the kite() function are all explained here

And the last: the name "KiTE" is an acronym of "KiTE is a Template Engine".