Live data from Hacker News

NeutralinoJS: Lightweight Electron alternative using native browser controls

neutralino.js.org

51–60 of 200 posts

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#51
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…

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.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#52

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

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.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#54
post #51
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…

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 spitballing, but Chrome does have issues with high memory usage[0]. But also, VS Code can take up multiple gigabytes[1] on a large project.

[0]: https://lifehacker.com/why-chrome-uses-so-much-freaking-ram-...

[1]: https://stackoverflow.com/questions/53658769/why-vscode-requ...

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#55
post #32

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?

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 can totally understand how appealing it is to effectively ship your entire environment as part of your application instead of relying on shared dependencies.

It's the modern "It works on my machine", but in this case it does because you almost ship the entire machine.

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#57
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

Re: NeutralinoJS: Lightweight Electron alternative using native browser controls

#58
post #20
post #16

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.

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.

Post reply on HN