Hacker News Reader

Comment by derefr | Hacker News Reader

What I'm really confused about is why Electron is set up such that each app ships the whole runtime, rather than there being something like the JRE or CLR (or Silverlight, or Adobe Air, or...) where each app that wants to use it, prompts for its installation.

Better yet, why not make the architecture into a single shared "Electron windowing server" process that all Electron apps run "on", such that I don't end up running 7 different copies of Chrome?

(Honestly, Chrome itself could have become said runtime with its packaged apps, plus the (only ever experimental) standalone App Launcher install mode. I guess that's not the path they wanted to go down.)

View on HN

That approach is not without downsides. It requires strong compatibility guarantees and version management. That's not easy to achieve.

And traditionally, management of such shared runtimes on anything but Linux sucks a lot. Remember all those Windows apps that tell you "Java Runtime Environment 1.5 required" and then they kind of leave you to figure out how to install that? Not exactly user-friendly.

And at the end of the day, regardless of your OS, you end up with 4-5 different JRE versions installed because compatibility is not perfect, so each app locks down to a specific version instead of accepting a newer JRE.

.NET isn't any better. I have 5-6 different .NET runtime versions installed and I can't remove any of them because each app requires a different version.

The method of vendoring all your dependencies may not be the most efficient, but it's certainly the most convenient one. It seems users these days care more about how much hassle it is to install than how long the download takes or how much RAM it uses.

> That approach is not without downsides. It requires strong compatibility guarantees and version management.

Static linking the runtime also has significant downsides. One of the worst is how it puts the burden of pushing runtime security updates on the app. Frequent JRE downloads because of security patches is annoying, but downloading N copies of chrome every for all of your apps is insane.

Of course, this also requires that each app update itself to be compatible with the new versions every time there is a security patch. The entire point of including a specific version of chrome is to avoid these updates, so the very idea of Electron implies the app is not designed for security.

Because an electron JRE will run into the same versioning issues that the JRE has.

Not to mention the additional headache of having to install dependencies which can be an annoyance on some platforms.

At this point in 2016 the number of people that are negatively affected by an electron app's size on disk is significantly less than would be negatively affected by having to muck with installing "Electron Runtime version 52" for app A but need to lock it to "Electron Runtime version 50" for app B.

Is there really anything in your average Electron app that breaks when Electron is upgraded? I assumed that Electron apps would inherit implicit forward-compatibility from web-apps, allowing "Electron" to just always mean "the latest Electron" in the same way that "Chrome" means "the latest Chrome."

Also, I'm not so much concerned with size-on-disk as I am with

1. redundant versioning leading to redundant network bandwidth costs (e.g. I don't want to find out that I have 20 different apps that want to download a 100MB update—99MB of which is the same Electron binary—every time Electron itself updates.)

2. memory usage (30 versions of the Electron runtime means 30 copies of Electron taking physical memory. 30 apps using the same Electron runtime means 30 copies of Electron in virtual memory sharing the same physical pages.)

Sadly that's not the case. Many electron apps are written with a single version in mind and that version needs to be treated like any other dependency. Knowing you are targeting a single platform lets devs aggressively optimized that platform.

Also, some electron apps will modify the "browser" part.

As for download sizes, aside from the first download all updates can use Delta update packages and I believe this is built in.

Re memory usage, with sandboxing the way it is today I'm not convinced you would save all that much memory unless you were running over 10 different electron apps, and even then compared to the total memory usage I feel it would be insignificant enough to not warrant the "JRE architecture". I don't really have anything to back this up, its just a hunch.

It seems to exist like a runtime (https://www.npmjs.com/package/electron), but I have not tried it for now and I can't judge the usability in production.

An NPM package does not a runtime make. By "runtime", I'm referring to something that exists, at least, as an .msi on Windows and a .pkg on macOS, such that Electron can generate a "launcher wrapper" binary that will download and execute those in silent-install mode, then unpack and execute your app using the now-installed runtime.

Because the node.js cult have lost their minds, only knowing how to bring the kitchen sink with everything they do, and only knowing javascript.

Is this really necessary? It's a language/runtime, not a sports team.

You throwing everyone that uses node.js into a big bin labeled "only knows javascript cult" is childish at best.

There are obviously trade offs going with a "globally installed runtime" vs "including the runtime with each application". JRE takes the former, electron the latter. Each with their own set of problems, each providing different solutions, each with their own reasons, applications, and "target audience".

Reply on news.ycombinator.com