[wruza]

Strangely “we” can do that for linux, but cannot for the web. “apt install myapp” pulls the required trusted binary dependencies, if they aren’t there, and that’s it. Qt, wx, gtk, ffmpeg, mesa, you name it. Potentially malicious code is reviewed by distros and is not included, so if you want to distribute libhacky with your myapp, the entire ecosystem has to accept it before a user could trust it. But browsers are somehow different. I think the main reason is that browser vendors want their control over the market, and the entire issue is not technical/community at all.

It’s hard to get big groups of people to work together effectively.

One of the valid ways to deal with it is to let them work separately.

[shadowgovt]

It doesn't work nearly as well in Linux as we'd want to impose such a design on the web.

"apt install myapp" works 95-99% of the time. The remaining time, you drop yourself into DLL hell of some flavor or other (package was poorly maintained, or your clone of the package repo indices is out of date, or you installed a local copy built-from-scratch of one of the binaries and it's now fighting with the distro binary, &c &c). And then remote tech support is impossible because for someone to provide support, they either need intimate knowledge of your configuration or you need to be running a stock configuration (and with very few, usually vendor-controlled exceptions, "stock configuration of a Linux distro" is a non-concept).

There was, ages ago, a paper describing what the design of a componentized browser rendering engine would look like (where pages could basically declare "I require engine components X, Y, Z" and the browser would have a library of them that could be spun up on a page-by-page basis). I wish I could grab a link to it; I think it may have been a Mozilla experiment? If I recall correctly, the complexity meant it never gained traction.