My Sciter[1] Engine has two versions

1. Sciter.JS, with QuickJS, mainstream version now.

2. And former Sciter.TIS - uses my own TIScript. TIScript uses moving/compacting GC (close to V8).

We have several products ported [2] from TIS to JS already. I am not registering increased memory consumption but quite contrary sometimes.

In some cases deterministic reference counting schema is beneficial in UI, like:

    function Foo() {
      var nobj = new NativeObject();
      nobj.dosomething();
    } 
    // QuickJS will destroy nobj at exit from the function

[1] https://sciter.com [2] https://terrainformatica.com/2022/02/19/freeconferencecall-a...

Does this ship an exactly pegged version of WebKit like Electron or does it use whatever the host system provides?

Sciter does not use website at all, nor any HTML engine provided by the host OS. It is itself an entire HTML,CSS,JS engine.

Well, roughly-HTML, almost-CSS and fairly-but-not-completely-JS. Historically, TIScript was the biggest problem for web compatibility, being very web-incompatible, but even the QuickJS version is already incompatible with the web in a couple of ways. And its fork of CSS doesn’t implement things like Flex and Grid, but rather something proprietary with similar scope, some advantages, some disadvantages, but mostly just different which I would say is generally a bad thing.

which is fine. The goal is to make *cross-platform* Desktop GUIs that is also light weight. I think Sciter can define a subset of html|css|js and provide some syntax checker(e.g. this feature is not supported). For Desktop GUIs we don't need all those web APIs etc. Sciter is super light weight comparing to Electron and Tauri.

You very regularly would like cross-platform desktop apps to work on the web as well, or at least to be able to share significant chunks of code. Given that, the fact that Sciter isn’t actually HTML/CSS/JS but rather a superset of a subset of each becomes very notable: you certainly won’t get total code sharing, and you’ll probably even struggle to get significant UI sharing.

I think sciter is not electronjs per se, it does not do web rendering, instead it uses html/css/js for Desktop(no internet) development, to replace say Qt-based GUIs.

Tried it a while ago, pretty decent.

As I recall, the only major advantage of QuickJS is that it can run on machines where v8 couldn't dream of fitting.

Data sizes almost always exceed the size of the code itself. I wouldn't consider it surprising that the IR would fade away into the noise.

V8 can also make tradeoffs that QuickJS probably cannot. For example, v8 internally represents strings as 1-byte latin-1 characters rather than 2-byte UCS-2. This halves memory consumption, but adds a lot of code to the implementation that a microcontroller running QuickJS may not have room for.

It’s really interesting to hear your performance issues with QuickJS there.

I found an opposite sort of performance profile (few small values on the stack, shallow stack size) with lots of calls back and forth between C and JS worked really well. Or, a lot of situations outdid V8 and ChakraCore for me (with JIT disabled). I didn’t dig into the exact reasons why though.

It's possibly related to the size of the JavaScript bundle being used. In my case it was 4Mb of minified JavaScript being evaluated (React Native with a bunch of dependencies).

another interesting proof of concept: https://github.com/engine262/engine262