3 ms·
That approach is not without downsides. It requires strong compatibility guarantees and version management. That's not easy to achieve. And traditionally, mana
by FooBarWidget 10y ago
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.
- pdkl95 10y ago> 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.