By Craig Buckler

What’s New in jQuery 1.9

By Craig Buckler

jQuery 1.9 was released on January 15, 2013. The version marks an important milestone in jQuery’s evolution:

  • several deprecated features have been removed to provide a slimmer, cleaner library in preparation for version 2.0
  • it will be the last to support IE6, 7 and 8 (more about that below).

Don’t rush off and download it just yet — there are a number of migration issues to consider. The long list of 1.9 changes means few sites are likely to escape unscathed.

jQuery Migrate Plugin

The jQuery Migrate Plugin should ease your upgrade woes. The plugin provides two essential facilities:

  1. it re-enables deprecated features so your v1.8-compatible code will work again, and
  2. it logs warnings to the developer console when deprecated features are used. You should find it easier to fix issues.

The migrate plugin should be loaded immediately after jQuery, e.g.

<script src=""></script>
<script src=""></script>

It can also be used when (if?) you upgrade to version 2.0.

Removed Features

This should not be considered a definitive list of removals, but they are the most likely to cause compatibility problems. As always, thorough testing is your best option…

  • jQuery.browser() — removed
  • .live() events — use .on() instead
  • .die() — use .off() instead
  • .andSelf() — use .addBack() instead
  • .add() — nodes are now returned in document order with disconnected nodes (those not in the document) at the end. All sets which contain disconnected nodes follow this behavior
  • .after(), .before(), .replaceWith() — now return an unmodified jQuery set
  • .appendTo, .insertBefore, .insertAfter, .replaceAll — if no elements can be selected by the target selector, e.g. $(elements).appendTo("#not_found")), the resulting set is now empty
  • Ajax events must be attached to the document — not a DOM node, i.e. $(document).ajaxStart(...); rather than $("#node").ajaxStart(...);
  • radio/checkbox click events — now returns the checked state rather than the state it would have been in if .preventDefault() were not called
  • Order of focus events — blur events on the previous element are now fired prior to focus events on the new element
  • jQuery(htmlString) — htmlString is only considered to be HTML (rather than a selector) if it starts with a ‘<‘ character
  • .attr() — you should normally use .prop()
  • “hover” pseudo-event — “hover” is no longer supported as a synonym for “mouseenter mouseleave”
  • jQuery.ajax returning an empty JSON result — this is now considered to be malformed JSON and throws an error

New Features

Other than streamlining and bug fixes, there are relatively few new features…

.css() multi-property getter
It’s now possible to pass an array of CSS property names to the .css() method. It returns an object with the current values, e.g.

var dims = $("#box").css([ "width", "height", "backgroundColor" ]);
// { width: "10px", height: "20px", backgroundColor: "#D00DAD" }

CSS3 selector support
The Sizzle selector engine supports the following CSS3 selectors in all browsers: :nth-last-child, :nth-of-type, :nth-last-of-type, :first-of-type, :last-of-type, :only-of-type, :target, :root, and :lang.

.finish() method
The .finish() method stops all queued animations and places the element(s) in their final state. This could be handled in previous editions using combinations of .stop() and .clearQueue(), but .finish() is easier to use.

Source map support
Source maps allow you to debug a production site which uses minified scripts or CSS. In essence, the browser’s debugger maps lines in the compressed file to the uncompressed source so it’s easier to view code, set breakpoints, change values etc. Look out for further articles on SitePoint soon…

Abandoning Legacy IEs

The ‘oldIE’ decision has divided opinion; some developers consider it premature, while others think any idea which aids the demise of IE6, 7 and 8 is a blessing. I have a number of concerns:

  • StatCounter estimates IE6/7/8 usage to be around 13% and NetMarketShare places it 32%. Whatever you believe, legacy IEs are not dead and unlikely to be buried by the time jQuery 2.0 arrives.
  • The jQuery team recommend conditional comments to load either jQuery 1.9 or 2.0 depending on the user’s device. It’s browser sniffing — a practice which should never have arisen in the late 1990s!
  • It’ll cause confusion. It doesn’t matter how many warnings are issued, some developers will install jQuery 2.0 without understanding the backward compatibility risks.
  • jQuery 2.0 will have an identical API to jQuery 1.9 (with oldIE code removed). Forking the code base will inevitably have consequences — especially as the v2.0 line evolves. You’ll require more thorough browser testing and how will you handle problems which arise in one version but not the other?
  • While there’s still work to be done, jQuery 2.0 beta is 10% smaller than 1.9. Let’s assume the team double that saving; the initial jQuery download will reduce by 6Kb. Will that result in noticeably faster browser response times? I doubt it.
  • The jQuery team will find v2.0 development easier, but what are the benefits to jQuery users? The library won’t necessarily execute faster — it already runs native browser APIs when they’re available. Which core features cannot be implemented in IE6/7/8?
  • Browser compatibility is one of jQuery’s biggest strengths. Without IE6/7/8 support, there’s less reason to use the library. Raw JavaScript is faster and mostly consistent in the other browsers.
  • Is the primary objective of any JavaScript library to push the web forward? Or should it be to aid development in current browsers regardless of opinion?

jQuery must evolve and that includes supporting new browsers and dropping unused ones. There’s a reasonable argument to abandon IE6 and IE7, but IE8 is the latest version supported on XP and it’s clear many Windows users are lethargic toward upgrading. Personally, I’d recommend sticking with jQuery 1.9 on any site which requires IE6/7/8 support. The risks outweigh the benefits of two code bases.

Time to Upgrade?

Those of a more nervous disposition may prefer to wait a few weeks for any issues to be resolved. You should also note that jQuery 1.9 is unlikely to be a straightforward file replacement and older code may need to be tweaked. That said, the Migrate Plugin offers a great interim solution should you experience problems.

Despite a few reservations about its future, jQuery remains the JavaScript library of choice for me and the majority of web developers.

    • Ben

      Toggle event with two function callbacks was deprecated. Toggle(true/false) for show/hide is still available I believe.

      So apparently I posted this too quickly so I’m just typing this sentence out so I can actually comment…

  • Nicely covered, Craig – thanks for highlighting the Migrate plugin, especially. Not sure that conditional comments really deserve to inherit the ‘browser sniffing’ taboo, though. That term usually refers to javascript-based techniques, which became taboo mainly because they’re so fallible. As only IE processes conditional comments, they are more efficient and less error-prone than feature-detection when applying a block of IE patches. To call them ‘browser sniffing’ risks newer devs throwing out the good with the bad. Of course, I’d still agree that it would be better not to need any of these techniques! :-)

  • I am happy they’ll remove ie6,7,8 support….

    a little less happy with removing hover since I use it quite a lot

  • Ignoring cross-browser compatibility, jQuery still provides:
    – a working Promise implementation, very handy for more complex web apps
    – easy to use AJAX methods
    – easy to use Event handling, I think using “on” is almost intuitive
    – convenient short-hand for working with the DOM

    I think I’ll continue to use jQuery 2.0 where possible, even though pure JavaScript would be faster. I would say that development is easier with jQuery than without it.

  • Ben

    I upgraded my website recently to 1.9, but downgraded the day after because of the JSON thing. I forgot about that, and ended up with 300 error emails! Anytime a JavaScript error happens on my order form I get an email. Whenever that email was sent, it would throw an error because it was JSON data type for some reason (nothing was returned so it doesn’t even need to be JSON!)… So I’ll have to check through a few more things before we go back.

    Also had to upgrade jqueryui to 1.10 because it had a few deprecated functions in it too.

    We had one instance of toggle being used as a click event rather than show/hide. Everything they marked for deprecation in 1.8 we had already replaced and stopped using :)

  • Nice post Craig. Hard to believe they are nixing support for IE8 in jQuery 2.0. That’s pretty extreme and is enough reason for me to stick with jQuery v1 for a while.

    Also, last week I noticed the datepicker plugin stopped working on about 60 of my sites. It took some digging but the cause was jQuery 1.9 which was automatically upgraded because I’ve been including jQuery from Google’s “latest” code library:

    Yowza! The fix was to use version 1.8.3 like this:

    • Dave Methvin

      Matt, when you use the /1/ URL from the Google CDN the file is served with an expiration date of a DAY which defeats much of the value of the cache. When you use the full URL with version, it is cached for a YEAR; since the file served by the full version won’t ever change it is safe to cache for a long time.

  • Kenny Landes

    Change is good. I won’t cry any tears for IE 6, 7, or 8, and applaud jQuery for dropping support. We’ve known this was coming for a year or so now, and even Microsoft is actively engaging in getting people to at least IE9, with IE10 soon to be released for Windows 7.

    While I understand the author strongly advocates for supporting every possible configuration, it’s really bad practice to do so. The argument is essentially that because there may be some user out there using IE6, the whole world should continue to support it even though it is obsolete. The same argument might say that because there might be a user out there using Windows 95, software developers should continue to develop Win95 compatible applications. This, of course, is absurd, and software development companies suffer no fools in this regard.

    In nature, there is survival of the fittest. It has served nature well. The same evolutionary principle should exist on the web, and IE 6, 7, and 8 are simply no longer fit. They should be left out to die along with other obsolete technologies such as Mac OS 8, 9, and early versions of OSX, and Win 95, 98, ME, XP and the wicked Vista. There are excellent reasons these technologies are no longer supported.

    The role of a web developer is not to provide artificial life support for obsolete technology. In dropping support, jQuery is mercifully striking a likely fatal blow to IE 6-7-8. Thank you for that, jQuery. All the other changes fit in the category of evolution. The author’s protests make him sound very, very old.

    • Kenny, although it would be nice if survival of the fittest were true, it doesn’t quite work that way in real life. Maybe you missed the comment above you where ckdesigns says they have a client with 65% of their web traffic coming from IE8. If they stopped supporting IE6-8, do you think that client would continue as a client? I think not.

      However, I do think that Craig maybe overdid it a little bit with the protestations against the IE6-8 support being removed. I don’t think any of the recent versions of jquery have introduced ‘must-use’ features, and I doubt that future ones will either. Just improvements. So if you have a large userbase on IE6-8, just stick with an older version of jquery.

    • Change is great. It’s just a shame you’re changing before your clients/visitors. How many of them will drop IE because your site adopts jQuery 2.0? They’ll just think your site’s broken and go elsewhere.

      And when did supporting multiple browsers become “really bad practice”? The web is device agnostic — that’s its strength especially when compared with desktops. User experiences may be different, but there’s no reason why a user shouldn’t see something regardless of their device.

      As for survival of the fittest, since when has technology/business followed evolutionary rules? Betamax was better than VHS. Blueray wasn’t necessarily the best DVD successor. IE holds a massive market share and Opera deserves more.

      Legacy browser compatibility is a major reason to use jQuery. That reason disappears from v2.0.

  • I’m glad they are removing IE 6/7/8 support, I’m sure they had a lot of good reasons, and it really depends upon the target of your project. 90% of my projects are back end tools where I know the users use IE9, and jQuery 2.0 is perfect. For the other 10% that are public facing, I’ll just keep using jQuery 1.9.

    This is a bold step forward for the jQuery team, and it excites me.

  • WordPress automatically uses the latest version.. so that’s now using 1.9. Because of that, plugins that use $.browser variable have issues, like the Royalslider. Because of the auto-use of the latest version, you can have weird issues all of a sudden. Other than that, does anyone know how to modify wordpress’ default setting of using the latest jquery version? Thanks!

    • ckdesigns

      Just looking into this, a quick search and I found this-

      I assume you will need to do some php work but I have not followed all the links.

      • Thanks. I tried that.. Didn’t work. I tried to put a php function in the header.php, in the functions.php.. all the tips and tricks people come up with, but it just doesn’t work. WP still loads the latest version…

    • Dave Methvin

      Just include the jQuery Migrate plugin, that should allow you to use the plugin until they upgrade.

      • I couldn’t find the plugin on wordpress’ site.. and have never worked with the files from the official jquery migrate site. I did look tho to see how it would work and added the js stuff to the header.php file in my theme. This fixed it. Thank you very very much!

  • Christian

    I too am a big proponent of moving the web forward but I think there may have been some dunderheadedness involved in this 1.9 “upgrade.” A better solution would be to leave in support for the now deprecated features and then the developer could remove them all in one big chunk if they wanted. I also had the same concerns you mentioned here floating around my mind but you crystallized them much better.

    Also, are there replacements for .after(), .before(), .replaceWith()? I actually used those…

    There was also some actual need for jQuery.browser() since even browsers that use the same rendering engine (e.g., Safari and Chrome) don’t always behave exactly the same.

    • ckdesigns

      I agree with you completely. I don’t like the fact that these browsers were dropped, the company I work for supports a large number of clients who see 65% of their web traffic coming from IE8, almost all of these clients are using some sort of CMS. Eventually we will need to upgrade their CMS’s because of security vulnerabilities, but popular CMS’s try to keep third party plug-in’s up to date so eventually the clients will have to choose to either paying a bunch of money to keep their site safe and dropping a bunch of web traffic OR not upgrading, hoping and praying they don’t get hacked.

      I suppose the third option for clients with small budgets is making a static site just for older browsers…

    • Dave Methvin

      > Also, are there replacements for .after(), .before(), .replaceWith()? I actually used those…

      They were not removed, the article is incorrect. Their behavior has changed in some unusual corner cases that your code probably does not encounter, but we have described them to ensure that everyone knows what changed.

    • Aaron

      @Christian re: .before(), .after(), .replaceWith()
      I don’t think those are removed, just that the return values have changed. It’s unfortunate that the heading “Removed Features” makes it look like all those things are now gone.

  • Dave Methvin

    Sorry, but there is a *lot* of incorrect information here. Most of the things under “Removed Features” have not been removed. jQuery 1.9 supports ALL browsers and at present 2.0 is primarily intended for use in non-web-site applications as described on the blog. Please refer to the jQuery blog posts and upgrade guide for accurate information.

    • Version 2.0 is still a beta? It’s not been released and isn’t likely to appear for several months.

      And what is meant by “non-web-site applications”? Are you suggesting v2.0 shouldn’t be used on a typical content site? If so, where does the boundary lie? Is a comments facility an application? What about an image gallery?

      Haven’t you — or the jQuery pages you’re reading — just added to the overall confusion?

      • Dave Methvin

        > And what is meant by “non-web-site applications”? Are you suggesting v2.0 shouldn’t be used on a typical content site?
        ” If you’re using jQuery in non-web-site HTML situations such as an Android, iOS, or Windows 8 app, or a Chrome/Firefox add-on, jQuery 2.0 is an awesome choice”

      • That’s basically saying – if you’re not targeting desktop browsers, jQuery 2.0 is a good solution. That’s nothing to do with applications vs websites and, realistically, how many people are doing it?

      • Adamantus

        This appears false:

        “Just remember, jQuery 2.0 doesn’t work on IE 6, 7, or 8!”. Which is unambiguous. There is no mention of adding old IE back in for 2.0.

        “If you’re using jQuery in non-web-site HTML situations such as an Android, iOS, or Windows 8 app, or a Chrome/Firefox add-on, jQuery 2.0 is an awesome choice. You can even use jQuery 2.0 on web sites if you don’t support oldIE or don’t mind using conditional comments:”

        I interpret this to mean that IE 6, 7, 8 is removed in 2.0 as this article suggests.


        “jQuery 2.0 will not run on oldIE. As a result of removing several layers of barnacle-encrusted code, it will be both faster and smaller than jQuery 1.9.
        The team is supporting both jQuery 1.9 and 2.0 into the future. You choose which version you want to use based on your needs.”

  • Tim

    I do not see any problem in dropping support for old browsers in new jQuery Version.

    Normally in professional projects, you know your users and can decide what to support and how to support it.

    Scenario One: You have IE Users and you cannot or do not want to indoctrinate them to use a “State-of-the-art”-browser. You go for jQuery 1.9 till your IE users die.

    Scenario Two: You do not have or expect to have IE Users. Use jQuery 2.

    Scenario Three: You have IE Users and your ability to indoctrinate them is awesome. Use jQuery 2 and tell your IE<9 users to download an "modern" browser…

    Our Company Scenario is: jQuery 1.6.1 works well, jQuery 1.7+ produces javascript errors and does not work with some older plugins we use. We will probably stick to jQuery 1.6.1 for the next years… No real Problem with that.

  • arnold

    im quite surprised , I do think IE8 should be supported at least :(

  • ralph.m

    The main reason I would consider using a library over raw JS would be the smoothing over of browser differences. Dropping IE8 support seems to kick that right out the window.

  • Sam

    I agree with the decision to drop IE 6, 7 and 8 support. Whoever is using these browsers needs a kick up the rear to move on already, and it’s high time we web developers stopped coddling those sitting in a darkened corner of their room huddled in a ball terrified of change.

    You wouldn’t say to someone still using windows 98 “Oh yeah you’re right those guys at xxx company are terrible for not making a version of the application that works with your system”. You would tell them to upgrade their damn system.

    Seems to me most of those still on IE8 or less are mid to large companies who don’t want to spend any money upgrading infrastucture etc to support newer technology. Well sorry tough **** you have to move with the times like every body. Anyone with a reasonable knowledge of technology would have easily forseen that system upgrades would be needed every 5-10 years.

  • “.attr() — you should normally use .prop()”
    I don’t think so. The official API doesn’t say that, it just says that we should use prop() to manipulate DOM properties, which makes sense.

  • KC

    .attr() — you should normally use .prop()

    Uhm… no? Each one is suitable for a different purpose.

  • Adamantus

    Very good article. I’ll definitely be sticking with 1.9.x for a while now. Shame I only just really started to learn Jquery when this kicked off.

    What may be happening here is that Jquery is holding back on features due to browser compatibility and are beginning to get worried that a spritely competitor is on the horizon, one which doesn’t care about the old IE support.

    Either that or they are just trying to kill off these old browsers through force. I.e. force upgrades through broken functionality by using their massive 55% website presence.

    I hope that the old IE versions are gone soon. Newer browsers tend to have upgrades switched on by default for less educated users.

Get the latest in JavaScript, once a week, for free.