Why don't browsers pre-include popular JavaScript libraries?

Question

I've often wondered why there isn't a standard for browsers having a pre-populated local cache of very popular JS libraries. To name a few examples: jQuery, Lodash, React.It seems like the benefits of this would be significant for both user and developer - faster loading, lower bandwidth, quicker builds, etc.It also seems eminently doable, technically. One possible high-level implementation off the top of my head:- A standard index of the most popular libs is maintained.- You pull them in via the script tag, with a new lib="name@version" attribute. Older browsers can use the src tag as a backup.- SPA build systems like webpack et al are aware of the standard and can just not bundle libs pulled this way, while keeping the require() and import syntax.I do, however, see some pretty big not-strictly-technical difficulties:- The index would have to be administered by some entity. Who would that be, and who would pay for it?- Who defines what the most popular libs are? Whatever system is used, how do you prevent it being gamed to the advantage of particular libs?- Trust and security. A similar set of issues npm faces. Although that being the case, is this really introducing a new problem? It also seems like a much narrower problem if we're only talking about a small set of very popular libs.- Maybe some issues around licensing, bundling code into browsers etc. But again, if it's a smallish set of only very popular libs, this seems like it could be dealt with individually for each one and its authors, maybe as a prerequisite for getting included in the index.These difficulties are not insignificant, but nor do they seem insurmountable and also the benefits do seem genuinely worth it.It just appears to me to be something that should so obviously have been done, that there must be really good reasons why it hasn't been - maybe including those above, maybe technical, maybe others.Does anyone know if any serious attempt has ever been made at a proposal to do something like this, even if in a non-standard way by an individual browser vendor?

daveoc64 · Accepted Answer

Extensions like Decentraleyes and LocalCDN are doing things like this:
https://addons.mozilla.org/en-GB/firefox/addon/decentraleyes...
https://chrome.google.com/webstore/detail/localcdn/njdfdhgcm...
The aim is improving privacy - your browser doesn't need to request the libraries from a CDN, so you can't be tracked by them.
This does also bring the performance gains you mention.

__ryan__ · Answer

I&rsquo;ve thought about this a lot, but mostly in the context of reducing bandwidth use of mobile devices.Bundling with the browser wouldn&rsquo;t be enough in my opinion&mdash; the ecosystem moves too fast and you&rsquo;d risk bundling outdated code.Instead, cache common assets you&rsquo;ve downloaded naturally while browsing. Use some heuristic to keep the most heavy and frequently used assets cached.I don&rsquo;t think you&rsquo;d need an index. You could instead use a cryptographic hash of the asset&rsquo;s content as a cache key, and the page can specify further parameters for ensuring the integrity of assets cached from external sources.Browsers already do cache assets, but to my knowledge privacy concerns result in this cache scoped per-site.My understanding of one of the primary privacy concerns is that you might cache a dependency which either intentionally or unintentionally acts as a tracker. If site A and site B share a dependency C, either site may be able to deduce that you visited the other by observing whether you had to retrieve C or if it was cached. I&rsquo;m sure a dedicated party could craft a system which fingerprints users by giving them unique dependencies to cache. I think coming up a solution to this problem would open the door to something like this becoming a real possibility.

marshmellman · Answer

There can be hundreds of different versions for each popular library, and as a dev, I need customers to use exactly the version that we tested against. There’s a whole ecosystem and tool chain around lockfiles and deterministic builds for a reason.
And specifying a version range isn’t sufficient, because humans will and do get it wrong - either the one specifying the range or the one publishing a new version.
Ultimately, browsers cache static assets anyways. So this idea only helps the user’s first page load for a given website.
Edit: I’ll add that at my company we looked into preloading assets that are commonly used across teams’ web apps. And this is why we didn’t build it.

vivegi · Answer

Perhaps as an orthogonal feature, implement a distributed CDN using all the browser cached assets across other browser instances (using an approach like IPFS or BitTorrent) to parallelize the object fetch using a DHT.It could potentially use the HTML tag's integrity attribute See: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/li... for content addressable DHT lookups

Osiris · Answer

Every reasonably complex site I've worked on uses some form of bundler so even if a site uses a bunch of common libraries they are all compiled together into a big JS file.I think that a lot of the way websites are developed would have to change to support such an initiative.

kbrannigan · Answer

That's the most unique idea I've seen today.It's is the same concept of OS drivers but for the browser ?Like linux including python by default ?

devKnight · Answer

this is actually an interesting idea

Why don't browsers pre-include popular JavaScript libraries?

Every reasonably complex site I've worked on uses some form of bundler so even if a site uses a bunch of common libraries they are all compiled together into a big JS file.
I think that a lot of the way websites are developed would have to change to support such an initiative.

That's the most unique idea I've seen today.
It's is the same concept of OS drivers but for the browser ?
Like linux including python by default ?

this is actually an interesting idea