21

I'm using jQuery on several of my websites and although I use a CDN to serve it, it just doesn't make sense for visitor to download jQuery each time. jQuery must be the world's most widely used JavaScript framework - wouldn't it make more sense if browsers just have it installed by default?

In that way millions of times a day a download of jQuery could be prevented. Either from people's own websites or from the CDNs.

All that would be really needed is some kind of if statement like:

 <!--[if jQuery gt 11]>

Does something exist that will help me prevent users making the trip to the CDN if they already have jQuery in their cache from another site?

Improve this question
12
  • 3
    the question is - why does a user need to make new downloads from sites or CDNs for something that he already has? jQuery is served from many locations and in many versions. I am concerned about page speed and users are concerned about (especially mobile) bandwidth. If there's a gold standard for a library - then why not use it? There are other examples sure and I would welcome those too - as long as there's an agreed upon standard for them (like a version number).
    – user1914292
    Sep 4, 2015 at 9:02
  • 27
    Why jQuery but not Angular, MooTools, Underscore, ...? And which versions of each? Should browsers contain copies of every JavaScript library ever made?
    – user253751
    Sep 4, 2015 at 16:12
  • 15
    "Sorry, you can't use my website until you upgrade to a 0.1 higher version of your browser"
    – VLAZ
    Sep 4, 2015 at 19:37
  • 4
    Relevant
    – Charlie
    Sep 5, 2015 at 13:43
  • 4
    caching is made for that. otherwise, version handling would be basically impossible
    – njzk2
    Sep 5, 2015 at 17:39

5 Answers 5

Reset to default
55

If you serve jQuery from a popular CDN such as Google's Hosted Libraries or cdnjs, it won't be redownloaded if your visitor has been on a site that referenced it from the same source (as long as the cached version has not expired).

jQuery is a popular library, just as you say, but bundling it with the browser is not likely to happen for a few reasons:

  1. jQuery is relatively small (compared to libraries that are sometimes bundled in browsers, like Flash). The largest performance bottlenecks on the average site are unlikely to be due to downloading jQuery.
  2. Improvements to JavaScript/ECMAScript mean that developers are increasingly not required to depend on jQuery. (See youmightnotneedjquery.com.)
  3. There are a great many other popular JavaScript libraries. Browsers are not designed as repositories for JavaScript code. Tracking script popularity, dropping less popular libraries, and keeping everything up-to-date may be best left to web developers of individual sites.
Improve this answer
11
  • I understand this, but I am now using code.jquery.com as CDN. However, when another website uses googleapis or cdjns the browser will AGAIN download jQuery from that other CDN. That just doesn't make sense and costs a lot of time/bandwidth all over the place. If you add to this that in most cases people would like something like jQuery1.7+ then it gets even worse. I understand your point about browsers not being repositories, but wouldn't we be able to come up with some kind of 'cache from multiple sources' kind of rule?
    – user1914292
    Sep 4, 2015 at 8:57
  • 24
    @user1914292 This would only be useful if all the browsers had all the versions of jQuery ever in existence, and if it intercepted any requests to any known source of jQuery, replacing it with the cached version. If there's even a tiny difference, it might cause bugs that are impossible to debug. This is further aggravated by the fact that web caching works, and has worked for decades. Your browser is not the only thing that caches those jQuery requests - many of the routers on the way to your browser do the same. The problem has been solved long ago, when bandwidth did matter :)
    – Luaan
    Sep 4, 2015 at 11:22
  • 4) What if the jquery code on a particular site depends on a function that's been fundamentally altered in a recent update and no longer does what the code expects it to do?
    – Shadur
    Sep 5, 2015 at 11:21
  • 1
    @Ejay no, it doesn't work as a tracking mechanism because 99% of the time the request gets served from your browser cache.
    – suriv
    Sep 6, 2015 at 20:06
  • 1
    @BenSteward Yes, use your browser's dev tools and check the Network panel. Chrome, for example, will show cached resources with “disk cache” or “memory cache” in the “size” column and a ghosted value in the “status” column (as long as you don't have “Disable cache (while DevTools is open)” active in the dev tools settings). It can depend on cache control headers and other factors as to what gets cached and for how long. developer.mozilla.org/en-US/docs/Web/HTTP/Caching
    – Nick
    Sep 25, 2019 at 6:57
21

Not only is jQuery not the only popular JS library, a browser would potentially have to include multiple versions. The Google CDN currently lists: 42 versions of jQuery; 44 versions of jQuery UI; 6 versions of jQuery Mobile.

It's better to allow web developers to define which version of a library to download based on their website's requirements. If you use a current production version of jQuery on your website and load it from a more popular CDN, then there's a good chance your visitors will already have it cached anyway.

Improve this answer
14

The browser is the engine it isn't the engine designer's duty to find out what kind of fuel and extra parts are you going to put into your car and include it for you. If they would do this browsers would be a huge bloatware because the next question will be "why just jQuery?", and we would end up maintaining dependency repositories.

Also, will we include all versions? What if somebody would like to use a custom version? What if somebody wouldn't like to use that library? How often they will merge and roll the latest releases? Will we end up with different browsers with different versioned jQuerys? They can't even equally implement standardised HTML, CSS and JavaScript functionalities. What if one of the browser maintainers aren't going to include a library or its specific version?

Browsers provide building blocks and an environment for you to build not an already finished solution.

Putting jQuery into the browser isn't going to make your site load blazingly fast because in nowadays this isn't the biggest bottleneck, however we can agree that jQuery is a needlessly big library but its purpose was never to be a fast library (considering bandwidth). There are many other libraries that were specifically designed around fast loading and to be lightweight like Zepto.

If you really that concerned about jQuery's size and bandwidth usage, then don't use it. Have you ever heard about Vanilla JS? It is an even more popular library that is used literally by almost everybody including jQuery itself! And it already fulfilled your dream because it is included in every browser!

Improve this answer
2

A reason for using a library like jQuery is compatibility.

Browsers have become more standard-complying, but by using the jquery library, you supply yourself, you don't have to worry about differences between browser families and versions

By supplying the jquery yourself, you are sure to have a consistent api.

If we have the jquery built into the browser, you have to check which version the user have, and we are back into the browsersniffing and "This site is best viewed in ..."

So having the jquery build into the browser does not make sense.

Also, caching works, so even if the user does not already have your jquery version, it only needs to be downloaded once.

Improve this answer
0
-2

I actually think the responders on here fail to understand that the answer to the question is browsers probably should look to include the most widely used libraries, and polyfills etc on the client side.

As the person asking the question states, conditional comments could be used to ensure that those using browsers that don't include jquery were served an appropriate version.

Jquery also includes it's own backwards compatibility support through migrate, allowing for conditional comments to give retro support for someone with a packaged version of an older jquery library without downloading a whole new library.

The argument FOR including these in browsers would be not just about user experience and cost, but also about this planet we live on. The use of data is a huge contribution to global pollution, and ensuring that needless data transfer is minimised could have a dramatic effect on our carbon footprint.

In essence for the sake of adding an additional few megabytes of code bloat in a packaged browser - the same data is being needlessly ferried about billions of times a day.

That worsens user experience for everyone on the internet. And costs major businesses huge amounts of money.

As a developer you would just create the necessary fallbacks required as we do currently for IE etc, so what's the problem - it probably should be included surely?

Improve this answer
5
  • 1
    This is tangential to the question. The question is "why don't browsers, and what can I do about it", not "why should browsers."
    – Stephen Ostermiller ♦
    Jul 29, 2017 at 16:47
  • The OP, while pondering your point, is interested in reducing traffic to the CDN if the framework already exists within the browsers cache possibly even from another site. Personally, I cannot see how unless there is a common way to reference the framework.
    – closetnoc
    Jul 30, 2017 at 1:30
  • Most people have failed to also say the most relevant answer to the question and that is jQuery is not a web standard and browsers only run web standards which change slowly and are based on fundamentals. jQuery was originally created to make fundamentals work consistently between browsers so including jQuery is like including a patch to fix browsers but browsers already fix themselves eventually. Already we see the diminished use of jQuery as partly evidenced by the many "You don't need jQuery" articles around nowadays.
    – Rob
    Jul 30, 2017 at 2:47
  • 1
    Stephen. The quesiton is not "why don't browsers, and what can I do about it". That's your rehash of it. The question is why don't they, and the person asking clearly states that simply doing this and creating a new framework for dealing with issues that arise would actually have a huge potential benefit to all web users.
    – Andy Bbop
    Oct 31, 2017 at 22:42
  • You all need to stop defending your outmoded preconceptions and accept you can all still learn. Oh, and also learn to actually read something. #Weapons. "The OP, while pondering your point, is interested in reducing traffic to the CDN". No he says it could save huges amounts of bandwidth whether at the client side or CDN. Read the effing post.
    – Andy Bbop
    Oct 31, 2017 at 22:49

Your Answer

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

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