Don’t Use jquery-latest.js

Posted on by

Earlier this week the jQuery CDN had an issue that made the jquery-latest.js and jquery-latest.min.js files unavailable for a few hours in some geographical areas. (This wasn’t a problem with the CDN itself, but with the repository that provides files for the CDN.) While we always hope to have 100% uptime, this particular outage emphasized the number of production sites following the antipattern of using this file. So let’s be clear: Don’t use jquery-latest.js on a production site.

We know that jquery-latest.js is abused because of the CDN statistics showing it’s the most popular file. That wouldn’t be the case if it was only being used by developers to make a local copy. The jquery-latest.js and jquery-latest.min.js files were meant to provide a simple way to download the latest released version of jQuery core. Instead, some developers include this version directly in their production sites, exposing users to the risk of a broken site each time a new version of jQuery is released. The team tries to minimize those risks, of course, but the jQuery ecosystem is so large that we can’t possibly check it all before making a new release.

To mitigate the risk of “breaking the web”, the jQuery team decided back in 2013 that jquery-latest.js could not be upgraded to the 2.0 branch even though that is technically the latest version. There would just be too many sites that would mysteriously stop working with older versions of Internet Explorer, and many of those sites may not be maintained today.

As jQuery adoption has continued to grow, even that safeguard seems insufficient to protect against careless use of http://code.jquery.com/jquery-latest.js. So we have decided to stop updating this file, as well as the minified copy, keeping both files at version 1.11.1 forever. The latest released version is always available through either the jQuery core download page or the CDN home page. Developers can download the latest version from one of those pages or reference it in a script tag directly from the jQuery CDN by version number.

The Google CDN team has joined us in this effort to prevent inadvertent web breakage and no longer updates the file at http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js. That file will stay locked at version 1.11.1 as well. However, note that this file currently has a very short cache time, which means you’re losing the performance benefit of of a long cache time that the CDN provides when you request a full version like 1.11.1 instead.

So please spread the word! If you see a site directly using the jQuery CDN’s jquery-latest.js or the Google CDN equivalent in their script tags, let them know they should change to a specific version. If you need the latest version, get it from the download page or our CDN page. For both the jQuery and Google CDNs, always provide a full version number when referencing files in a <script> tag. Thanks!

16 thoughts on “Don’t Use jquery-latest.js

  1. after reading these:

    “We know that jquery-latest.js is abused”

    “The jquery-latest.js and jquery-latest.min.js files were meant to provide a simple way to download the latest released version of jQuery core”

    I wonder why you don’t simply put a download button with latest instead of keeping this version in the CDN.

    Having it there is like a colorful candy/chocolate bar for developers.

    If the message is “DON’T USE LATEST FROM CDN” and it’s for dev purpose only, put in such version only a console.warn(“latest support from CDN is being removed”) for 3 months and drop it after that time.

  2. The blog addressed this. Many of the sites using this bad practice are essentially unmaintained. No amount of warning period will prevent them from breaking, and users will suffer. Smart developers (the ones reading this blog) will get the message and not use the jquery-latest file.

  3. PhistucK on said:

    I am also in favor of a console warning. Not a deprecation warning, but a simple warning for those who simply do not know that.

    try{console.warn(“The version of jQuery used by this page is not meant to be used in production. Also, it is no longer updated, so there is no use for it anymore. For more details, see http://blog.jquery.com/2014/07/03/dont-use-jquery-latest-js/“);}catch(e){}

    That should be enough for the innocent cases of sites that are maintained by developers who simply thought they were following the rules and should not worry about any breakage.

    Frankly, I cannot think of a reason not to add such a warning right now.

  4. A warning is fine, and we’ve talked about doing this once this announcement was made. However, I doubt we’d ever be able to remove the files in the next decade.

  5. It’d be more important to contact tutorial authors who are using latest.js in their tutorials then contacting more or less maintenanced websites I think.

  6. There may have been a time that they did want people to link it (collecting analytics info possibly) but the long term disadvantageous have outweighed the benefits of data collection.

  7. PhistucK on said:

    @Dave Methvin –
    Yeah, I do not think removing it would be an option. When are you going to add the warning?

  8. Chris on said:

    A warning comment, near the top of the files, would help.

    Perhaps nudging users towards Bower would help as well.

  9. mohsen s on said:

    how can i download a custom version of JS 1.8.3?
    1.9 can not support my codes. tnx for advance.

  10. Darryl Miles on said:

    Simply have the CDN insert a 1 second delay before serving the file contents (of jquery-latest.js).

    Consumers will soon stop using it in production sites.

  11. chuckdries on said:

    @Andrea like they said, they don’t want to break sites that are no longer being maintained. If they did that, they would break every single site that doesn’t have an active developer.

  12. I think you should just break all those old sites, it’s a win-win: jquery-latest is actually the latest, and all the freelance developers out there get paid an hour of work for each site to go around fixing them up.

  13. To really annoy devs without breaking production sites, have a javascript alert pop up if the document domain or location host contains ‘localhost.’

  14. Mark Ernst on said:

    In response to the first comment by Andrea, I agree, serve it as a download. even better, just set the headers as an octet-download stream which forces the download. :)

    Good to know we’re not alone in this as we used it as a CDN file as well on a couple of sites.