Live data from Hacker News

NeutralinoJS: Lightweight Electron alternative using native browser controls

neutralino.js.org

91–100 of 200 posts

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#91

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…

> It used to be known for prematurely wearing out SSDs by constantly writing stuff (cache I think?) to disk.

They were constantly vacuuming some SQLite database.[0]

[0] https://arstechnica.com/information-technology/2016/11/for-f...

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#92
post #85

Earlier quoted context omitted.

There's Carlo [1], which is an alternative to Electron that uses locally installed Chrome. 1: https://github.com/GoogleChromeLabs/carlo

The problem with this is that is requires people to have Chrome installed. That's a awkward dependency to require for a stand alone app.

Found this in Carlo to issue 90 [2]:

>If one chooses a chromium channel in the launch options, then carlo calls puppeteer createBrowserFetcher which will download the chromium revision compatible with Puppeteer or even a specific revision. sunglasses

In regular ElectronJS you have the same Chromium bundled with the app. Not sure if puppeteer installs a local or system wide Chromium.

2: https://github.com/GoogleChromeLabs/carlo/issues/90

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#93

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 also have this problem where a "Spotify Helper" can crash constantly, and you won't notice it unless you look at the process tree.

On macOS, this will start a ReportCrash process, and end up taking up an entire CPU core just repeatedly crashing, reporting a crash, restarting, etc. It also significantly impacts battery life.

This happens every day for me. It's arguably worse than the SSD-killing SQLite vacuum problem they had.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

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

Over here, the base overhead of an Electron window is around 60MB. How do you know it's not those applications allocating a lot of memory that is causing all this usage?

Of course I don’t know that since I don’t have the time or ability to inspect what the apps are doing. :-) The best I can do is give comparisons to the old non-Electron versions of Spotify and Skype, which had all the same core features as the Electron versions and used less memory for the whole app than you’re saying a base Electron window costs.

It is difficult for me to lay blame at the feet of application developers (assuming they didn’t make the choice to use Electron) when the platform itself is so bad at giving developers ways to manage their apps’ memory usage.

If you want to listen for an event on a global object like `window`, the platform could give a way to do this using a weak reference, but it doesn’t, so you have to make sure to always remember to manually remove the listener yourself or else you’ve just leaked a bunch of stuff.

If you want to load an image, or some other media, the platform could give a way to control the runtime’s internal caches so you aren’t retaining data in memory that you don’t need—but it doesn’t, so you have to hope that the generic runtime memory cache from Chromium is intelligent enough not to retain unimportant things (and, in my experience, it’s not).

This problem has existed in one form or another in every Electron app I’ve ever used. Some are certainly worse than others, but I don’t think I’ve ever seen one come within even an order of magnitude of the memory usage of similar apps written natively.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#95
post #58
post #20

Earlier quoted context omitted.

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

We still need to support IE 11 on our projects anyway. Welcome to the corporate world.

Not if you are shipping chrome with your application. Isn't that part of the point of electron?

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#96
post #64
post #51

Earlier quoted context omitted.

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.

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.

I wish this urban legend would just stop: the Spotify desktop client is NOT an Electron app, it's a CEF (Chromium Embedded Framework) app.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#98
post #96
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.

I wish this urban legend would just stop: the Spotify desktop client is NOT an Electron app, it's a CEF (Chromium Embedded Framework) app.

Well, it runs an instance of Chromium. So basically the same thing in this context.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#99

Earlier quoted context omitted.

Indeed. Webshits alone are responsible for 1 or 2% of global energy usage.

I feel like this calibre of comment is a perfect example of the "reddification" of HackerNews recently

If it were being reddified, you'd see a bunch of people needlessly turning things into political discus--- ohh.....

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

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

Post reply on HN