Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NeutralinoJS: Lightweight Electron alternative using native browser controls

neutralino.js.org

Post reply on HN
Print view View original

81–90 of 200 posts

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#81

Post by hnuser123456 »

csnover wrote: post #64
efdee wrote: 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.

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

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#82

Post by NullPrefix »

derefr wrote: 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…

There's Carlo [1], which is an alternative to Electron that uses locally installed Chrome.

1: https://github.com/GoogleChromeLabs/carlo

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#83

Post by api »

untog wrote: post #40
vorpalhex wrote: post #22

Earlier quoted context omitted.

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.

It's a shame Sciter hasn't seen more adoption: 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.

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.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#84

Post by vips7L »

api wrote: post #83
untog wrote: post #40

Earlier quoted context omitted.

It's a shame Sciter hasn't seen more adoption: 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.

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

I've been looking at Dart lately and it seems like a pretty awesome language. A weird mashup of Java + JavaScript, but I agree its something else that has to be learned. I think flutter would probably have better adoption if they chose something more mainstream.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#85

Post by mfer »

NullPrefix wrote: post #82
derefr wrote: 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…

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.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#86

Post by kitsunesoba »

fmakunbound wrote: post #76
csnover wrote: 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.

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 think?) to disk.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#88

Post by efdee »

derefr wrote: post #63
efdee wrote: 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.

What’s its uptime? A lot of Electron apps—even ones that use minimal local JS, serving mostly as a webview—accrue base overhead as you use them, then keep it around even when you close their main window (and thus release their main Chromium-side render context), as long as the process stays alive. They’re caching stuff (like, as I said, rendered font glyphs, or network responses.) I have a copy of Slack running that’…

Multiple weeks of uptime (on a laptop that is used daily and hibernates at night).

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#89

Post by greggeter »

kirubakaran wrote: post #78
pjmlp wrote: post #58

Earlier quoted context omitted.

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

> 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

That stat says "IE + Edge." MS is aggressively pushing upgrades to Edge which means Chromium would be the system engine, yes?

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#90

Post by NullPrefix »

derefr wrote: post #43
simias wrote: post #32

Earlier quoted context omitted.

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

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

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

Post reply on HN