[binaryturtle]

What is that? Like 32x >100MB junk overhead per app? ~4GiB gone from the disk just to hold the same broken copy of some framework/library? It's quite the insanity, isn't it?

If there was one copy of that electron (e.g. installed to /Library somewhere) which all apps would simply use then you only would need to update one copy. Less disk space wasted. All apps fixed in one go.

Back in the old days on the Commodore Amiga we would just do that… install some .library to SYS:Libs/ first if a program required it. It's not like this process was so complicated nobody could do it, right?

[charcircuit]

>It's not like this process was so complicated nobody could do it, right?

Don't underestimate the utility of write once run anywhere. Needing to ensure compatibility with a bunch of different browser engines is not simple.

[Lammy]

Ironically Microsoft had exactly this in 1999 with Internet Explorer 5:

- https://en.wikipedia.org/wiki/HTML_Application

- https://www.geoffchappell.com/studies/windows/ie/mshtml/clas...

[dist-epoch]

There is not one Electron. There are multiple, they release a new version every month or so.

Some apps, like VS Code, update very quickly to the latest one. Others more rarely. So now you need to keep multiple shared Electron versions, and track dependencies and who uses what version.

And it's quite likely that everyone of your Electron using apps will be on a different version, so now you are back to square one.

[typpilol]

4gb seems quite small for all of those apps to be honest.

[whatever1]

No F shared libraries. Seriously.

Memory and storage is cheap enough nowadays to not have to deal with the insanity that shared libraries cause. I don’t care if I use 30gb of memory to run a browser and a note taking app.

[jonhohle]

Some of us do care. Devs should respect users systems more than their own instead of crapping all over them with Electron. I’d almost go as far as to say that it’s evil. Wasting resources, energy, people’s time, and money.

[solid_fuel]

I don't understand why it's all-or-nothing. We know how to version things pretty well these days, why is there no blended solution where libraries are shared but version aware? I don't mind having two different versions of electron on my laptop but I don't want 30 copies of the same version.

[SAI_Peregrinus]

You're basically describing Nix.

The big issue I see with Nix is that it's solving several related & very complex problems, and isn't doing so at a particularly easy level of abstraction. It's a PITA to package software that isn't using an already-supported build system. And mixing versions is messy, instead of just `[ package1="versionA", package2="versionB", …]` sort of thing with a lockfile to convert versions to immutable IDs like commit hashes you have to specify which commits of nixpkgs had each version and then do something like `nixpkgs-versionA=GIT_COMMIT_HASH_A; nixpkgs-versionB=GIT_COMMIT_HASH_B; [ nixpkgs-versionA.package1, nixpkgs-versionB.package2, …]`. There are lots of other "warts" like that, of varying levels of annoyance.

[whatever1]

Because in practice nobody has solved it, while everyone claims they have.

In practice every software needs a particular version of a library. Even a minor upgrade to that library might, and will break it. In an idealized world it should not happen, but here we are. In a world that we setup whole containers so that we can run software.

So no. Shared libraries do not work in practice. At all. It should be straightforward, but they just do not work.

[klabetron]

omg remember when we all had to install Java separately at the system level?

[whatever1]

Multiple versions of it. And .NET and C++ runtimes etc. And could never uninstall any version of them because you did not know what would break.

[oefrha]

No shit. One major frigging selling point of Electron vs OS web view is the developer controls the browser version and has a stable target to develop and test against, rather than having many moving targets that shift after the app is shipped.

And you really think the entire ecosystem has never heard of this honking great idea named shared libraries from the good old days? Being smug about obvious things like this usually just betrays your shallow understanding.

Disclosure: I’ve criticized Electron aplenty. But these are complex tradeoffs and people dismissing them with obvious wins in their minds are clueless.

Disclosure 2: I was once a member of the maintainer team of a major package manager. Shared libraries, oh my, I can tell you horror stories all night long. If your experiences with them are great chances are a team behind the scenes has blocked and/or fixed faulty updates for you and shielded you from most of the issues.

[typpilol]

I find explaining browser defaults to non web-devs really eye opening for them.