Category: Web Application Techologies

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

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.

“Theory” of URLs for developers

We are using URLs these days quite a lot, but not all of us understand what they actually are.

By this post I will try to explain their structure and how Sciter/HTMLayout deals with them.
Please note that this is sort of informal explanation and I am using term “URL” here while “URI” is more correct name for that entity strictly speaking.

URLs are made from these 5 major parts:

<scheme name> : [//] <resource identification > [ ? <query> ] [ # <fragment> ]

Where:

  • scheme name – is in principle any name token – name of the URL scheme. Some of names are well known: “file:”, “http:”, etc.
  • // part – if present, means that the following “resource identification” part uses hierarchical naming convention, with ‘/’ character as a delimiter.
  • resource identification – is either ‘/’ separated path name if ‘//’ is provided. Or it is some “flat” name.
  • query part is in principle meaningful only for dynamic client/server scenarios. It is an instruction to the server to provide that resources with those parameters.
  • fragment – is a name or ID of some sort that identifies some location or part inside the resource.

Consider that you have the same HTML test-file.html available from these three locations:

  1. file:///c:/test-folder/test-file.htm
  2. http://example.com/test-folder/test-file.htm
  3. res:test-file.htm

Let’s imagine that the document contains image with relative path:

  <html>
  <img src="image.png">
  </html>

Sciter, while loading the document, will resolve relative path name “image.png” to these:

  1. file:///c:/test-folder/image.png – as base URL is hierarchical one.
  2. http://example.com/test-folder/image.png – ditto.
  3. res:image.png – but here only resource schema is inherited as base URL uses “flat” naming convention.

In principle your Sciter application can use your own URL schema. You just need to decide will it be hierarchical or flat.

For example if you will call SciterLoadHtml(html, "app://module/main.htm"); then all relative links inside that document
will be resolved against app://module/ base name. So in your SCN_LOAD_DATA handler you will get: “app://module/images/img1.png”, “app://module/styles.css” and so on.

But if you plan to put all your files into resource section of your executable then you should use “flat” schema, like “res:”.

And the last note: if you use hierarchical URLs in SciterLoadHtml and SciterLoadFile calls then these urls must be absolute ones otherwise Sciter will not be able to resolve them reliably.

Sciter,

Adding basic <video> support to Sciter.

The <video> element (behavior:video in fact) is rendered windowlessly as normal DOM element so can participate in animations, transforms and to have other DOM element rendered on it.

Here is a screenshot of Sciter made when it is playing video (standard 30 fps rate) under animation and transformation on semi-transparent background.

sciter video demo

[AngularJS] “you have ruined javascript”

Rob Ashton article: “you have ruined javascript”

While I am considering it as a bit of overreaction but I 100% agree with the nature of problems defined there.

Chase for silver bullet lead us in the same trap of over-engineered world of abstractions. Or over-abstracted world of engineering? Whatever …

Mac OSX, DPI and font sizes mess

Most of applications on Mac OS X use fixed 72 DPI settings despite of all these Retina and other high-DPI monitors. I understand that this is legacy we’ve got from last century. But c’mon, it is 2014 out there …

Even conventional browsers that supposed to handle scaling well by using CSS rules are failing to render simple things like:

  <div style="width:3in; width:3in; border:1px solid">
    is it 3 inch square?
  </div>

you will see everything but not 3 inches square here.

I am not getting what’s the problem to implement proper scaling. Here it is in Sciter on Mac:
DPI screenshot

Screenshot is taken on Mac with Dell UltraSharp U2711 monitor.

Repeatable: simple jQuery plugin for rendering lists, tables, etc.

While ago I’ve published simple and compact (90 lines of code) plugin for rendering, well, repeatables.

Here is its documentation and here is live demo.

The Repeatable is a mechanism of DOM population from array of objects. Repeatable template is defined directly in markup:

<ul id="people">
    <li><a href="mailto:{{this.email}}">{{this.name}}</a> <b if="this.age > 18">18+</b> </li> 
    <li>No data available</li>
</ul>

and that template gets cloned and instantiated for each record in the array.

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.

Model-View-Whatever, the Plus engine for Sciter.

Preface

I would say that human history is a history of reinventing "wheels" of various kinds.

This time we see concept of data binding reincarnated with slightly pathetic name Model-View-Controller. Of course, as many people as many meaning they give to the MVC abbreviation but, nevertheless, it is all around basic idea of data binding – you have data (the Model these days) declaratevily bound with UI "controls" (the View). I believe Microsoft’s VisualBasic 4 and its IDE was the very first usable implementation of the idea. There was no Controller concept at that moment so their implementation was quite limiting – while you can implement 90% of your data editing needs using simple declarations you will spend 90% of your design time fighting with the rest of 10% of needed functionality.

The Plus framework for Sciter.

The Plus framework you can find in Sciter SDK is quite compact (400 LOC) and relatively simple implementation of that old data binding concept with controller means.

Note, the Plus is not an attempt to solve every html/css/script UI problem as AngularJS does. It is just a data binding mechanism with the concept of @observing functions (controllers in my interpretation).

Basics

Model in Plus interpretation is some tiscript namespace object that contains data variables (and optionally functions) to be bound with particular container in HTML DOM.

For example if you declare this script: 

namespace Data {
  var correspondent = "world"; // variable to be bound
}

and corresponding markup:

<section model="Data">
   Whom to greet: <input name="correspondent"> ?
   <p>The greeting: Hello <output name="correspondent">!</p>
</section>

and include in your document "plus.css" file you will get live data binding between Data.correspondent data variable and two DOM elements: two ways with input[name=correspondent] and one way (only view) binding with output[name=correspondent]. So when you type something in that input you will see the data also rendered in output element.  To see this alive load sdk/samples/+plus/demos/0-basic-variable-binding.htm in sciter.exe from its SDK.

The model and name DOM attributes.

Note that <section> element contains model="Data" attribute. It instructs the Plus engine to establish data binding between content of this section and members of namsepace Data {} in script. Name of the bound namespace can be any suitable, not just Data.

Any DOM element inside that section[model] may have name attribute defined. On binding initialization the Plus will try to find data element in the model with that name and if such data variable is found it will made two or one way (for <output> elements) binding between .value of that DOM element and the data variable. The name can be compound – may contain ‘.‘ (dot)-separated list of names. This way  you can bind DOM elements with object fields inside the model: 

namespace Contact {
  var name = { first: "Albert", last: "Einshtein" };
  var phone = "....";
  ... 
}

and markup:

<form model="Contact" id="contact-details"> 
  <label for="name.first">First name></label> <input name="name.first">
  <label for="name.last">Last name></label> <input name="name.last">
  ...
</form>

Celsius to Fahrenheit convertor.

Controllers, the @observing function decorator.

File plus.tis (the Plus engine implementation) contains declaration of function decorator named @observing. With that decorator you can define functions that will be triggered (called by the engine) when variable(s) they are observing change.

As an example let’s define simple Celsius to Fahrenheit conversion tool that should work in two directions – when you define celcius value it will calculate its fahrenheit representation. And vice versa. Something similar to the form on the right:

First we will define our Data namespace:

      include "../plus.tis"; // model below uses @observing decorator defined in plus.tis  
      namespace Data // our model
      {  
        var celsius = 0; 
        var fahrenheit = 32;
        
        // this function is observing 'celsius' and calculates 'fahrenheit'
        @observing "celsius"
          function toFahrenheit() {
            fahrenheit = celsius * 9 / 5 + 32;
          }
        // this function is observing 'fahrenheit' and calculates 'celsius'
        @observing "fahrenheit"
          function toCelcius() {
            celsius = (fahrenheit - 32) * 5 / 9;
          }        
      }

Note two functions above: function toFahrenheit() is observing celcius variable. When celcius variable will change, for example as a result of changes in <input|number(celsius)> field, the toFahrenheit() function will be triggered and will set value of fahrenheit variable. As we have another input bound with the fahrenheit variable: 

<body model="Data">
  <p><input|number(celsius)>°C and <input|number(fahrenheit)>°F</p>
</body>

we will see in it results of calculation. This works in both directions – from fahrenheit to celcius and from celcius to fahrenheit.

To see this alive load sdk/samples/+plus/demos/1-basic-function-binding.htm sample in sciter.exe.

That’s it for now. In the next article I’ll explain use of repeatable attribute to bind arrays of objects with rpepatable sections and other samples. If you don’t want to wait check other samples in sdk/samples/+plus/demos/ folder of the SDK. They are self descriptive.

MVC or not MVC? The Formation Engine for jQuery

Various JavaScript frameworks provide data binding facilities (Knockout, AngularJS, etc.) these days.

They are based on kind-of-MVC concept: you have some data (structure, model), view rendering that data in html and some code in between that commonly named as controllers.

How successful/convenient those frameworks are subject of separate topic. For me they are too intrusive I would say. On some views/pages they make sense, on others final solution looks too ugly.

Anyway, here is an alternative idea…

Instead of separating data structure and its view we simply can create construction that is a data model and its view at the same time 🙂

I named that magic “construction” as Formation. Formation is essentially a collection of DOM elements organized in a tree that reproduces structure of the data (or model if you wish). Value of the formation is JSON data structure – the model per se.

Consider this example

Here you see collection of inputs and subsections (on the top).
On the bottom/right corner you see the Formation tree created of <section#inputs> container.

On the left you see live data of the Formation (editable textarea). Changes there reflect state of elements. In the same way changes in inputs reflect text in this textarea.

The Formation implementation does two major things:

  • creates formation trees and
  • initializes custom DOM elements (check that in HTML source – that friends list).

Couple of words about custom elements support in formations:

When formation sees custom DOM element ( any DOM element with tag name containing ‘-‘ inside ) it tries to find its initializer in registry of jQuery plugins – that famous $.fn collection. And calls it if it was found. You can check js/jquery.list-input.js – it is normal jQuery plugin with the name matching that custom element tag name: “INPUT-LIST”.

To create/get formation of some container you can call either

  1. global [window.] formation( domel_or_$_wrapper ) function or
  2. $(selector).formation() plugin.

You can store created formation in some variable and access DOM elements in it in quite effective manner:

var inputs = $("section#inputs").formation();
$(inputs.firstName).on("change", function() {...});

Accessing formation members directly is faster than accessing them using jQuery selectors as these are just direct references.

You can download complete sample to play with from here.

Future Formation plans: to implement so called repeatable formations, so if you have this markup:

<ul repeatable name="stockItems">
   <li><output name="name">  <output name="price" type="currency"></li>
</ul>

and will feed it (through formation) by this data:

[
  {name:"Apple", price: 1.05 },
  {name:"Orange", price: 0.52 } 
]

it will render two <li>s in the list.

Another ng-inspired idea is to have class switches as Formation elements, this class declaration:

<div class="{someSwitch:collapsed|expanded}" >...</div>

will cause corresponding formation to have element named “someSwitch” that can be assigned false/true or 0|1 values to change class to either <div class=”collapsed”> or to <div class=”expanded”>…

UPDATE: see discussion about the Formation on jQuery forum : forum.jquery.com/topic/mvc-or-not-mvc-the-formation-engine