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/

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?

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.

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

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...

> 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".

Tauri, Sciter and Wails, three electron alternatives are now on spot 1,2 and 3 on hacker news.

If you need ideas for your tech blog, let me recommend doing a post comparing the 3 :)

The only one missing now is Electron and we'll have a real battle :)

Besides shipping vulns, what category is Electron beating the rest in? Genuinely curious.

I'm in no way a fan of Electron and much rather use Tauri. But if you want something proven, wildly deployed and with the biggest community/potential support, then probably Electron is the best currently, just because of how old it is.

On the other hand, this isn't some web page you distribute everywhere an hope it's compatible. Those engines are self-contained, so if your application works, it works.

That’s correct for Sciter, but Tauri uses the OS’ browser engine, so you’re back to the hostile environment / unknown territory of the web.

People say this about using Apache as a webserver; I understand it, but don't know if I agree with it.

I'm running Apache for all my services and it's totally fine. It does everything I need and since I'm not running Fortune 500 websites or anything performance is more than enough. If it works, I don't need with it.

I'm not particularly risk-averse myself either, so I don't agree with it either. But I do know some are, so those seems to be the arguments in favor of Electron from that perspective.

Just a personal anecdote, I work in an industry that is extremely risk averse. I still use 300 baud modems every day. Apache is new-fangled nonsense.

300 baud modems? Over analog lines, VoIP, HF radio or what elese? Supposing it was not just an ironic answer, I would be pleased to know more about this!

Electron is irreplaceable if

- you want to cut the dev cost on support all platform - maybe MOST important

- you want Browser like feature - embed webview not iframe

- you want to make sure the feature is there, if you can not polyfill

Memory is cheap, download size is cheap.

See the sibling thread: https://news.ycombinator.com/item?id=31765784

Guess we’re doing a “web UI on the desktop” morning on HN, huh?

Sciter has always been near the top of my list of tech I want to play around with. Last I saw the creator was working to get a JS runtime attached to it which might finally be the thing to motivate me to try it out.

sciter is good if you are looking for make an app based biz which not depends too much on web spec.

BTW, sciter only allowed dynamic linking for free use, the binary is close sourced. https://sciter.com/prices/

cross comment https://news.ycombinator.com/item?id=31764929

The SDK and the webview links on gitlab have a BSD3 license.

I think that very confusing prices page isn't saying what you think it is (when I read it, I thought it too).

What’s really useful in most of the desktop UI frameworks is not so much the declarative design language but the “designer” type tools which come with them for .Net, QT, etc. Is there a similar tool which comes with a set of common components that you can use to layout the design and then just change the CSS/HTML for more advanced styling requirements?

In the 90's there was a small app called "InfoCourier" which was an "HTML Compiler" which allowed you to create a local website in HTML and then turn it into a windows exe file.

Nowadays, it's called react-native, you get HTML like compiler to a windows/macos exe.

It looks like windows is supported, but I couldn't find anything non-experimental for MacOS. Is MacOS still officially supported by react native?

Edit: I just found this https://github.com/microsoft/react-native-macos . So Microsoft is officially supporting react native on macos? That's pretty ironic haha.