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,322
  • 2
  • 29
  • 62
  • 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 '12 at 18:30
  • 1
    Which version would you suggest they include? What about next week? – pdr Jan 27 '14 at 01:16
  • 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 – yardpenalty.com Jan 27 '14 at 00:45
  • @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 '14 at 10:38

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.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • 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 '12 at 13:56
  • thanks for all your reasons NOT to include in browser setup :-) – ozz Mar 14 '12 at 13:58
  • Also "Add confusion: why JQuery and not Prototype, or some other framework, image, CSS file, etc.?" - my question clearly states "JQuery and similar tools" – ozz Mar 14 '12 at 13:59
  • 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). – Arseni Mourzenko Mar 14 '12 at 14:00
  • *my question clearly states "JQuery and similar tools"*: what similar tools exactly? Can you give a list which will be accepted by every person in the world? – Arseni Mourzenko Mar 14 '12 at 14:02
  • Well, it would eliminate a performance hit on the first website that uses JQuery as it would already be downloaded. I appreciate this is a very small performance save. I guess it is that, plus it would possibly eliminate the need for using CDN's at all. – ozz Mar 14 '12 at 14:03
  • The question isn't supposed to solve the entire debate, it is only a question about the feasibility of including these types of things in the browser install. Everyone is saying it is not a good idea for various reasons, and I am fine with that! :-) – ozz Mar 14 '12 at 14:05
  • 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. – Arseni Mourzenko Mar 14 '12 at 14:08
  • 1
    @All If you would like to discuss this further then please take this to chat. – maple_shaft Mar 14 '12 at 14:23
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.

dan_waterworth
  • 7,287
  • 2
  • 34
  • 45
  • 1
    thanks Dan - any links I can read on what you describe? – ozz Mar 14 '12 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 '12 at 14:11
  • 4
    A root canal operation would make the DOM API more pleasant... – Donal Fellows Mar 14 '12 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. – Adam Crossland Mar 14 '12 at 14:57
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.

Adam Crossland
  • 9,688
  • 2
  • 35
  • 46
  • 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 '12 at 13:23
  • I've updated the question to mention that I am aware of caching :-) – ozz Mar 14 '12 at 13:57
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,133
  • 1
  • 28
  • 56