
NeutralinoJS: Lightweight Electron alternative using native browser controls - api
https://neutralino.js.org
======
derefr
I feel like nobody cares too much if they’re running _one_ Electron app;
people do have the headroom for an extra 1-2GB of RAM usage. The problem comes
when they run _several_ Electron apps at once, and each comes with its own
“base” overhead (i.e. the runtime memory consumption of the browser-runtime as
a whole, independent of how many render contexts are open.)

Chromium is built to share a lot of things between tabs efficiently, but this
economy-of-scale doesn’t translate over into having multiple instances of
Chromium running. Each instance gets its own GPU renderer process + font-glyph
tile cache, its own network-request cache (i.e. its own in-memory key-value
store with its own LRU limit), etc. Running multiple Chromium instances at
once is a bit like running multiple copies of an RDBMS on the same machine and
expecting them to not fight over memory.

Does anyone know what exactly this “base” overhead in Chromium consists of;
and, more importantly, how often it changes relative to Chromium releases?
Because I’m wondering whether it’d be possible to factor most of it out into a
separate layer from the highly-iterated-on “browser engine” DLL stuff (the
renderer + DOM + JS layer) into its own sort of “Chromium Core Services” DLL,
which could be relatively-more ABI-stable.

If you had that factoring-out, you could achieve a pretty good memory + CPU
savings just by having Chromium + application frameworks like Electron all
share one copy of the Chromium Core Services between them, while keeping their
own higher-level “renderer+VM” DLL on top (which would hopefully be pretty
stateless in terms of shared state, only adding the ~50MB mmap(2) overhead of
the DLL-image itself, and then whatever memory the individual render-contexts
consume.)

Alternately, of course, you could build Electron as a pseudo-browser where
Electron “apps” are just separate windows running in its memory space, and the
native Node processes are all just distinct V8 Execution Contexts in the same
process. But 1. this would lose you the ability to develop for a particular
version of the renderer, which is what Electron gains you over projects like
Neutralino in the first place; and 2. this wouldn’t give you the benefit of
Electron sharing service-memory with Chrome itself.

~~~
zelly
Given that everyone brings this up every time Electron is mentioned, and
Electron apps keep proliferating, I expect a future version of Windows and
macOS to have Chromium bundled with the OS. There will be some platform
independent open standard that Electron will use under the covers.

Native desktop apps are never coming back. It will either be Electron or
mobile apps emulated on desktops.

~~~
chipotle_coyote
Behind my two Safari windows is the text editor I use for my technical writing
job: BBEdit, a native desktop app. (For coding, though, I prefer to use
MacVim, a native desktop app, although I've lately been trying out a beta of
the forthcoming Panic Nova, a native desktop app.) I also use Marked, a native
desktop app, for Markdown previewing occasionally. Of course, I spend a lot of
time in the Terminal, a native desktop app, running command line programs and
shell scripts, which are not native desktop apps but are certainly native
apps. When I need to run a diff or merge tool, I tend to use Kaleidoscope, a
native desktop app. Because I'm in an open office, I sometimes have to resort
to headphones, which I primarily use with iTunes, a native desktop app.

Now, as I finish up this response to you in Safari, a native desktop app,
remind me what were you saying about native desktop apps again?

~~~
derefr
Offtopic, but if you’d like an elegant hybrid† Markdown viewing/editing
experience, I’d suggest [https://typora.io/](https://typora.io/), another
nicely-polished low-memory-consumption native app.

† I don’t know what to call this editing paradigm. It’s somewhere between
source-editing and WYSIWYG. Document markup nodes are rendered as their source
syntax when your cursor is “inside” them, allowing for plaintext modification
of the syntax; but then, when your cursor leaves a node, it switches to
rendering as its formatted output instead. You can cursor back into the node
to edit it more at any time. It’s pretty unique. It’s the editing style that
Slack’s new input box wishes it had.

~~~
disqard
I use Typora myself, but it's definitely an Electron app (neither native, nor
lightweight).

[https://support.typora.io/What's-New-0.9.66/](https://support.typora.io/What's-New-0.9.66/)

------
gigel82
I see projects like this pop up every once in a while and get abandoned.

A simpler approach may be to just publish a basic web server as your app
(express on top of node would do) that runs on the local machine on some
random port and have users just go to that URL with their regular installed
browser. Bonus points for no leakage of security / CORS / etc. issues from the
UI side of things, every unsafe thing needs to be node-side where it can be
better controlled. Also enforces asynchronous and efficient communication
between the UI and the "local backend".

~~~
throwlaplace
Does the browser really have access to all the same apis as electron? Doesn't
electron have broader access to the file system (e.g. all the stuff that
vscode does).

~~~
tlavoie
What the parent posted is stating is that the local web server has that
system-level access, which the browser doesn't need in order to access the
app.

The "back end" web server can be running on whatever language stack you like,
be it Go, Rust, Haskell, Common Lisp or whatever. Syncthing is one example,
where it's nominally headless, but there is a local web server that can be
pulled up to set preferences, monitor status and so on. Works great.

~~~
throwlaplace
oh yes you're right. i got confused for a moment. thanks!

------
hamaluik
Looks kind of like WebView [1] which I earnestly tried but eventually
abandoned. Using the system-provided web engine is great for space savings,
but terrible for cross-compatibility and feature availability owing to having
to use IE on Windows.

[1] [https://github.com/zserge/webview](https://github.com/zserge/webview)

~~~
valdiorn
Isn't the "system provided web engine" now Edge on Windows 10, and has been
fore a while?

~~~
hamaluik
AFAIK, there's a difference between MSHTML (internet explorer) and EdgeHTML
(edge / trident). But even then, Edge can be somewhat lacking depending on
your use case [1]. For simple apps that just need a simple UI without spending
time developing cross-platform, this solution is great! Unfortunately the
projects I've had to develop require newer features and/or performance lent by
using the Chromium Embedded Framework that simply aren't possible, even if
Edge was available.

[1]
[https://caniuse.com/#compare=ie+11,edge+12,chrome+80](https://caniuse.com/#compare=ie+11,edge+12,chrome+80)

------
Sephr
> There are some drawbacks such as Windows edition is based on IE etc.

This alone is a major reason to use Carlo[1] instead, which is arguably more
secure (by virtue of not using IE) and produces even more lightweight bundles
than NeutralinoJS.

1\.
[https://github.com/GoogleChromeLabs/carlo](https://github.com/GoogleChromeLabs/carlo)

~~~
jamesgeck0
Is Carlo maintained? The last commit in master was eight months ago.

~~~
paulirish
It's not.

(I was part of the team that launched it.)

------
rcarmo
Doesn't work on Mojave for me, since it's apparently linked with 10.15
libraries:

    
    
        ./neutralino-mac  
        dyld: lazy symbol binding failed: Symbol not found: __ZNSt3__14__fs10filesystem14__current_pathEPNS_10error_codeE
          Referenced from: /Users/rcarmo/Downloads/New Items/neutralinojs-v1.3.0/./neutralino-mac (which was built for Mac OS X 10.15)
          Expected in: /usr/lib/libc++.1.dylib
    
        dyld: Symbol not found:  __ZNSt3__14__fs10filesystem14__current_pathEPNS_10error_codeE
          Referenced from: /Users/rcarmo/Downloads/New Items/neutralinojs-v1.3.0/./neutralino-mac (which was built for Mac OS X 10.15)
          Expected in: /usr/lib/libc++.1.dylib
    
        zsh: abort      ./neutralino-mac

------
pjmlp
This is the correct way of doing it when a PWA doesn't cut it.

No need to push a full browser engine when the OS already has enough of them
available.

~~~
robbick
It definitely is the 'correct' way of doing it, but it will mean you use IE
when in windows, which is often/normally not the correct way

~~~
pjmlp
We still need to support IE 11 on our projects anyway.

Welcome to the corporate world.

~~~
kirubakaran
> We still need to support IE 11

Not all of us. I'm happy to lose the 2.16% [1] in return for saving a lot in
time and effort.

[1]
[https://www.w3counter.com/globalstats.php](https://www.w3counter.com/globalstats.php)

~~~
pjmlp
Lucky you, I usually do internal corporate applications.

------
Mikho
If you want anything from the web to work on Windows as native why not just
use PWA utilizing Microsoft's (1) own PWA Builder (2) including the
availability of proper debugging tools and acceptance in the store? It doesn't
matter what tech it uses. The more important thing is it will be supported and
updated. There won't be any surprises.

(1) [https://developer.microsoft.com/en-
us/windows/pwa/](https://developer.microsoft.com/en-us/windows/pwa/) (2)
[https://www.pwabuilder.com/](https://www.pwabuilder.com/)

~~~
kbumsik
But it works on only Chrome at the moment. Firefox or Safari users wouldn't
install Chrome just for your PWA.

~~~
Mikho
What are you talking about? Read my comment. You have stand-alone native-like
app that Microsofts creates for you from your web service. The app could also
be installed directly from the Windows Store. No browser required at all.

------
nablaoperator
Why is it called `Neutralino`? As a supersymmetric partner it's much heavier
than the Standard Model particles.

~~~
lisper
Neutrino was taken:

[https://neutrinojs.org/](https://neutrinojs.org/)

------
catchmeifyoucan
WebWindow is another library that takes the same approach. It's still in
progress but is very promising. It was very easy to get running when I tried
it last.

[https://github.com/SteveSandersonMS/WebWindow](https://github.com/SteveSandersonMS/WebWindow)

------
iamleppert
A hello world Electron app uses about 50 MB of memory.

The problem with Electron apps is not so much Electron or Chromium but how
they are designed & developed. Most developers view memory optimization as an
after-thought. This is especially true for multiple document interface
applications. The tooling is all there to monitor and optimize memory, but few
make real memory budgets part of their build & integration testing process.

Developers have 16-32 GB of memory (or more) workstations and typically work
on individual features that don’t exercise the edge cases of large datasets.
They don’t bother to implement proper LRU mechanisms, paging, and often do
performance optimizations that sacrifice memory for speed.

It gets worse if they aren’t forced to dog food their own creations or aren’t
users of their app themselves.

------
anonsivalley652
Stupid question: instead of embedding an entire browser in each-and-every app
and trying to keep that secure, why not package the native desktop framework
as a shared, versioned component and the app as a tiny thing that depends on
it?

~~~
simias
I'm generally pretty old school when it comes to development practices but I
can totally understand how appealing it is to effectively ship your entire
environment as part of your application instead of relying on shared
dependencies. Dealing with dependency incompatibility is a _huge_ maintenance
burden in my experience, and it's super tricky to debug if you don't have
access to the problematic environment (which is most of the time if you deal
with public projects).

That's why I really try to get into docker for instance, sure good old unix
sysadmin and configure scripts might arguably be more elegant and efficient
but it's a huge pain to maintain and can (and eventually will) break out the
blue after a system update because of a regression in some obscure library.
Meanwhile docker images should work mostly everywhere without any effort and
you only update your dependencies when you want to update them.

So now that storage is cheap and RAM is plentiful I think shipping the
dependencies as part of the executable is a reasonable approach most of the
time. The problem with electron is that the dependencies involve a full web
browser and half a trillion libraries. That's the insane part. I have full
python virtual envs for non-trivial apps that are a fraction of the footprint
of an electron hello world. It's the core technology that's broken, not the
packaging.

~~~
derefr
I think the grandparent comment is envisioning something more like Docker than
like e.g. the JRE.

This is actually already how the Microsoft Visual Studio C Runtime (aka
MSVCRT) is distributed: each application embeds or streaming-downloads the
_exact_ [ABI] version of the runtime it needs, but only one of each exact
[ABI] version of the runtime needs to exist per system, and each of those
runtimes can be upgraded by the OS to resolve security problems (while never
altering the ABI guarantees that version distribution makes.)

As such, a runtime built this way is a lot like a base layer in a Docker
image: it’s a static dependency of the app, installed during the app’s
installation, and held in a pseudo content-addressable store that deduplicates
it from other apps’ demands for the same dependency.

~~~
NullPrefix
>each application embeds or streaming-downloads the exact [ABI] version of the
runtime it needs

Except when they don't. Took me way too long to accidentally install the right
redist to have fn-key OSD (volume up, mute, airplane mode, et cetera) on my
ThinkPad.

Because why bundle it with the drivers? No error messages either. Just mash
the buttons and have no visual feedback.

------
clownpenis_fart
using the word "lightweight" to describe anything involving js and an html
renderer should be prohibited

~~~
t0astbread
I wonder why. Given the popularity of HTML you'd think some large organization
would've developed a reasonably fast _and_ memory efficient browser engine by
now but everyone seems to be aggressively optimizing for speed.

~~~
tasogare
Bloated specs with tons of historical cruft and edge cases. And a renderer
needs to support it all. The problem stems from trying to use something
designed to share documents with some custom styling as a universal GUI for
applications instead.

------
antoineMoPa
So if I understand right, what makes this lighter than electron is the fact
that only webkit2 is used instead of embedding the whole chromium app.

~~~
jacobush
I don't understand, it seems like it runs in any browser? Are they using
webkit2 as a replacement for node and the system browser for the GUI?

~~~
antoineMoPa
It seems to me that the Javascript runs in the client.

The Javascript side calls the system via the local network, passing through
this router:
[https://github.com/neutralinojs/neutralinojs/blob/master/cor...](https://github.com/neutralinojs/neutralinojs/blob/master/core-
linux/src/router.cpp)

I hope that there is some form of authentication to make sure no random web
apps are accessing the API.

------
rubyn00bie
What is the difference between this and
[https://github.com/zserge/webview](https://github.com/zserge/webview) which
it's based on? Or what do I get from this that I don't from webview (which
I've been considering in Rust)?

~~~
zserge
Webview author here. I have to mention that neutralino is based on a slightly
outdated webview, the new version is to be merged in March, which includes
EdgeHTML and Edge/Chromium support on Windows.

------
ronyfadel
I'm currently working on an app built with Electron app. One thing I love is
not to have to worry about whether the APIs I'm using are supported by the
browser, since the browser is packaged inside the app. (if it works on my
machine, it has a decent chance or working well on my users' machines).

The perf overhead (memory, bundle size) is big, but it's not stopping anyone
from shipping Electron apps (Visual Studio Code, Slack, WhatsApp, etc..).

A nice to have compromise would be to have currently running Chromium Electron
instances to host newly launched Electron apps, it doesn't solve the bundle
size issue, but at least solves memory bloat and the number of Chrome main
processes running.

------
pier25
Why no macOS in the comparison?

[https://github.com/neutralinojs/evaluation](https://github.com/neutralinojs/evaluation)

For a moment I thought Neutralino didn't support macOS.

~~~
leppr
Presumably the person who did the benchmarks doesn't own an Apple computer.

------
yayr
I don't think using a local web port for the UI of a desktop app is a good
idea, at least for security reasons. I guess much of the resources of the
alternative solutions are used to mitigate just that (in addition to having a
powerful backend framework). So if you don't want either, than maybe it is an
option, but it severly limits the scope of the architecture.

------
mwexler
Surprised not to see the license clearly on the site, but it's under MIT
License:
[https://github.com/neutralinojs/neutralinojs/blob/master/LIC...](https://github.com/neutralinojs/neutralinojs/blob/master/LICENSE)

------
k__
Reminds me of Nidium, but nothing is happening there anymore

[https://github.com/nidium/Nidium/](https://github.com/nidium/Nidium/)

------
mwnivek
Sharing this as another alternative, unfortunately unmaintained:

[https://github.com/pojala/electrino](https://github.com/pojala/electrino)

------
rafaelvasco
It's an awkward transition period toward a universal virtual machine,
universal bytecode format JIT based runtime that runs in browser and out of
it. Ultimate cross platformness. The Holy Grail. Lot's of people trying
several things that tackle some of it but not all. All of them will perish as
all things do but they'll pave the way for the future. Let the revolution
begin;

------
rjvs
SpiderEye [1] is another project with the same approach, while Ultralight [2]
is very different but with similar goals in some ways (light cross-platform
application UI).

1\.
[https://github.com/JBildstein/SpiderEye](https://github.com/JBildstein/SpiderEye)

2\. [https://ultralig.ht](https://ultralig.ht)

------
sebastianconcpt
_Neutralino offers a lightweight and portable SDK which is an alternative for
Electron and NW.js also with many advantages. No extra dependencies are
required. SDK is fully portable. Debug applications using a web browser. An
uncompressed Neutralino app is only ~5MB and compressed app size is ~1MB._

------
superkuh
In time all possible words will have a different, overloaded, meaning within
the context of computer science.

------
fbn79
If I understand it's like Google Chrome Native Messaging but with a generic
multi-purpouse server.
[https://developer.chrome.com/extensions/nativeMessaging](https://developer.chrome.com/extensions/nativeMessaging)

------
dirkg
Electron's value prop is running the same code as your website, and also being
able to use latest features from Chromium, Node and JS for unified
development.

Neutralino uses MSHTML and WebKit so its already outdated, and it won't run on
the web. So why would I use it?

------
giovannibonetti
When I click on the comparison button on my mobile browser it just opens the
left menu

------
dvdhnt
This looks interesting. I was confused because the name is very close to an
established JS build tool: [https://neutrinojs.org/](https://neutrinojs.org/)

------
rusticpenn
> There are some drawbacks such as Windows edition is based on IE etc.

What does this mean?

~~~
untog
It uses whatever the system webview is. So on Windows that is IE, on Mac it’s
WKWebView, not sure about Linux.

It’s a trade off: it’s much more lightweight but loses cross platform
consistency. For some that might be absolutely fine, for others it may not.

~~~
vorpalhex
I wish we had a step inbetween. Something more than "just a webview" but
something less than, well, all of electron. Give me like a really cut down
browser that's consistent across platforms and embed it.

~~~
untog
It's a shame Sciter hasn't seen more adoption:

[https://sciter.com/](https://sciter.com/)

But a) it's a commercial product and b) uses it's own scripting language
instead of JavaScript. But from some initial noodling around with it the
browser engine is very capable and the footprint small.

~~~
api
The weird language is the big turn-off for me, not the license. This is also a
turn-off for Flutter and Lazarus.

WHY do these projects insist on doing this? What is it about UI that leads
people to think this is a good idea? _Do not make me learn yet another
language just to use your UI library._

It's not that FreePascal or Dart are bad languages. It's that they're another
language to consume yet more precious attention and head space, and there's
nothing compelling enough about them vs. C++, Rust, Go, Python, JS/TypeScript,
etc. to make it worthwhile.

~~~
c-smile
You can use Sciter in C++, Rust, Go, Python, Delphi, C# and D projects :
[https://github.com/sciter-sdk](https://github.com/sciter-sdk)

~~~
api
You can't write your GUI in those languages.

~~~
c-smile
> You can't write your GUI in those languages.

What do you mean by "write GUI"?

If to declare DOM structure then HTML is for that.

If to initialize DOM structure from code at runtime then this (C++ here):

    
    
       use namespace sciter;
    
       element root = window.get_root();
       element div = element::create("div", L"Hello world");
    
       root.append(div);
    
       div.attach_event_handler(my_controller);
    

Or do you mean something else?

~~~
api
Whoa... I didn't know it let you do that! In that case that's quite
interesting. It opens the potential for using the web renderer but not having
to code everything in JS.

~~~
c-smile
"It opens the potential..."

Applications that use Sciter for their UI are native applications. Like Norton
AntiVirus for example. Or any other app of these vendors:
[https://sciter.com/#customers](https://sciter.com/#customers)

------
sheerun
There's
[https://github.com/patr0nus/DeskGap](https://github.com/patr0nus/DeskGap)
which seems little more mature?

------
ad404b8a372f2b9
Web devs have ruined the web and now they're ruining the desktop. I wish
people would go back to native UIs.

------
asdkhadsj
Does this support WASM? I'd expect not given it's so small, but worth asking.

~~~
hellofunk
That probably just depends on whether the system browser that it launches
supports wasm, I think it’s passing off the dependency.

------
cordite
The docs page is just white for me

------
ecmascript
Looks great, I will definitely try it!

