By Craig Buckler

What’s New in jQuery 2.0

By Craig Buckler

The second branch of the web’s most popular JavaScript library was released on April 18, 2013. jQuery 2.0 is now available for download but don’t rush off and install it just yet — there is one major change…

No More Support for IE6/7/8

(or IE9 and IE10 if they’re used in “Compatibility View” mode).

I still think it’s a little premature to abandon IE8 but the team couldn’t wait any longer. jQuery 2.0 removes all the legacy IE code for node selection, DOM manipulation, event handling and Ajax.

This has resulted in a 11% file size reduction from 32,819 bytes to 29,123 bytes. That’s 3.6Kb for the gzipped minified version — it’s unlikely to be noticeable even on a dial-up connection. Admittedly, the team hoped to save more but discovered that Android/Webkit 2.x browsers still required many workarounds.

If you need to support IE8 and below, stick with jQuery 1.9.x for now. You could conditionally load version 2.0 in all other browsers, but:

  1. conditional loading will offset any gains in file size reduction and processing, and
  2. you may encounter differences between the two jQuery branches. The team has pledged to minimize API divergence but there will almost certainly be issues. jQuery 1.10 will address known compatibility problems.

Custom Builds

The custom build feature has been refined in version 2.0 so you can exclude any of 12 unused modules and shrink jQuery below 10Kb. The modules which can be omitted are:

  • ajax: all Ajax functionality, transports, and event shorthands.
  • ajax/xhr: XMLHTTPRequest Ajax transport only.
  • ajax/script: <script> Ajax transport only.
  • ajax/jsonp: JSONP Ajax transport only (depends on ajax/script).
  • css: The .css() method plus non-animated .show(), .hide() and .toggle().
  • deprecated: deprecated methods (currently .andSelf() only).
  • dimensions: .width() and .height() methods, including inner- and outer- variations.
  • effects: the .animate() method and its shorthands such as .slideUp().
  • event-alias: event attaching/triggering shorthands such as .click().
  • offset: the .offset(), .position(), .offsetParent(), .scrollLeft(), and .scrollTop() methods.
  • wrap: the .wrap(), .wrapAll(), .wrapInner(), and .unwrap() methods.
  • sizzle: the Sizzle selector engine. When this module is excluded, it is replaced by a rudimentary selector engine based on the native querySelectorAll method which does not support some advanced jQuery selectors.

For example, if you are using CSS3 animations rather than jQuery methods, you could omit the effects module and possibly dimensions, offset, wrap and sizzle.

Creating your own custom build is not for the faint-hearted and you’ll require some knowledge of Git, Node.js and Grunt. Full instructions are available but, longer term, I hope the team can implement an online build process similar to Modernizr.

Should I Upgrade?

It’s important to understand that jQuery 2.0 has API parity with jQuery 1.9. There are a small number of bug fixes but no new features.

However, if you’re one of those lucky developers who has dropped support for IE6/7/8, grab jQuery 2.0 and don’t look back.

  • so whats the point of upgrading it if it has no new features? rather than making a lighter file?…

    • A smaller file and marginally faster start-up is the main advantage. However, you will lose IE6/7/8 support, so that could be a big disadvantage.

  • Francesco

    I’m not entirely sure what you mean by “conditional loading will offset any gains in file size reduction and processing”.

    Why is that?

    • Because you need code to determine whether jQuery 1.9.x or 2.0.x can be used then load that library accordingly. Therefore, you could have two HTTP requests (loader and jQuery) rather than one. Even if you can handle it using just conditional comments, the browser still needs to do some extra processing (and it wouldn’t surprise me if some browsers loaded both versions).

      Ultimately, this makes a minor difference to real-world usage, but so does an extra 3.6Kb on a file.

      • Francesco

        Of course I can use only conditional comments, it’s possible, everybody does that all the time, why should it be different in this case? It would be crazy to write code to detect this!

        Yes, conditional comments are not “a good thing”, because they smells of user-agent sniffing, but there is no other way, even the HTML5 Boilerplate has them. A lot. And since we already use them for a lot of other things, I can’t see what is wrong in using them for this too.

        And if there was a IE version that loads both I believe we would have heard of it by now, since we’ve been using them for years and years. I would have been a major problem that could have broken lots of sites.

        I understand that 3.6k is nothing… and that you don’t like this idea of jQuery 2 at all ( :-) ), but… I still see no reason not to use both with conditional comments.

      • However you look at it, loading jQuery 1.9 in some browsers and jQuery 2.0 in others is an unnecessary overhead. Why are you doing it? What’s the advantage? I’m sure it’ll work fine and won’t cause any noticeable delays in most cases. However, at worst, your site will break in one version and not the other. Either way, you’ll need more stringent testing.

        Remember also that IE9 and below understand Conditional Comments. IE10+ and all other browsers do not. Can you guarantee your syntax will be correctly parsed in all browsers every time?

        Keep it simple:
        If you need to support IE6/7/8, use jQuery 1.9
        If you’re happy to support IE9+, use jQuery 2.0

      • Francesco

        You do have a problem with conditional comments, don’t you? :-)

        They’re perfectly safe to use, and IE10 not supporting them is not a problem. Firefox or Chrome (or anyone else but IE) never did, and that never was a problem.
        I can’t see the future, but there will be huge problems anyway the day they stop working… retroactively (?).

        The only reason to do it, anyway, is those 3.6k. If there really is an overhead with every single conditional comment, then I agree with you, it’s useless (and maybe even harmful) to do it. But if there isn’t… why not?

        At least until the two versions don’t diverge and there can actually be testing problems.

      • I have three problems with Conditional Comments:

        1. They’re browser sniffing.
        2. They’re rarely required.
        3. They encourage developers to apply workarounds to problems rather than fix the problem itself.

        But that’s beside the point. If you use CCs to load jQuery 1.9/2.0, you’ll see the code is an unruly mess which is easy to get wrong. It’s certainly not “safe” since you’re depending on a hack which negates the v2.0 CC in browsers which don’t support them.

        As for “why not” conditionally load jQuery, as mentioned, you’re adding unnecessary complexity and the risks outweigh the benefits. Perhaps you’re 100% certain jQuery 1.9 and jQuery 2.0 have identical APIs? I’m not — and nor is the jQuery team otherwise they wouldn’t have promised to fix known differences in the next release.

      • Francesco

        I used to hate conditional comments too, mainly for reason 1, they really are browser sniffing and that’s evil.

        But then I had to deal with the real world, and, I admit it, having them up there at the very beginning of the HTML5 Boilerplate html page did help me understand that there are many instances where really is is no other option but to use them. At the very least if you’re required (by customers, bosses, anyone) to try and make the sites look as similar as possible.

        A very simple example: to deal with inline-block. I couldn’t use inline-block (that I use everywhere) if I couldn’t use conditional comments. (Actually I *could* use a css hack, but that’s even worse in my opinion).

        And of course, even though they are browser sniffing, they don’t have one of browser sniffing’s biggest practical problems: it’s unreliable. Conditional comments are reliable (yes, even with IE10 not supporting them).

        And they’re not an unruly mess, it’s just copy and paste. The same you have at the very beginning of every site you make with the HTML5 Boilerplate. And you can’t get it wrong, because the site just wouldn’t work, you’d realize in a second. (And we already copy and paste the jQuery script include every time, a line more doesn’t make any difference.)

        Differences in APIs might really be a problem, though, you’re right! I’m not 100% certain they’re identical. But again, I see no problems in trying both for the time being, since I’m testing everything in every browser anyway. The first time I’ll find a problem, I’ll drop it system in a second.

  • Kenny Landes

    I’ll use this on new projects that don’t require IE8 support. I think this will accelerate the die-off of IE8, so I welcome it, but it is uncertain how quickly it will die. Who still supports IE 6/7? I haven’t in two years, though for the most part IE7 did most of what IE8 can do, except for some AJAX issues.

    • I’m not wholly convinced a JavaScript library will accelerate IE8’s demise when (a) there’s a compatible version available, and (b) people rarely run IE8 because they want to. Time will tell but one thing’s for certain: if you don’t need to support old IEs, you may not need jQuery.

      • I believe 5 percent or maybe less amount of developer will use jQuery 2.0, IE8 support is more important than 3.6kb and there is nothing so new in 2.0, so it was not necessary to stop supporting IE8 so soon, IMO.

  • I think that, as John Resig tweeted, the main point here is context. So, for example, PhoneGap apps will surely switch to jQuery 2 since they don’t need to support IE6-9, while most of the websites will still use 1.X branch.

  • I don’t know why the new version won’t support IE versions. Its too bad. Please Microsoft make your browser like other ones. I think we are pushing away Microsoft’s internet explorer.

    • IE10 is as good — if not better — than Chrome and Firefox for core HTML5 and CSS3 technologies. IE9 was missing a few features but won’t cause problems.

      The main issue is that many people are still on XP and can’t upgrade beyond IE8. Fortunately, IE8 usage is dropping reasonably quickly.

  • I think there is no need to use conditional loading of 2.0 if someone still now needs IE8 support and yes it’s true only a JavaScript library can’t accelerate IE8′s demise but I think it’s really too early to stop supporting IE8 only for saving 3.6Kb but a lots of people are still now using IE8 because it’s the default browser in their OS and most of them are not geek.

    • I totally agree. At this moment, conditional loading offers no real benefit and may cause further complications. Within a year or so I’d hope you can drop IE8 support and switch to jQuery 2.0 full-time.

  • Thanks Craig Buckler for excellent post

    • You’re welcome Peeter — thanks for the feedback.

  • For those who need on online jQuery builder this has just been released.

  • Robert

    It looks like even Microsoft with all its muscle and money can’t persuade the Die Hards to upgrade their jurassic browsers (and rid off it’s ugly history) :

    For the past 6 months I saved my server logs offline (3 servers, 2 portfolio and many personal sites). And ran some sed + awk + grep queries on them to check UA strings, I concluded that there were just a handful IE7 and IE8 visits (nothing below) with unique IPs. 7 to 22 total IE7+IE8 unique visits per month across all sites. The site with the worst unique visitors per month count, has 331 unique visits per month. These (IE7+IE8 visits) were also consistently ranked as the visitors with the lowest page views and shortest visit duration.

    So I’m embracing jQuery 2.0. I also took the “bold” step to ditch the html5shiv in Modernizr.
    Also, no JavaScript, equals no site :
    In index.php and load the real site index page with JavaScript and a message.
    On each site page :
    in html : <html class=”no-js”></html>
    in css : .no-js {display: none; visibility: hidden;}

    jQuery 2.0 is **THE** chance to make the dinosaurs feel the pain.
    Sticking to jQuery 1.9.x will **eventually** be like making the same mistake again as we did before : supporting unsupported stuff (IE8-). Adding one more legacy liability on top of the IE8- liability pile.

    What will be next? A jQuery2.0shiv for jQuery 1.9 on Github/Bitbucket?

    According to Wikipedia, IE6 was introduced in August 2001, IE7 in October 2006, IE8 in March 2009, IE9 in March 2011. Djeez! We might as well go for it and support IE1 (Windows 95, remember). That’s only 6 years more back in time than IE6 (which in itself is almost 12 years back in time).
    If we are willing to support 12 years old, why not go for the whole legacy?
    Of the other browsers which you support, how old are they?

    Even their maker, Microsoft, stopped supporting the oldest versions, years ago.
    So why are **you** still supporting them?
    For just another year ? :

    The users of these ancient browsers can still visit sites like the Wayback Machine to enjoy the Jurassic internet and stay in the past forever.

    And be fair, or honest, to yourself : the majority of boxes still running XP with IE8-, won’t be able to provide the horse power to run a modern site smoothly anyway.
    2 tabs, each with one video, will at least choke, and possibly kill, that PIII/PIV/Athlon running IE8-.
    Even an AMD E-350 with 2-4GB RAM, Win7 and IE9+ will have more power and not choke.

    Don’t deserve a webpage like this :

    Let’s break those old browsers.

    One time a client for an e-commerce site, specifically asked me to block anything older than IE8. His company had decided that people not able/willing to upgrade would also have nothing to spend.

    • Sean

      It seems like spite is your main motivation for not supporting old browsers. You do understand that there are reasons for people being unable/unwilling to upgrade to modern browsers apart from just mom and pop not knowing any better right?

    • The assumption that ‘poor’ customers use IE6/7 is flawed. In my experience, it’s the largest and most affluent companies and government departments using those browsers. They’ve not upgrading because they have tens — if not hundreds — of thousands of users with locked-down PCs. Upgrading IE overnight is simply not an option, especially when they have legacy applications to test or fix.

      The fact is: you can do whatever you like. If you just want to support 60% rather than 98% of browsers, then go for it. However, you can’t complain when 40% of your customers migrate to competitors.

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