31–40 of 200 posts
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?
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?
That's why I really try to get into docker for instance, sure good old unix sysadmin and configure scripts might arguably be more elegant and efficient but it's a huge pain to maintain and can (and eventually will) break out the blue after a system update because of a regression in some obscure library. Meanwhile docker images should work mostly everywhere without any effort and you only update your dependencies when you want to update them.
So now that storage is cheap and RAM is plentiful I think shipping the dependencies as part of the executable is a reasonable approach most of the time. The problem with electron is that the dependencies involve a full web browser and half a trillion libraries. That's the insane part. I have full python virtual envs for non-trivial apps that are a fraction of the footprint of an electron hello world. It's the core technology that's broken, not the packaging.
Looks kind of like WebView [1] which I earnestly tried but eventually abandoned. Using the system-provided web engine is great for space savings, but terrible for cross-compatibility and feature availability owing to having to use IE on Windows. [1] https://github.com/zserge/webview
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?
Not a stupid question. This is exactly how operating systems and application SDKs were always developed and deployed until fairly recently.
Looks kind of like WebView [1] which I earnestly tried but eventually abandoned. Using the system-provided web engine is great for space savings, but terrible for cross-compatibility and feature availability owing to having to use IE on Windows. [1] https://github.com/zserge/webview
Isn't the "system provided web engine" now Edge on Windows 10, and has been fore a while?
This is Windows after all.
https://github.com/neutralinojs/evaluation
For a moment I thought Neutralino didn't support macOS.
> There are some drawbacks such as Windows edition is based on IE etc. What does this mean?
https://github.com/neutralinojs/evaluation/blob/master/READM...
This page was last updated 2/28/2019. Last month, Microsoft Edge was rereleased as a Chromium based browser. Presumably this would change the Windows frontend for Neutralino to Chromium, but I'm only speculating.
Edit: It appears that a Chromium system-provided web view for Windows is still in developer preview:
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv...
using the word "lightweight" to describe anything involving js and an html renderer should be prohibited
Earlier quoted context omitted.
It uses whatever the system webview is. So on Windows that is IE, on Mac it’s WKWebView, not sure about Linux. It’s a trade off: it’s much more lightweight but loses cross platform consistency. For some that might be absolutely fine, for others it may not.
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.
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.