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…
NeutralinoJS: Lightweight Electron alternative using native browser controls
51–60 of 200 posts
Re: NeutralinoJS: Lightweight Electron alternative using native browser controls
#52using the word "lightweight" to describe anything involving js and an html renderer should be prohibited
> An uncompressed Neutralino app is only ~5MB and compressed app size is ~1MB.
Re: NeutralinoJS: Lightweight Electron alternative using native browser controls
#53Re: NeutralinoJS: Lightweight Electron alternative using native browser controls
#54I 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.
[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
#55Stupid 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…
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
#56So 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.
Re: NeutralinoJS: Lightweight Electron alternative using native browser controls
#57 ./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-macRe: NeutralinoJS: Lightweight Electron alternative using native browser controls
#58This 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
Welcome to the corporate world.
Re: NeutralinoJS: Lightweight Electron alternative using native browser controls
#59Re: NeutralinoJS: Lightweight Electron alternative using native browser controls
#60Why is it called `Neutralino`? As a supersymmetric partner it's much heavier than the Standard Model particles.