19

After reading another question about JQuery and CDN's, is it feasible for tools like JQuery to "come with" the browser, thus reducing/eliminating the need for the first download from a CDN, or from your own host server.

JQuery files specifically are pretty small, so you could easily have a number (all?) of the different versions as part of a browser install. Now fair enough, this would increase install footprint, download time for the browser itself.

Then sites could check "local" first, before CDN (which then caches), before finally defaulting to downloading from the website server itself.

If this is feasible, has it been done, and if not, why hasn't it be done?

ozz
  • 8,352

4 Answers4

16

Actually, what you're describing exists already for years. It's called caching. And it's available not only for JQuery, but for everything your browser may download.

Then sites could check "local" first, before CDN, before finally defaulting to downloading from the website server itself.

This is exactly what every browser does. It checks local cache first, then downloads one from CDN if need. With proper cache configuration, there is even no roundtrip to the server (to check for newer version) for months.

Including JQuery into the browser setup would:

  • Add unnecessary complexity to the browser application and setup,

  • Add unnecessary complexity to update process,

  • Increase the number of updates in order to keep the up-to-date version of JQuery, even for people who don't need it,

  • Add confusion: why JQuery and not Prototype, or some other framework, image, CSS file, etc.?

  • etc.

Increasing the complexity of a software product with no benefit in terms of features, performance, etc. is an extremely bad idea.

15

There's no technological reason why they couldn't. However, it's not necessary and it's against the web's fundamental philosophy. It's not necessary, because you can achieve almost the same thing with a far future expires header. It's against the web's philosophy because it causes there to be a top-down, centralized authority on which libraries should/shouldn't be bundled with the browser.

Edit: JS libraries are there, primarily, to make dealing with the DOM easier. I don't think bundling third-party libraries with the browser is the right way to make the DOM API more pleasant.

5

Browser caching provides something very much like what you are talking about. It should be the case that jQuery or any other JS library would be downloaded once and then retrieved from the cache on further requests.

While jQuery may be the most ubiquitous JavaScript library, it isn't the only one and it seems to me that making it a an installed component of the browser would be bad for the JS ecosystem. Competition is healthy and generally leads to innovation, and we developers and software users would not be well-served by giving jQuery a special position.

Once you take caching into account, the advantage that you gain is very, very minimal. The minified version of jQuery is only 31K. That's no rationale for changing anything.

5

Don't forget that jQuery is a js library, it seems to have become the de facto one and seen as a panacea (to the point of becoming memeworthy on SO), but it is just a js library.

Everything that is standardised for scripting (EMCAScript) is included in the browser already, anything else added to other browsers would become non-standard and you'd end up with the cross-browser issues for non-standard browsers (like the IE event model) that influence part of the reason why libraries like jQuery have been created in the first place.

Short answer: they could be included, but they shouldn't.

StuperUser
  • 6,163