Neutralino – Electron alternative powered by C++ | Hacker News Reader

Neutralino – Electron alternative powered by C++

neutralino.js.org

61 pointsnomdep11 comments

The name Neutralino comes from supersymmetry theory and it is neutral particle (electric charge is zero) but if the naming is just saying we are better than electron and should be the modern alternative one that will replace it, then the more suitable name would be selectron (electron superpartner and it is a boson!). But that would be confusing I understand.

PS: I hope that this is really better than electron because I hate all electron apps and the desire for many developers to use it to deliver multi platform apps. It is buggy, resources monster and doesn't work consistently.

It's also bad name because the neutralino is a candidate to be a WIMP, and nobody wants a wimpy framework.

This looks incredible. As an avid Electron user, I have often wondered if there were more lightweight and performant alternatives. The only drawback I can see is that since it uses the “existing web browser library in the operating system (Eg: gtk-webkit2 on Linux)” there may not be any bundled (and familiar) debugging tools, but I will definitely try this out.

I don't think it makes much sense to use these frameworks which rely on the native OS browser API's. One of the most important things when shipping an app is determinism and knowing that your app will remain working after you ship it. We have that with the likes of Electron, but with the OS embedded browsers they can ship an update which breaks your app (or even just subtly alters the styling), plus it introduces an increased testing burden on the developer because now they need to ensure it behaves the same across all different OS integrated-browser implementations.

It's not such a big deal if you're doing something akin to a typical web-app, but if you're doing something very unique the little inconsistencies across browsers can be an annoyance that isn't worth dealing with.

While not perfect, the web platform is pretty damn backwards-compatible, which is why sites using frames and table layouts still render fine. There's also feature detection to engaging code only when a API is supported too. I'd argue it's better to assume this will be good enough instead of shipping another browser just to be 100% sure—space and bandwidth aren't free.

The web may be backwards compatible, but the engine in the OS (e.g, WKWebView on macOS) may not see security updates and bug fixes past a certain point.

In contrast, Electron will "just work" and can be deployed pretty far back in comparison.

Just as much, many Electron-based applications aren't keeping their own engines updated and shipped.

The rest starts to get philosophical: on Linux, BSD, or other libre OSs, these WebViews do get upgraded for usually a devices entire lifespan (unlike Android) and users are usually more confident in their OS's update system and maintainers to regularly do updates. Of course, you could always make it purely a PWA and pressure the likes of Mozilla to actually support hosting these sorts of apps for OSs (RIP SSB).

It’s a bit of a myth that those get upgraded. They lag significantly behind Electron (Chromium) attention-wise.

By the way, wouldn't QtWebEngine be a much nicer 'native' provider for webview? It's actually Chrome, not WebKit, is available on all platforms. Both on Windows and Linux you need to install a webview provider anyway, so why not this one?

Webviews are not alternatives to electron. If your software works in a WebView, you don't need electron. And if it doesn't work in a WebView, you can't use webviews.

I imagine this is only available on SUSE?

Reply on news.ycombinator.com