Hacker News Reader

Comment by e1g | Hacker News Reader

Note, Sciter does not embed a browser engine but reimplements the DOM/CSS/JS (via QuickJS) logic in C++ which means many familiar web patterns will work, many will not, and many might behave differently. Unlike Electron, Sciter will not be the best option to wrap an existing web app and expect it to work as a desktop app.

Partial compatibility tables are at https://sciter.com/developers/for-web-programmers/

View on HN

Honest question: how is ”reimplements in C++” different from implementing their own browser engine?

Is it purely the absence of a JS virtual machine and instead compiles JS code directly to C++ and into native code?

It does have a JavaScript VM, just slower (QuickJS as compared to electron's V8).

So what's "Quick" about it? Would having a slower JS engine be outweighed by some other savings? Honestly, the biggest one is memory... Electron is the biggest memory hog I've ever seen, ONE application slows my 16GB macbook to a crawl and it starts swapping to HD. How to stop that?

It's "Quick" in the sense that it's a bytecode interpreter instead of a heavyweight JIT, so much faster startup times (although overall compute performance is much slower). And the library is much smaller than more heavyweight engines like V8, so good for reducing overall app size.

Recently Facebook had to implement a whole new non-JIT Javascript engine just for the purpose of optimizing startup times for React Native apps (https://github.com/facebook/hermes). If you consider how even Facebook had to ditch the V8 JIT for their purpose it's totally understandable why Sciter chose QuickJS as their new Javascript engine.

If it's ONE application why do you jump to the conclusion it has to be electron's as opposed to the actual application's fault?

Electron has some baseline overhead (~100 MB RAM IIRC), but otherwise it's not difficult to write well behaving applications with it.

An Electon app simply uses much more memory than a native one, there's no way around that...

Yes, and the difference is the maturity of the engine. For example, to execute JS files Sciter uses QuickJS which runs ~20-30x slower than V8 JIT [1] and has no support for Intl [2]. Sciter's spin on HTML/CSS is also different [3], which might even be better than the standard DOM/CSS, but different means you're coding specifically against the internals of this packaging/distribution method.

[1] https://bellard.org/quickjs/bench.html

[2] https://test262.report/?engines=v8%2Cqjs

[3] https://sciter.com/tutorial-learn-sciters-html-components-in...

> Sciter's spin on HTML/CSS is also different [3]

Hmm, that was new to me and quite disappointing TBH. I thought the entire point of an embeddable web rendering component is to leverage existing "standards"/practices, especially CSS' out-of-this-world complexity. Why would anyone in normal mental health condition embrace HTML and CSS for coding apps if the result can't even be used in browsers?

I had counted Sciter towards browser implementations; but now I see it does nothing to prevent our fall into a second medieval age once no-one understands the job-security machine that is CSS. What an utter piece of garbage CSS is, counter to the entire point of using markup.

> different from implementing their own browser engine

Because sciter (at least as I understand it) does not have any intention to be a general browser. It intends to be an application development framework, and is quite happy to behave differently to browsers if doing so aids in that goal.

Sciter is like React Native with extra Web like feature and a more flex "jsx".

Reply on news.ycombinator.com