Sciter+Node versus Electron


As we know Electron.js is built of Chromium and Node.js. Where Chromium is a full scale Web browser that even uses its own, independent JavaScript engine.

Therefore each Electron.js application is essentially a separate Web browser and Web server installed on your machine – as many Electron applications you are running – as many browsers and servers you have in your RAM. Yet each Electron application runs at least three separate processes on your machine.  

But what if to replace Chromium in Electron by Sciter?

To answer this I’ve created very basic Sciter as NodeJs native module.

In order to get some stats I’ve compared Microsoft Visual Code, as typical Electron.Js application, with the “IDE” sample from Sciter’s SDK that has similar UI structure:

sciter.node – Sciter IDE demo

Here are some numbers for you to consider:

Distribution size (zip)12mb60mb5 times smaller
Size on disk15mb90mb6 times smaller
RAM consumption50mb318mb6 times less
N of processes188 times less
Startup time34ms670ms12 times less

I think the numbers are at least motivating.

Ideal Sciter / Node integration model

Sciter is made of the following modules: HTML, CSS, Graphics, Script compiler and VM, libUV and script runtime.

And NodeJs is essentially V8 script engine, libUV plus script runtime. 

So ideally sciter.node is just HTML, CSS, Graphics modules of Sciter compiled into NodeJs statically – it will use JavaScript instead of Sciter’s Script and common libUV. But that will be not Sciter nor NodeJs but something else at the end.

20 Replies to “Sciter+Node versus Electron”

    1. I am happy that it “works on your machine” ™.

      You can share your memory with people from China and India for whom I am forced to support Windows XP.

    2. Also, if it takes 90 mb for one application, how many such applications can you run at once?

      Also apply the same logic to when the usage is 1gb per application. That makes us think.

    3. Yeah, why care, we the careless people don’t mind exercising all the running we can do just to keep in the same place.

      Mark my words, “I didn’t care” will be the epitaph on the tombstone of this ‘civilization’

  1. I like the idea a lot.. the resources consumption comparison tho’ it doesn’t come close to being fair.. a simple Hello World would’ve been better.

    1. It is fair in the sense that 80% (YMMV) of Electron features is not used by any given application. Why do you need WebGL implementation to be present in the code of your text editor? Compare Sublime with Visual Code. Sublime also uses it’s own DOM + script for plugins but it takes 30mb of RAM versus 300mb in case of Visual Code.

      If to compare pure Sciter solutions then versus – both are capable of Markdown editing. Typora is an Electron application. Ratios are the same – Typora consumption metrics are 5-6 times larger than they should.

  2. Hi Andrew,

    thanks for sharing, and good luck with this project!

    I’ve been thinking about using Node.js and Sciter UI after participating in a similar project Thorium. Unfortunately that project was experemintal and had no further development.

    As a former HTMLayout user, I would happy to help you anything related to V8 and Node.js naitve addons. I’ve been using embedded V8 this way since 2011 in various projects.

  3. that’s amazing…really.
    im wondering if u could do a variant with whitespace-sensitive syntax throughout (script, html, css) similar to coffeescript (or the icedcoffescript) and jade for css? or even better, a totally new language that is a cross between your script and erlang but still no end-of-the-line punctuations. that would be very nice, indeed. hopefully.

  4. QuickJS just arrived…

    So what about marrying it with h-smile core (engine used in Sciter) ?

    So this is about SciterJs – version of Sciter where tiscript is replaced by QuickJS …

    If someone is interested – let me know.

  5. If Sciter can replace Electron, e.g. for Ionic + {Angular,Vue,React}, you will have a killer app for making multi-platform desktop apps. It is a huge opportunity, as currently desktop side of Ionic is very much neglected. Laptops still sell a lot of units/year and developers need a single codebase approach to Web+Mobile+Desktop. Any serious app (think Slack, Netflix) need desktop presence.

    (I know this thread is old, but the benefits are still very desirable)

Leave a Reply

Your email address will not be published. Required fields are marked *