17 ms·

NeutralinoJS: Lightweight Electron alternative using native browser controls

347 points by api 7y ago

mwexler 7y ago
Surprised not to see the license clearly on the site, but it's under MIT License: https://github.com/neutralinojs/neutralinojs/blob/master/LICENSE https://github.com/neutralinojs/neutralinojs/blob/master/LIC...
antoineMoPa 7y ago
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 7y ago
  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?
  - hellofunk 7y ago
    I agree that they really need to explain this better on their site somewhere.
  - antoineMoPa 7y ago
    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/core-linux/src/router.cpp https://github.com/neutralinojs/neutralinojs/blob/master/cor... I hope that there is some form of authentication to make sure no random web apps are accessing the API.
- jonmaim 7y ago
  Indeed I think they don't ship the whole browser package. What they might actually do is to locally launch a HTTP server which renders the app if you call it on any browser (localhost:8080 in the examples). The chrome of the app is actually a thin layer that use the default OS web browser. That is why the memory footprint is much less higher that alternatives like electron.
- pcr910303 7y ago
  Looks like it's using system controls on macOS, Windows and dynamically linking to webkit on Linux for rendering the served HTML/CSS/JS (from node). I see mentions of WKWebView(the system webkit) in the code[0], and while I don't know any Windows programming, they are #including <mshtml.h>[1] - looks like a system included web view (presumably the one that edge was based on). The linux build requires libwebkit2gtk-4.0-dev to be installed[2] - they're dynamically linked to webkit2gtk. [0] https://github.com/neutralinojs/neutralinojs/blob/b10e065c97aef495d960c0619bed7b64a084f17b/core-macos/lib/webview.h#L1915 https://github.com/neutralinojs/neutralinojs/blob/b10e065c97... [1] https://github.com/neutralinojs/neutralinojs/blob/07fdc3c1c79f53c86e383518d71d0bbeed4600f8/core-windows/src/webview.h#L63 https://github.com/neutralinojs/neutralinojs/blob/07fdc3c1c7... [2] https://github.com/neutralinojs/neutralinojs/blob/master/README.md#build-neutralino-platform-in-linux https://github.com/neutralinojs/neutralinojs/blob/master/REA...
  - antoineMoPa 7y ago
    I think you are right except when you say that the HTML/CSS/JS is served from node. The website says it is not served from node which makes it lighter than alternatives. Developing an app requires node, but it will not be needed at runtime if I get this right.
- ASalazarMX 7y ago
  I guess it needs only 400 Mb of RAM instead of 500 then.
ecmascript 7y ago
Looks great, I will definitely try it!
rusticpenn 7y ago
> There are some drawbacks such as Windows edition is based on IE etc. What does this mean?
- untog 7y ago
  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.
  - pjmlp 7y ago
    Just like the Web stack. If that isn't desired, then doing native apps is the way.
  - vorpalhex 7y ago
    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 7y ago
      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 7y ago
        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.
fbn79 7y ago
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
superkuh 7y ago
In time all possible words will have a different, overloaded, meaning within the context of computer science.
asdkhadsj 7y ago
Does this support WASM? I'd expect not given it's so small, but worth asking.
- hellofunk 7y ago
  That probably just depends on whether the system browser that it launches supports wasm, I think it’s passing off the dependency.
pjmlp 7y ago
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.
- deleted 7y ago
  [deleted]
- robbick 7y ago
  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 7y ago
    We still need to support IE 11 on our projects anyway. Welcome to the corporate world.
    - kirubakaran 7y ago
      > 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
      - greggeter 7y ago
        That stat says "IE + Edge." MS is aggressively pushing upgrades to Edge which means Chromium would be the system engine, yes?
      - pjmlp 7y ago
        Lucky you, I usually do internal corporate applications.
    - strbean 7y ago
      Not if you are shipping chrome with your application. Isn't that part of the point of electron?
hamaluik 7y ago
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
- dingdingdang 7y ago
  The good thing about webview is that it does not use localhost:8080 for internal comms!
- deleted 7y ago
  [deleted]
- valdiorn 7y ago
  Isn't the "system provided web engine" now Edge on Windows 10, and has been fore a while?
  - api 7y ago
    So that means only 25% of your users will still have IE since they never upgrade? Then you have corporate environments where IT held back Edge because internal business software requires IE. (Yes that is still a thing. Yes you can install them both. Yes, IT will still do that.) Then you have systems where some badly written installer broke the native web view but the user isn't noticing because they only use Chrome. This is Windows after all.
  - hamaluik 7y ago
    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
anonsivalley652 7y ago
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?
- bityard 7y ago
  Not a stupid question. This is exactly how operating systems and application SDKs were always developed and deployed until fairly recently.
  - thrower123 7y ago
    It worked quite well, until software release cycles got stupidly short. It was always a pain in the ass to have to install the Visual C++ runtime, but there were only so many versions of it. These days you have people linking a hundred DLLs that release new versions monthly, sometimes weekly.
- bengl 7y ago
  Google's Carlo sort of does that. It uses your system's already-installed Chrome instead of packaging another one. https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo
- mrits 7y ago
  Single binary is becoming more common even for runtime apps (JVM,.NET). The reason I wouldn't want Electron to be shared across apps is I don't want a system wide install and certainly don't want to deal runtime version type issues. Electron would start having to be backward compatible for years.
- api 7y ago
  That's sane. Sanity is prohibited in the realm of UI programming. There's apparently a law somewhere that states that all GUI libraries and APIs must be one of: platform-specific, bloated/slow, or incomplete/ugly.
cordite 7y ago
The docs page is just white for me
pier25 7y ago
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.
- deleted 7y ago
  [deleted]
- leppr 7y ago
  Presumably the person who did the benchmarks doesn't own an Apple computer.
clownpenis_fart 7y ago
using the word "lightweight" to describe anything involving js and an html renderer should be prohibited
- marshmellowtest 7y ago
  Indeed. Webshits alone are responsible for 1 or 2% of global energy usage.
  - MuffinFlavored 7y ago
    I feel like this calibre of comment is a perfect example of the "reddification" of HackerNews recently
    - vesinisa 7y ago
      > Please don't submit comments saying that HN is turning into Reddit. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - skrowl 7y ago
      If it were being reddified, you'd see a bunch of people needlessly turning things into political discus--- ohh.....
  - ORioN63 7y ago
    _sigh_ Source? Even disregarding the poor term you've used, I'm pretty skeptical of what you just stated. Especially with a margin error of 1%.
- hjek 7y ago
  I know but the apps are several orders of magnitude smaller than Electron apps, so I think it's appropriate here: > An uncompressed Neutralino app is only ~5MB and compressed app size is ~1MB.
- t0astbread 7y ago
  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.
giovannibonetti 7y ago
When I click on the comparison button on my mobile browser it just opens the left menu
derefr 7y ago
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.
- efdee 7y ago
  Where is this 1-2GB number coming from? I'm running a fairly large Electron app and the combined memory usage of its processes is about 250-300MB.
  - 7y ago
nablaoperator 7y ago
Why is it called `Neutralino`? As a supersymmetric partner it's much heavier than the Standard Model particles.
- lisper 7y ago
  Neutrino was taken: https://neutrinojs.org/ https://neutrinojs.org/
k__ 7y ago
Reminds me of Nidium, but nothing is happening there anymore https://github.com/nidium/Nidium/ https://github.com/nidium/Nidium/
rcarmo 7y ago
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
dvdhnt 7y ago
This looks interesting. I was confused because the name is very close to an established JS build tool: https://neutrinojs.org/ https://neutrinojs.org/
Sephr 7y ago
> 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 7y ago
  Is Carlo maintained? The last commit in master was eight months ago.
  - paulirish 7y ago
    It's not. (I was part of the team that launched it.)
- paulirish 7y ago
  Carlo is essentially what top commenter derefr is asking for. That said, it is unmaintained and I don't expect that to change.
- xienze 7y ago
  > There are some drawbacks such as Windows edition is based on IE etc. Well that's kind of a non-starter. Part of the appeal with shipping an entire browser in an Electron app is to give yourself a fixed target. It always seems that these "Electron killers" all have some fatal flaw, be it "just use whatever the system browser is" or "just as good as Electron, if you don't care about file drag-and-drop, system clipboard integration, full CSS support, minor things like that"[1]. 1: https://github.com/ultralight-ux/Ultralight/issues/178 https://github.com/ultralight-ux/Ultralight/issues/178
- latchkey 7y ago
  Sadly looks dead... https://github.com/GoogleChromeLabs/carlo/issues/163 https://github.com/GoogleChromeLabs/carlo/issues/163
catchmeifyoucan 7y ago
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
mwnivek 7y ago
Sharing this as another alternative, unfortunately unmaintained: https://github.com/pojala/electrino https://github.com/pojala/electrino
ronyfadel 7y ago
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.
rubyn00bie 7y ago
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 7y ago
  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.
yayr 7y ago
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.
gigel82 7y ago
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".
- martin-adams 7y ago
  i see this approach with DB admin tools which makes it great to run in docker along side the db itself.
- throwlaplace 7y ago
  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 7y ago
    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 7y ago
      oh yes you're right. i got confused for a moment. thanks!
  - bobblywobbles 7y ago
    Electron does, but you need to consider security. Malicious apps or ill-designed architectures can leak openings where a bad actor can attack your OS. I'm the author of secure-electron-template, a template with secure practices baked-in. Security is very important and I don't feel people think of that from the get-go.
dirkg 7y ago
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?
Mikho 7y ago
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 7y ago
  But it works on only Chrome at the moment. Firefox or Safari users wouldn't install Chrome just for your PWA.
  - Mikho 7y ago
    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.
deleted 7y ago
[deleted]
sebastianconcpt 7y ago
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.
rjvs 7y ago
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
iamleppert 7y ago
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.
ad404b8a372f2b9 7y ago
Web devs have ruined the web and now they're ruining the desktop. I wish people would go back to native UIs.
sheerun 7y ago
There's https://github.com/patr0nus/DeskGap https://github.com/patr0nus/DeskGap which seems little more mature?
rafaelvasco 7y ago
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;

347 points by api 7y ago

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

antoineMoPa 7y ago

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 7y ago
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?
- hellofunk 7y ago
  I agree that they really need to explain this better on their site somewhere.
- antoineMoPa 7y ago
  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/core-linux/src/router.cpp https://github.com/neutralinojs/neutralinojs/blob/master/cor... I hope that there is some form of authentication to make sure no random web apps are accessing the API.
jonmaim 7y ago
Indeed I think they don't ship the whole browser package. What they might actually do is to locally launch a HTTP server which renders the app if you call it on any browser (localhost:8080 in the examples). The chrome of the app is actually a thin layer that use the default OS web browser. That is why the memory footprint is much less higher that alternatives like electron.
pcr910303 7y ago
Looks like it's using system controls on macOS, Windows and dynamically linking to webkit on Linux for rendering the served HTML/CSS/JS (from node). I see mentions of WKWebView(the system webkit) in the code[0], and while I don't know any Windows programming, they are #including <mshtml.h>[1] - looks like a system included web view (presumably the one that edge was based on). The linux build requires libwebkit2gtk-4.0-dev to be installed[2] - they're dynamically linked to webkit2gtk. [0] https://github.com/neutralinojs/neutralinojs/blob/b10e065c97aef495d960c0619bed7b64a084f17b/core-macos/lib/webview.h#L1915 https://github.com/neutralinojs/neutralinojs/blob/b10e065c97... [1] https://github.com/neutralinojs/neutralinojs/blob/07fdc3c1c79f53c86e383518d71d0bbeed4600f8/core-windows/src/webview.h#L63 https://github.com/neutralinojs/neutralinojs/blob/07fdc3c1c7... [2] https://github.com/neutralinojs/neutralinojs/blob/master/README.md#build-neutralino-platform-in-linux https://github.com/neutralinojs/neutralinojs/blob/master/REA...
- antoineMoPa 7y ago
  I think you are right except when you say that the HTML/CSS/JS is served from node. The website says it is not served from node which makes it lighter than alternatives. Developing an app requires node, but it will not be needed at runtime if I get this right.
ASalazarMX 7y ago
I guess it needs only 400 Mb of RAM instead of 500 then.

ecmascript 7y ago

Looks great, I will definitely try it!

rusticpenn 7y ago

> There are some drawbacks such as Windows edition is based on IE etc. What does this mean?

untog 7y ago
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.
- pjmlp 7y ago
  Just like the Web stack. If that isn't desired, then doing native apps is the way.
- vorpalhex 7y ago
  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 7y ago
    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 7y ago
      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.

fbn79 7y ago

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

superkuh 7y ago

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

asdkhadsj 7y ago

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

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

pjmlp 7y ago

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.

deleted 7y ago
[deleted]
robbick 7y ago
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 7y ago
  We still need to support IE 11 on our projects anyway. Welcome to the corporate world.
  - kirubakaran 7y ago
    > 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
    - greggeter 7y ago
      That stat says "IE + Edge." MS is aggressively pushing upgrades to Edge which means Chromium would be the system engine, yes?
    - pjmlp 7y ago
      Lucky you, I usually do internal corporate applications.
  - strbean 7y ago
    Not if you are shipping chrome with your application. Isn't that part of the point of electron?

hamaluik 7y ago

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

dingdingdang 7y ago
The good thing about webview is that it does not use localhost:8080 for internal comms!
deleted 7y ago
[deleted]
valdiorn 7y ago
Isn't the "system provided web engine" now Edge on Windows 10, and has been fore a while?
- api 7y ago
  So that means only 25% of your users will still have IE since they never upgrade? Then you have corporate environments where IT held back Edge because internal business software requires IE. (Yes that is still a thing. Yes you can install them both. Yes, IT will still do that.) Then you have systems where some badly written installer broke the native web view but the user isn't noticing because they only use Chrome. This is Windows after all.
- hamaluik 7y ago
  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

anonsivalley652 7y ago

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?

bityard 7y ago
Not a stupid question. This is exactly how operating systems and application SDKs were always developed and deployed until fairly recently.
- thrower123 7y ago
  It worked quite well, until software release cycles got stupidly short. It was always a pain in the ass to have to install the Visual C++ runtime, but there were only so many versions of it. These days you have people linking a hundred DLLs that release new versions monthly, sometimes weekly.
bengl 7y ago
Google's Carlo sort of does that. It uses your system's already-installed Chrome instead of packaging another one. https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo
mrits 7y ago
Single binary is becoming more common even for runtime apps (JVM,.NET). The reason I wouldn't want Electron to be shared across apps is I don't want a system wide install and certainly don't want to deal runtime version type issues. Electron would start having to be backward compatible for years.
api 7y ago
That's sane. Sanity is prohibited in the realm of UI programming. There's apparently a law somewhere that states that all GUI libraries and APIs must be one of: platform-specific, bloated/slow, or incomplete/ugly.

cordite 7y ago

The docs page is just white for me

pier25 7y ago

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.

deleted 7y ago
[deleted]
leppr 7y ago
Presumably the person who did the benchmarks doesn't own an Apple computer.

clownpenis_fart 7y ago

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

marshmellowtest 7y ago
Indeed. Webshits alone are responsible for 1 or 2% of global energy usage.
- MuffinFlavored 7y ago
  I feel like this calibre of comment is a perfect example of the "reddification" of HackerNews recently
  - vesinisa 7y ago
    > Please don't submit comments saying that HN is turning into Reddit. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - skrowl 7y ago
    If it were being reddified, you'd see a bunch of people needlessly turning things into political discus--- ohh.....
- ORioN63 7y ago
  _sigh_ Source? Even disregarding the poor term you've used, I'm pretty skeptical of what you just stated. Especially with a margin error of 1%.
hjek 7y ago
I know but the apps are several orders of magnitude smaller than Electron apps, so I think it's appropriate here: > An uncompressed Neutralino app is only ~5MB and compressed app size is ~1MB.
t0astbread 7y ago
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.

giovannibonetti 7y ago

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

derefr 7y ago

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.

efdee 7y ago
Where is this 1-2GB number coming from? I'm running a fairly large Electron app and the combined memory usage of its processes is about 250-300MB.
- 7y ago

nablaoperator 7y ago

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

lisper 7y ago
Neutrino was taken: https://neutrinojs.org/ https://neutrinojs.org/

k__ 7y ago

Reminds me of Nidium, but nothing is happening there anymore https://github.com/nidium/Nidium/ https://github.com/nidium/Nidium/

rcarmo 7y ago

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

dvdhnt 7y ago

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

Sephr 7y ago

> 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 7y ago
Is Carlo maintained? The last commit in master was eight months ago.
- paulirish 7y ago
  It's not. (I was part of the team that launched it.)
paulirish 7y ago
Carlo is essentially what top commenter derefr is asking for. That said, it is unmaintained and I don't expect that to change.
xienze 7y ago
> There are some drawbacks such as Windows edition is based on IE etc. Well that's kind of a non-starter. Part of the appeal with shipping an entire browser in an Electron app is to give yourself a fixed target. It always seems that these "Electron killers" all have some fatal flaw, be it "just use whatever the system browser is" or "just as good as Electron, if you don't care about file drag-and-drop, system clipboard integration, full CSS support, minor things like that"[1]. 1: https://github.com/ultralight-ux/Ultralight/issues/178 https://github.com/ultralight-ux/Ultralight/issues/178
latchkey 7y ago
Sadly looks dead... https://github.com/GoogleChromeLabs/carlo/issues/163 https://github.com/GoogleChromeLabs/carlo/issues/163

catchmeifyoucan 7y ago

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

mwnivek 7y ago

Sharing this as another alternative, unfortunately unmaintained: https://github.com/pojala/electrino https://github.com/pojala/electrino

ronyfadel 7y ago

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.

rubyn00bie 7y ago

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

yayr 7y ago

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.

gigel82 7y ago

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

martin-adams 7y ago
i see this approach with DB admin tools which makes it great to run in docker along side the db itself.
throwlaplace 7y ago
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 7y ago
  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 7y ago
    oh yes you're right. i got confused for a moment. thanks!
- bobblywobbles 7y ago
  Electron does, but you need to consider security. Malicious apps or ill-designed architectures can leak openings where a bad actor can attack your OS. I'm the author of secure-electron-template, a template with secure practices baked-in. Security is very important and I don't feel people think of that from the get-go.

dirkg 7y ago

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?

Mikho 7y ago

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 7y ago
But it works on only Chrome at the moment. Firefox or Safari users wouldn't install Chrome just for your PWA.
- Mikho 7y ago
  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.

deleted 7y ago

[deleted]

sebastianconcpt 7y ago

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.

rjvs 7y ago

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

iamleppert 7y ago

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.

ad404b8a372f2b9 7y ago

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

sheerun 7y ago

There's https://github.com/patr0nus/DeskGap https://github.com/patr0nus/DeskGap which seems little more mature?

rafaelvasco 7y ago

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;