Live data from Hacker News

NeutralinoJS: Lightweight Electron alternative using native browser controls

neutralino.js.org

121–130 of 200 posts

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#121
post #101
post #48

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 ef…

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.

Everything you've written here presents a nightmarish vision of the computing future. Ethical and privacy considerations play a large role in my decision making process on which software I use. I don't want to use Chromium at all, if possible. I use one Electron app, Slack, on account of requiring it for work.

> Native desktop apps are never coming back

I really hope you're wrong. This would be a terrible outcome for so many reasons. I refuse to use Electron apps on my personal laptop on account of the absolutely noticeable degradation of performance and battery life from using these Electron apps. Using vscode literally halved my battery life.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#122

Earlier quoted context omitted.

Wow. I've got Apple Music/iTunes running for a week or so on this Catalina macOS and the process viewer reports 300MB (including sub-processes). I assume it's a native application. How does Spotify manage to use so much RAM??

The Spotify desktop client is architected such that each pane in the main window is essentially its own separate webapp, complete with duplicate (and triplicate, quadruplicate, etc) dependencies. They did this so their various teams don’t have to talk to each other. Desktop Spotify has been a resource hungry mess for years now. It used to be known for prematurely wearing out SSDs by constantly writing stuff (cache I…

> They did this so their various teams don’t have to talk to each other.

This is absolutely dreadful. I've unfortunately worked in multiple organisations where teams deconstructed their web-based products into microservices for this very reason.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#123

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

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.

It's possible to develop relatively lightweight browser engines. Refer to NetSurf for instance. However the ones I've seen are not what you'd consider fully-featured or usable for the average user's everyday browsing. The issues begin at implementing modern CSS and JavaScript support. Admittedly I've never looked too deeply at the internals, from what I understand supporting modern web standards is a maze of edge-cases, bug-for-bug compatibility issues and a forever moving target of feature parity with the major browsers.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#124
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?

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#125
post #64

Earlier quoted context omitted.

I’m currently running three Electron apps: Spotify, Skype, and VS Code. Spotify: 1083.7 MB. VS Code: 890.9 MB. Skype: 406 MB. In the past, I’ve had projects open in VS Code which have caused that number to shoot up into the multi-gigabyte range. Of course this is all anecdotal but I am pretty sure these numbers come from actual experiences that people are having with Electron apps.

Keybase also uses in the range of 600MB-1GB, and 8 processes, most of which don't exit when you exit the application. I'm not sure what Discord uses because I only run it in the browser, but I'm sure it's in the same range as all of the above. I've come up with a powershell snippet to fully quit keybase and reclaim ~1GB RAM: get-process | Where-Object {$_.path -match "keybase"} | Stop-Process

Discord seems surprisingly efficient for an Electron app.

https://imgur.com/a/DJKyyRz

That's ~230 MB. I can get it up to ~275 MB but it seems to return to normal pretty quickly.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#126
post #48

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 ef…

> I’m wondering whether it’d be possible to factor most of it out into a separate layer We've done this. The layer is called a web browser. You deliver runnable code to it using something called HTTP.

Did you even read the comment? GP literally addresses deficiencies in this layer when running multiple instances of the browser.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#127
post #48

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 ef…

> Chromium is built to share a lot of things between tabs efficiently

yey, currently using 6.6 gigabytes on my machine (RSS)... efficient...

firefox is no better, sitting at 4.8 gigabytes...

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#128
post #64

Earlier quoted context omitted.

I’m currently running three Electron apps: Spotify, Skype, and VS Code. Spotify: 1083.7 MB. VS Code: 890.9 MB. Skype: 406 MB. In the past, I’ve had projects open in VS Code which have caused that number to shoot up into the multi-gigabyte range. Of course this is all anecdotal but I am pretty sure these numbers come from actual experiences that people are having with Electron apps.

Keybase also uses in the range of 600MB-1GB, and 8 processes, most of which don't exit when you exit the application. I'm not sure what Discord uses because I only run it in the browser, but I'm sure it's in the same range as all of the above. I've come up with a powershell snippet to fully quit keybase and reclaim ~1GB RAM: get-process | Where-Object {$_.path -match "keybase"} | Stop-Process

The shorter form, before people complain again that PowerShell is too verbose:

   gps | ? path -m keybase | kill

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#129
post #121
post #101

Earlier quoted context omitted.

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.

Everything you've written here presents a nightmarish vision of the computing future. Ethical and privacy considerations play a large role in my decision making process on which software I use. I don't want to use Chromium at all, if possible. I use one Electron app, Slack, on account of requiring it for work. > Native desktop apps are never coming back I really hope you're wrong. This would be a terrible outcome for…

Gnome already is based on html/js. There is no need for 10 different UI toolkits if one standard can be optimized. The problem is html/js are far from well designed but due to their popularity a lot of time and money has been spent optimizing them.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#130
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/ (2) https://www.pwabuilder.com/

Post reply on HN