If you use jQuery, then you probably have a URL in a
<script> tag like this in your source code:
CDN-hosted. Minified. Specific version. Very good.
Of course, if you’re one of the cool kids, then you might be doing the following, as taken from HTML5 Boilerplate:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script> <script>window.jQuery || document.write('<script src="js/jquery-1.7.2.min.js"><\/script>')</script>
This ensures that if an edge-case scenario occurs in which the CDN-hosted jQuery is momentarily down, you fall back to a locally hosted version. And bonus points for the protocol-relative URL.
So all is good. Either of those methods is fine, and the latter is better.
The Wrong Ways
But I get the feeling that a few less experienced jQuery users are referencing jQuery like this:
Notice the less specific version number — “1.7” instead of “1.7.2”.
Or, even worse:
Notice the whole version number — “1” instead of “1.7” or “1.7.2”.
Or, worst of all:
Notice no version number, just a plain reference to the “latest” version, whatever that might be.
So why is it wrong to link to jQuery using one of those last three methods? And is it ever right to do that?
What About Development?
The only time you should link to jQuery using one of those three methods is during development or when experimenting. You should never use those methods in production.
In fact, by testing how things work in different point releases, you could find a bug and you’d help the jQuery dev team by reporting this. So there are cases, in development, where using these types of general version references could be handy.
Why Not Drop One or More Decimal Versions?
You’ll notice that if you link to jQuery version 1.7 (with the third decimal digit missing), this will automatically reference the most recent 1.7.x release. And if you link to jQuery version 1, this will take you to the latest 1.x release. Some people feel this is best, because it gives you the latest version.
Sure, it sounds good, and we certainly should want to use the latest version of any piece of code or software. But think about IE6 for a moment. Why was that browser’s market share so high for so long? It was because many enterprise applications were built specifically for that browser, and upgrading to IE7 or later would break those applications.
The same problem could occur if you link to a non-specific jQuery version. If you build your website for jQuery 1.7.2, then, unless you later upgrade your code or do thorough testing, you need to ensure that the site references and uses only the 1.7.2 release and nothing later.
Even from one point release to another, there is the potential for breaking changes. For example, Paul Irish tells me that jQuery’s
$.browser property will be deprecated in jQuery 1.8. There are other deprecated features that will stop working in later versions, potentially even small point releases.
Yes, even from 1.7.2 to 1.7.3 there could be a breaking change. Although it’s probably unlikely to happen, the mere possibility is enough to demonstrate that it’s not safe to link to jQuery without referencing a fully-specific version.
What About jquery-latest.js?
Naturally, the same principle applies to this. The jquery-latest.js file that’s hosted on jQuery.com seems to always link to whatever is the latest version. But that file is not even minified. It’s obviously not put there for production-level code.
Any Further Technical Thoughts?
If anyone has any specific examples of changes that may have broken a site or app’s functionality in a point release, or if you have any other technical info on why this isn’t a good idea, please comment.
I’ll be happy to update the article if I’ve misstated anything.
Another point to notice is that the “unspecific” urls don’t set a “far-future expires header”, so they won’t be cached by the browser (or at least not as long as the specifivc version)
http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js expires in 1 year (so probably NO request at all, as there is a big chance that the user has this file already in cache from another website)
http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js expires in the PAST, so it won’t get cached at all
Good you are mentioning that! I thought that this would be the main concern in this article but it wasn’t addressed. Thanks for pointing out.
Louis, I think this somthing that should be added to the article.
I think I’ll leave it as it is. This article isn’t really about caching. I also don’t think that caching a single library file is a critical performance boost. There are many more important things to do to improve performance.
Also, since this is the first comment, people will find it easily. :)
Thanks for this, Louis, as I’ve recently debated how to best address this, and great points about features breaking. Nothing like having to tear apart our code, only to find the jquery version switched with depreciated features on our live site.
Good point I’ve seen people get caught out with this before. A couple of versions ago they changed the way you identify if a checkout is checked and that broke a few if statements. It’s always best to test before upgrading to a new version of any third party software.
Very useful article. Have seen quite a lot of sites using latest jquery version developed by agencies.
I have to disagree – if you write good gode, there will be no problem while updating 1.x to 1.x …
I’am fine with http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
Well, it has nothing to do with whether you write good code. Also, your advice is going against the advice of one of jQuery’s team members who told me himself that you shouldn’t reference jQuery in production like that.
In most cases this is fine. I just ran into an issue today. Seems library was updated and it broke some of my functionality. Rolled it back to 1.7.2 and all is well. Lessoned learned and great article.
Hey thanks so much for this. Came in this morning to find that sub menus would no longer appear. Wasn’t sure what was going on … this was the issue …
excellent scripts, I hope I serve to my projects
Brilliant, thanks for taking the time to write the article. We’ve been struggling and your “edge-case scenario” item nailed it. Many thanks.