WPF vs Sciter


WPF Sciter
Definition Windows Presentation Foundation (or WPF) is a graphical subsystem for rendering user interfaces in Windows-based applications by Microsoft. Is an embeddable graphical user interface engine (dynamic or static library) by Terra Informatica Software.
Released 2007 as part of Windows Vista. 2006 – h-smile core release date (HTMLayout, Sciter1, Sciter2 and Sciter3).
OSes Microsoft Windows Microsoft Windows, Mac OS X, Linux/GTK.
Technology .NET Framework 3.0 and above. Only managed API. Native code with native plain C API.
Distribution WindowsBase.dll, PresentationCore.dll, PresentationFoundation.dll (without .NET core) ~ 5 Mb Single sciter32/64.dll ~ 4 Mb
UI Architecture XAML DOM tree W3C compatible DOM tree.
Markup language XAML HTML5 and SVG.
Style language XAML, no cascading CSS – cascading style sheets.
Code behind UI .NET languages tiscript (JavaScript alike, built-in), C, C++, Delphi
Data Binding XAML data binding: one-time/one-way and two way
  • built-in string interpolation via stringizer functions;
  • kite – {{mustache}} alike template engine;
  • +plus – AngularJS alike two-way bindings based on Object.observe();
  • +vlist – one-way, virtual lists bound with arrays of records.
Media services vector and raster images, audio, video vector (SVG) and raster images, video with audio.
Graphics WPF rasterizer on top of DirectX.
Platform graphics:
  • Windows – Direct2D on top of DirectX
  • OS X – CoreGraphics
  • Linux – Cairo
Graphic primitives 2D graphics along with brushes, pens, geometries, and transforms.
  • All standard CSS primitives including filters and transforms.
  • <canvas> alike graphics primitives for immediate mode drawing along with brushes, pens, geometries, and transforms.
Templates Look of an element can be defined directly, via its properties, or indirectly with a Template or Style. Look of an element can be defined directly, via its style properties, or indirectly via style sheets. Structure of elements can be "templated" by Behavior classes (native or in script) and Aspect functions and applied to elements via CSS – properties: behavior, prototype and aspect.
Animations low level animation via timers and higher level abstractions of animations via the Animation classes. CSS transform property based animations, timeline (TweenLite alike) animation engine, low level animations via Element.animate().
Printing Supports paginated documents via DocumentViewer class. <frame type="pager"> supports print preview and printing of paginated HTML documents. Supports CSS page-break-after/before/inside properties.
Accessibility Microsoft UI Automation Microsoft UI Automation on Windows.

BlockNote on KickStarter

blocknote2

I have started BlockNote campaign on Kickstarter

That is about funding of BlockNote2 development: WYSIWYG HTML editor for the rest of us that will work on Windows, Mac and Linux.

BlockNote editor was free last 10 years and if you have found it handy please donate if you can. Each river starts from a small stream.

As a part of this campaign I am also offering discounts (up to 50%) for Sciter license and source code access. And yet advertisement spots on BlockNote front page. Note: that space and number of offerings is limited.

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.

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.

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.

Graphin engine

I have started Graphin.dll project – portable and compact graphics engine based on AGG (agg2d in particular).

Graphin url is code.google.com/p/graphin

API mimics Graphics and Image objects but in plain C. In principle this is close to the <canvas> from WHAT WG .

Graphin.dll includes also pnglib/zlib and jpeglib with the ability to load and save image object to/from byte vectors (and so mm files) as png/jpeg.

Intention is to have graphics engine that is portable and simple to use. With Graphin it should be possible to reproduce <canvas> functionality
in any language/environment.

There is nothing spectacular yet there but structure is established and couple of methods like graphics_rectangle, graphics_line, etc are written.

Graphin is based on agg 2.4 and contains that agg2d thing written by Maxim Schemanarev .

agg2d class was ported by Jerry Evans from agg 2.3 and contains fixes made by Maxim, myself and Pavel Korzh.

New members of the project are very welcome.

I am planing to use Graphin as graphics backend of multiplatform versions of htmlayout and sciter.

Update: here is a screenshot of Graphin Demo project.
Graphin Demo