Linking to jQuery: Always Reference a Specific Version

If you use jQuery, then you probably have a URL in a <script> tag like this in your source code:

http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js

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:

http://ajax.googleapis.com/ajax/libs/jquery/1.7/jquery.min.js

Notice the less specific version number — “1.7” instead of “1.7.2”.

Or, even worse:

http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js

Notice the whole version number — “1” instead of “1.7” or “1.7.2”.

Or, worst of all:

http://code.jquery.com/jquery-latest.js

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.