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?

  • 3
    When a particular JavaScript function becomes so ubiquitous that it's seen as being needed everywhere, it's added to the language. Array.prototype.forEach, Array.prototype.indexOf, Object.create are all examples of code that got bundled into the JavaScript engine itself.
    – zzzzBov
    Mar 14, 2012 at 18:30
  • I am sure Chrome will come up with a solution that offers the end-user the option to install an extension with the ability to cache the necessary jQuery/javascript files when a site is first rendered? If the user declines it forces the request as per usual. The option "don't ask me again" could disable this option. There could be an area in the settings where the end-user can select which js files to store in browser cache using a simple checkbox list. There will always be custom js sent to the client, but it seems that eliminating the js files being sent to client per request would optimize p Jan 27, 2014 at 0:45
  • 1
    Which version would you suggest they include? What about next week?
    – pdr
    Jan 27, 2014 at 1:16
  • @pdr - old question, with lots of answer to the negative for doing this. BUT you could easily bundle the latest version with the browser release and allow the user code to fall back to requesting a newer version from CDN if required. With breaking changes like JQuery 2.0, you could have both and allow the code to choose. All a mute point though really :)
    – ozz
    Jan 27, 2014 at 10:38

4 Answers 4


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.

  • 1
    thanks Dan - any links I can read on what you describe?
    – ozz
    Mar 14, 2012 at 13:19
  • 1
    I would argue that needing to download megabytes upon megabytes of common libraries every time I request a page goes against another fundamental web philosophy of keeping web pages small and accessible. Many people are still on modems and slow satellite connections after all.
    – maple_shaft
    Mar 14, 2012 at 14:11
  • 4
    A root canal operation would make the DOM API more pleasant... Mar 14, 2012 at 14:21
  • 1
    @maple_shaft, that's a somewhat specious argument. The minified jQuery distribution is 31K. While it is certainly the case that there are web pages out there that load a crazy number of different libraries, the question is specific to jQuery, and there's no accounting for crappy programmers. Mar 14, 2012 at 14:57

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.

  • Thanks. Yeah, I wasn't clear in my question. I am WELL aware that is what happens. I am talking about eliminating the need for even the first download. I'll update the question.
    – ozz
    Mar 14, 2012 at 13:56
  • thanks for all your reasons NOT to include in browser setup :-)
    – ozz
    Mar 14, 2012 at 13:58
  • 6
    You can't eliminate the need for the first download. If JQuery is included in the setup, it is downloaded for the first time when the person downloads the setup executable (then it is downloaded again through updates when a new version of JQuery is released). Mar 14, 2012 at 14:00
  • 2
    It doesn't eliminate the performance hit, but moves it from the visit of the first website to the downloading of the setup executable, which means that overall, this is the opposite of a performance save. It doesn't eliminate the need of CDN neither if you want to support older browsers and browsers not updated since the release of the last JQuery version. Mar 14, 2012 at 14:08
  • 1
    @All If you would like to discuss this further then please take this to chat.
    – maple_shaft
    Mar 14, 2012 at 14:23

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.


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.

  • thanks Adam - yep, I know the first download, cache scenario. My thoughts are to replace that as well. JQuery was only 1 example but I agree with your thoughts on competition, this seems like it might be the main reason what I suggest doesn't happen. You'd then have different browsers having different sets of "default" components etc.
    – ozz
    Mar 14, 2012 at 13:23
  • I've updated the question to mention that I am aware of caching :-)
    – ozz
    Mar 14, 2012 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.