Should web browsers include popular web framework libraries?

Question

What reasons are there for web browsers to not have a library of popular web frameworks.

For example if a web page included jQuery, why shouldn't the browser have it's own static version, which is separate from the normal cached items?

I would imagine if most libraries were preloaded into a browsers cache, before any request was made with a document that included a library, then this would remove the initial request to a CDN and have a potential performance improvement.

But if the browser 'preloaded cache' didn't include the library then the browser should request the resource that is included in the document.

• sleske: The question is a bit unclear. What makes you think there would be any advantag in having a static version inside the browser?
• Deanos: The only advantage I could see is that it would remove the need for the initially request and potentially deliver a performance increase.
• Ryathal: isn't this the reason the Jquery site advocates using the google hosted version so that users have one version that works for tons of sites.

Answer 1

Because within a month, the browser's built-in version of jQuery would be out-of-date, negating the whole reason for using a third party library in the first place. Within 6 months, developers would be wanting to use features in the latest release of jQuery that weren't in what was built-in to the browser, but they wouldn't without including the whole new version of jQuery - negating the whole reason of bundling it in in the first place.

Browsers should follow and implement standards and developers will benefit years later when the older browsers stop being used or by writing browser-specific code to take advantage of the newest features. The path for browsers to get more jQuery-like functionality is via that standards process.

The whole point of the cross browser framework is that you can specify one specific version of the framework and know that you get the exact same behavior everywhere right now because that version of the framework takes care of it for you. That would never be the case with built-in frameworks (because the web developer is stuck with a different version of jQuery built into each targetted browser) so developers would just go about including the latest version of the framework and now you'd not be leveraging what was built-in.

• Deanos: The browser would use it to save making a request, and improve the page performance.
• maple_shaft: Why not have then every known release of all popular JS libraries from a common CDN specifically for the browser? This solves the problem of various web apps requiring extremely specific versions of a JS library, and also has the added benefit of actively discouraging developers from including manual hacks within a framework library (which is far too common a practice unfortunately).
• jfriend00: @maple_shaft - how does that help you? Aren't all releases of jQuery on the Google CDN already? What are you asking for beyond that and how does it help you? Doesn't good web design practice already call for using one of the most common CDNs to promote use of a cached version of jQuery?
• Nilpo: Along with updates, most libraries have open copyrights that allow customization. The web developer, not the client knows which version the page was intended for.
• jfriend00: @Deanos - The browser would have to build in very specific knowledge of a few things to look for and where to look for them (like jQuery versions from the Google CDN). It would save a small amount of page load time the first time that resource was needed, but it would use more total bandwidth anytime a cached item or version of that cached item was never needed. I suspect the benefits are relatively small vs. complexity or Google probably would have already tried it in Chrome with their own CDN. Keep in mind that things can live in the disk cache for a long time.