The big advantage of doing it this way is that, for users, it Just Works. They never get incomprehensible error messages telling them that they've got an incompatible version of libwhatever.dll when they try to load your app. I remember well the bad old days of Java desktop apps in the early 2000s, where this problem was omnipresent. Moving away from that was a major boon to users, and I don't ever want to go back.

And now many java apps bundle their own JRE (at least on windows).

Like anything else it's a tradeoff, and for the average user not having to install separate dependencies (at least on windows and mac) is going to be easier, and 50 or 100 mb isn't something anyone is going to really have an issue with in the vast majority of cases.

Slack for example is 192 MB. I guess if everyone had that theory I might have 30 extra copies 6 extra gigabytes. More importantly I would have to ensure I killed apps lest say a calculator app or editor ruin my battery life by itself for the dubious privilege of rendering a blinking cursor.

Like I said it's a tradeoff.

For you, it sounds like it hurts more than it helps, but for others the options may be:

1. Don't use slack at all because they can't figure out how to install the correct version of libthingy.dll. Or they don't get the app at all because it's not for their platform.

2. Use slack

And in that scenario, the option they went with wins hands down.

I'm not saying it's perfect, and I still believe that giving both options would be a benefit for most, but the fact that it is done this way wasn't a "mistake", it was a tradeoff for the targeted audience solving problems that many had.

You're not really being fair here. You could just as well distribute all needed dll's with the app. In fact, that's pretty much what Electron does.

Why not ship an installer that checks for and appropriately installs DLLs?

Doesn't sound that bad on desktop. The binaries for Qt or the java JVM are not small either.

I suppose it's a problem on mobile though.

Hmmm.

Qt programs are pretty small. Java are bigger but still much much smaller than any Electron-based program.

IIRC JRE is about 50 MB. Probably less. So even if you include it with your Java program, it's STILL smaller than Electron programs.

Java was the problem here. DLL hell is a problem if you don't ship with the needed DLLs. Which you shouldn't do in the first place.

I‘ve had a bunch of electron apps show incomprehensible Javascript errors at launch. Technology doesn‘t prevent people from distributing poorly tested code.

It's 2017 and we still can't distribute software or manage libraries. For some reason content addressability based on hashes for libraries has never occurred to anyone.

Windows Side-by-Side assemblies (WinSxS) are similar to this. Each assembly or .dll contains a manifest that list its dependencies by version and token id. The OS dynamically loads the dependencies based on the manifest.

https://en.wikipedia.org/wiki/Side-by-side_assembly

This was introduced in Windows 2000 and used for core OS components starting with Windows Vista.

I think Guix has the potential to do that. At least the hash for the reproducible build is part of the package definition.

So it seems like one should be able to just have that hash, and then rely on the backend to just go fetch a blob that has that hash from a list of possible sources (centralized repo, bittorrent tracker, IPFS, etc.)

Why use hashes instead of, e.g., semver, or hash + patch version, so that you could patch Heartbleed easily?

What do you mean should be hashed? Each library?

Yes. Then add a service on the OS that fetches the libraries for any binary. It's not a complicated thing. It's been obvious to me for years that this is how exact version linking should work.

Linux at least has library versioning so this is less of a problem. Windows has foo.dll and foo.dll and foo.dll, so pretty much the only way is to ship your own foo.dll.

There are schemes like this, e.g. Nix.

I like it though it not without any disadvantage.

It will be challenging to upgrade OpenSSL after a discovered vulnerability.

Not that I disagree, but the downside is that you would have the browser fragmentation that alot of people use electron to avoid.

There is a project that actually does something in those lines.

https://github.com/nodekit-io/nodekit

Instead of embedding a browser engine and Node in each application, it uses the available ones in the platform it's running.

Another similar project to use the available browser on the user's current platform:

https://github.com/pojala/electrino

Then you'll get weird errors. Everyone distributes the whole universe because it just works. Docker is the same idea for services.

And you fix these errors as they arise, adding platform-specific hacks to the library as necessary. Your product still ends up much smaller and better-performing than the others.