jQuery 2.0 Released

Posted on by

You asked for it, you got it: jQuery 2.0 has arrived!

As promised, this version leaves behind the older Internet Explorer 6, 7, and 8 browsers. In return it is smaller, faster, and can be used in JavaScript environments where the code needed for old-IE compatibility often causes problems of its own. But don’t worry, the jQuery team still supports the 1.x branch which does run on IE 6/7/8. You can (and should) continue to use jQuery 1.9 (and the upcoming 1.10) on web sites that need to accommodate older browsers.

Where to Get It

The final jQuery 2.0.0 files can be found here on the jQuery CDN:

The files should also be available on the Google and Microsoft CDNs soon, but please give these folks a few days before releasing a storm of impatient tweets. Also remember that production web sites should be requesting a specific version from any CDN; using a non-specific version like /2/ or jquery-latest.js is considered harmful to your web site’s health and performance.

If you’re upgrading from a version before 1.9, we recommend that you use the jQuery Migrate plugin and read the jQuery 1.9 Upgrade Guide, since there have been a lot of changes. It’s easy to use the plugin, just include it in your HTML file after jQuery and open your browser console to see the messages it generates:

<script src="http://code.jquery.com/jquery-2.0.0.js"></script>
<script src="http://code.jquery.com/jquery-migrate-1.1.1.js"></script>

How to Use It

jQuery 2.0 is intended for the modern web; we’ve got jQuery 1.x to handle older browsers and fully expect to support it for several more years. If you want, you can serve 2.0 to newer browsers and 1.9 to older ones using our conditional comment trick, but that is not required. The simplest way to support older browsers is to use jQuery 1.x on your site, since it works for all browsers.

With the release of jQuery 2.0, there are a few environments where the jQuery team will no longer support use of the 1.x line because 2.x is a far better choice. These are typically non-web-site scenarios where support for older IE isn’t relevant. They include:

  • Google Chrome add-ons
  • Mozilla XUL apps and Firefox extensions
  • Firefox OS apps
  • Chrome OS apps
  • Windows 8 Store (“Modern/Metro UI”) apps
  • BlackBerry 10 WebWorks apps
  • PhoneGap/Cordova apps
  • Apple UIWebView class
  • Microsoft WebBrowser control
  • node.js (combined with jsdom or similar)

Many of these environments are themselves a work in progress, and have unique sets of rules or restrictions that are different from the ones typically found when jQuery is used for browsers on Internet web sites. Although we aren’t able to test regularly in all of these non-browser scenarios, we’d like to hear about your experiences in using jQuery with them. Even better, we’d love for the communities supporting these environments to pool and share their knowledge about how to use jQuery 2.0 there.

How 2.0 Changed

Here are some highlights of the changes that jQuery 2.0 brings:

No more support for IE 6/7/8: Remember that this can also affect IE9 and even IE10 if they are used in their “Compatibility View” modes that emulate older versions. To prevent these newer IE versions from slipping back into prehistoric modes, we suggest you always use an X-UA-Compatible tag or HTTP header. If you can use the HTTP header it is slightly better for performance because it avoids a potential browser parser restart.

Reduced size: The final 2.0.0 file is 12 percent smaller than the 1.9.1 file, thanks to the elimination of patches that were only needed for IE 6, 7, and 8. We had hoped to remove even more code and increase performance, but older Android/WebKit 2.x browsers are now the weakest link. We’re carefully watching Android 2.x market share to determine when we can cross it off the support list, and don’t expect it to take very long.

Custom builds for even smaller files: This feature has been greatly refined and extended since its debut in jQuery 1.8. You can now exclude combinations of 12 different modules to create a custom version that is even smaller. A new minimal selector engine, basically a thin wrapper around the browser’s querySelectorAll API, lets you shrink the build to less than 10KB when minified and gzipped. See the README for instructions on how to create a custom build, and remember that any plugins you use will also need to stick to the subset you select.

jQuery 1.9 API equivalence: jQuery 2.0 is API-compatible with 1.9, which means that all of the changes documented in the jQuery 1.9 Upgrade Guide have been applied to jQuery 2.0 as well. If you haven’t yet upgraded to jQuery 1.9, you may want to try that first. Be sure to use the jQuery Migrate plugin.

The full record of changes can be found in the changelog below, and in the list of commits on GitHub.

What’s Next

In keeping with our pledge to minimize API divergence between the 1.x and 2.x branches, we’ll be releasing a jQuery 1.10 within a couple of months that incorporates the bug fixes and differences reported from both the 1.9 and 2.0 beta cycles. In the future, we will be maintaining feature parity between 1.10 and 2.0, 1.11 and 2.1, etc. Patch releases will happen in each branch on their own schedule, based on team resources and severity of any reported bugs.

Please do try this new release with all your web sites and HTML apps. If you find problems, create a minimal test case (preferably using a site like jsFiddle or jsbin) and submit it to our bug tracker. We’re particularly interested in situations where jQuery 1.9.1 behaves differently than jQuery 2.0.0, since that’s something we’ve tried to avoid.

Who Helped

jQuery 2.0 has been 10 months in the making, a product of the jQuery Core team: Julian Aubourg, Corey Frang, Oleg Gaidarenko, Richard Gibson, Michal Golebiowski, Mike Sherov, Rick Waldron, and Timmy Willison. Oleg and Michal joined the team during the 2.0 odyssey; we’re glad to have them aboard.

Many thanks to the other jQuery team and community members who contributed fixes: Steven Benner, Pascal Borreli, Jean Boussier, James Burke, Adam Coulombe, Tom Fuertes, Scott González, Dmitry Gusev, Daniel Herman, Nguyen Phuc Lam, Andrew Plummer, Mark Raddatz, Jonathan Sampson, Renato Oliveira dos Santos, Ryunosuke Sato, Isaac Schlueter, Karl Sieburg, Danil Somsikov, Timo Tijhof, and Li Xudong.

To those of you who tested the betas and reported bugs, we’re especially thankful for your help since it helped to make the release more solid and stable.

How You Can Help

Please, participate! Try the code (especially the betas), file good bug reports with clear test cases, contribute patches. Write or edit documentation. Come to the jQuery Conference Portland in June and mingle with other jQuery-ites. Visit contribute.jquery.org to learn how to get involved with the project.

You can also become a jQuery Foundation member to support our efforts and get some fabulous gifts in the process!

jQuery 2.0.0 Changelog

Ajax

Attributes

Build

Core

Css

Deferred

Effects

Event

Manipulation

Selector

Support

Traversing

Please do not report bugs in the blog comments! Instead, read the blog post for details on how to report bugs.

168 thoughts on “jQuery 2.0 Released

  1. panique on said:

    Awesome! But how long will the 1.x branch be maintained ? As some countries still have up to 30% IE8/7/6 market share (Global 6%-7%, according to W3C) i would love to hear your plannings on this. Thanks for your excellent work, jQuery team!

  2. I have always liked to see charts, percentages and absolute difference in size of file and performance of code in libraries that I use.

    For a long time the release notes of new jQuery versions have removed these kind of information, but I would really appreciate those informations coming back on the notes. And I guess thousands other developers would too.

    I don’t know the exact complexity involved for this task, but I guess that an automated job on grunt could resolve this problem, and it would be great information to have.

    Best regards,

    Daniel

  3. Howdy just wanted to give you a quick heads up. The words in your content seem to be running off the screen in Firefox. I’m not sure if this is a formatting issue or something to do with web browser compatibility but I figured I’d post to let you know. The design look great though! Hope you get the issue fixed soon. Kudos

  4. Martijn on said:

    No IE7/8 Support. EPIC FAIL.

    How the fuck did this get through? It’s not the place of a framework to decide which browsers are in scope and which aren’t. Needless to say, probably almost noone will upgrade to 2.0, if they take themselves seriously as web developers.

    jQuery team, I suggest you look back at this horrible mistake and support IE7/8 sooner rather than later.

  5. jQuery Rocks on said:

    @Martijn: I agree with you that many companies and individuals still need to support IE7/8 – however, people making mobile apps with Phonegap, or Windows 8 apps, or Chrome extensions have no need for IE7/8 support – this is not a lack of options but an expansion of choices for each developer to make.
    If they abandoned 1.x yes, that would be bad – but they won’t.

  6. Works great for my use case – phonegap on android 4.2.2 for corporate applications. Was looking at Zepto (which doesn’t work natively with all my plugins) until I spotted this.
    Thanks guys :)

  7. I use Nuget via Visual Studio, and agree that 2.0 should be considered a different package. When 1.10 comes out (as indicated in this blog post), there will be no way to install it via Nuget, since the 2.0 version will supercede it. If you are not in the intended use-case for 2.0, this is just a PITA, as Nuget will also be constantly nagging to install 2.0 which is a breaking change in browser support.

  8. Jeremiah Bagula on said:

    Hello All,

    I cannot wait to update all projects that are not using any IE support. Love the fact that jQuery is smaller…

  9. @DaveH, it seems unlikely the Android 2.x market share will fall that quickly. On the other hand, I expect it to fall a lot faster than IE6/7 market share, which has taken a decade. I believe there are still (crappy) Android 2.x phones being sold today, but phones generally have a 2-3 year lifespan. We’ll just have to watch it and decide when it makes sense, just like for 1.x support.

  10. Brad Metcalf on said:

    Getting a little tired of reading rants everywhere that people can’t upgrade because they need to support everyone running IE 6,7,8. I got to thinking about it and it is safe to say this group of users is least likely to be technically inclined if they don’t even bother to do an update or switch browsers entirely.

    This is good news as this would indicate they are extremely unlikely to be using a user agent spoofer. So all you have to do is write a PHP, Python, Rails, JS, or whatever script that detects the user agent’s version. If it is IE 6,7, or 8 then have it load 1.9.1 in the header. Anything else 2.0. Took my 2 minutes to do and in this case I doubt it will fail me.

  11. @Brad Metcalf: or you could go for the safer and simpler solution recommended by the jQuery team, using conditional comments.

  12. tward on said:

    @Brad Metcalf: I still need to support IE7 and 8 because the U.S. Government doesn’t move that fast when upgrading…

    I just don’t understand what people are ranting about when 1.9 will still work just fine for IE 6/7/8, it took 5 minutes to make my pages support both 1.9 and 2.0 of jQuery….

  13. Martijn on said:

    @Stifu
    That’s not the problem. Of course there’s 1.9, but the two version WILL go out of sync in terms of their features and bugfixes. It’s just in the nature of maintaining two current versions of a product. Another problem is, mark my words, 1.9 will be frozen at some point, at a time when IE8 support is still neccesary.

    At this point, the jQuery team will state “just use 2.0 for those new features”. And you’re screwed.

    I think it’s not up to a framework to decide when versions of a browser go obsolete. Proven by the existence of 1.9, there’s a huge demand for oldIE support, but hard-headedly calling the deprecatable version 1.9 is just a big in-your-face sign that it will no longer be supported at some arbitrary point in the near future.

    JUST call both versions 2.0, a “normal” version and a “light” version. Then this whole discussion would not exist, because both versions are the latest one.

    CUSTOM BUILD is another perfect apportunity to add in (or leave out) certain features like oldIE support. But noooo, oldIE had to be moved to a dark corner in an “old” version of the framework.

  14. Martijn on said:

    @jQuery Rocks
    I agree, there are apps using jQuery that have to demand for IE7 or IE8 support. Not even IE9 support (hey, jQuery Team, won’t you remove that too please?…)
    But something like this should be solved with CUSTOM BUILDS, not forcing developers to an “old” version of the framework, which *will* at some point no longer be supported.

  15. Martijn on said:

    “or you could go for the safer and simpler solution recommended by the jQuery team, using conditional comments.”

    That’s just falling to your knees and begging hopelessly for problems. Once the 1.9 and 2.0 branche start to go out of sync, and they WILL, you’re in for a treat. If you wanna be futureproof, DO NOT include two version of the same framework, seriously.

  16. Martijn on said:

    “Also remember that production web sites should be requesting a specific version from any CDN; using a non-specific version like /2/ or jquery-latest.js is considered harmful to your web site’s health and performance.”

    Haha, and today I realize why they always emphasize this. Doing this will break your site in IE7 and IE8 ;)
    Just saying :)

  17. Dennis on said:

    Any possibility of a fallback js, which includes IE8 support? There’s no upgrade to IE9 for Win XP.

  18. @Martijn: “I think it’s not up to a framework to decide when versions of a browser go obsolete.”

    It’s totally up to them to decide what they support. They don’t decide or claim something is obsolete, they just decide to stop supporting it (which they haven’t yet, for oldIE). Following your logic, jQuery should support IE<6 or Netscape 4, because they shouldn't dictate which browser we use. Actually, the jQuery team is being very considerate to make everyone happy, and make the transition as smooth as possible. They're both thinking of the future (or should I say present?), and making sure developers for IE6-8 aren't left out just yet.

    Besides, I don't really see what's the big deal with having to use an older jQuery version on your sites that target IE6-8. Most developers wouldn't be able to tell the difference between jQuery 1.4 and 1.9. The main problem would be potential plugin compatibility issues, but even that can be resolved one way or another.

  19. Kamran Shahid on said:

    I understand about the backward compatibility problem wiht older IE versions but it should atleast support IE 8

  20. Why don’t kick off IE6 – IE7 first ?

    IE8 is the latest version of MSIE in Windows XP and still have a lot of market share.

    According to Statcounter, there are 18% market share of IE8, but only <3% market share of IE7 or below.

  21. Update: Market share according to statcounter,
    For Jan 13 – Apr 13,
    10.72% of market share for IE8
    <2% for IE7 or below

  22. They’re not just removing support for IE6-7, but also IE8, for technical reasons. It wouldn’t make much sense / help much to remove support for just IE6-7, as IE8 has similar limitations. That is to say they’d still have to keep most oldIE hacks in place if they wanted to keep IE8 support.

  23. Brad Metcalf on said:

    As I understand it users will still get IE 6-8 support for jQuery through the 1.x branch. All 2.x will be compatible depending on versions. Such as the way 2.0 and 1.9.1 are compatible. The difference is 2.0 does a faster kill off on browsers on there way out or browsers most likely not to be supported for the application being developed anyways. As 1.x progresses I wouldn’t doubt they will start phasing out old browsers. But it will be a more slow kill off, you know when the browsers have very little market share. The comments on other sites are getting pretty crazy because the initial thought is jQuery isn’t giving you an option, when in reality they are giving developers a better option.

    I am still in favor of UA detection over conditional comments in this process at the current state of browser phase outs. Like I mentioned IE users using old versions are very unlikely to be sending an incorrect UA header. If it happens, it is going to be a very rare case. I can’t be so confident this will be bulletproof for future phase outs though. And I am also on the fence about conditional comments and future headaches this could cause. But my preferred method was mentioned with the intentions of pointing out this could be a simplistic way to upgrade, have wide support, and hopefully be a case UA detection is dependable. As far as seeing if a browser is capable of something users should still use feature detection over UA detection.

  24. Brad Metcalf on said:

    Also, I use both methods of UA detection and conditional comments after the UA detect just to be safe. My worries about CC failing me is for future browsers not doing a proper detection if the browser has parsing issues.

  25. Brad Metcalf on said:

    Hate how you can’t do an edit to a comment on here. What I meant by parsing issue is conditional commenting is an IE feature. Non IE browsers ignore them. But in a case they ignore the commenting tags and not the script tags then you will have the possibility of both being attached to the page and causing conflicts.

  26. I recommend future of jquery

    html5 support
    ===canvas Tag====
    event
    -getContext
    -beginPath
    -arc
    -fillStyle
    -fill
    -stroke
    -more
    ===Video Tag====
    event
    -play
    -stop
    -record
    -take photo
    -more
    ===audio Tag====
    event
    -play
    -stop
    -record
    -take photo
    -more
    ==scroll value==
    -scrollheight
    -more
    ================

  27. @Brad Metcalf: so you’re worried some browsers will stop handling HTML comments properly. This basically can’t happen. If such a browser existed, it wouldn’t work with loads of sites, assuming it wouldn’t simply be completely useless. And the browser would have to get fixed very fast if they want to keep users. If you can’t trust a browser to properly handle HTML comments, you can’t trust it to do anything right. You shouldn’t code around such crazy scenarios. Actually, UA detection is much more likely to fail.

  28. jQuery Friend on said:

    It’s really Great that jquery starts to unsupport old and legacy browsers and OSs like IE and Android 2.x.
    Hope other librarys switch to this solution too.

    “The world wide web stops it’s modernity cause of clients running old machines…”

  29. Toni L on said:

    I understand the rant about Internet Explorer, but I’d really recommend that people would start to push people to install the latest Google Chrome, Mozilla Firefox or other modern browser to their users. It should be a priority to support developement. Even banks constantly raise the bar for users browser, just because of the security issues.

    And if you decide to support the ancient browsers, don’t forget to add that on your project estimate. ;)

  30. I’m excited to try this out on my HTML5 powered sites – old IE doesn’t support most of that anyway, why not have a faster and smaller jQuery. Glad it includes IE9 though.

  31. filipvb on said:

    IMHO, It was at least 2 years too early to fork the code; – the marketshare of IE8,7,6 is still too high: http://goo.gl/I898M
    Some 15% code size reduction is not worth for such a big change.

  32. Anand on said:

    Hello Jquery team,

    I am creating a web application using Jquery for some support people. You can understand support teams can work on any browser based on the problem. Can you please suggest me which version is suitable for me. After reading this it confused me more. Please suggest proper version and any link.
    Thanks you for the effort and Help,
    Anand

  33. Ryan Wheale on said:

    While I agree that there are still a large number of people using old IE, this is due in part to the fact that we developers continue to build things which will work in those browsers. If we start to move away from supporting those old browsers, eventually the end user (or IT manager) will get a clue and upgrade to a browser which follows specifications. It is our responsibility to force this change, or else lay folk and hard-headed IT managers will never make the change.

  34. Hi guys,
    I’m trying to use jQuery 2.0.0 in my Windows 8 store app. The app works fine, but I get the following error when I run the app validation kit, which is required in order to publish an app to the store.

    FAILED
    Bytecode generation
    Error Found: The bytecode generation test detected the following errors:
    File \\?\C:\Program Files\WindowsApps\25899MatthewKaufer.TrigonometricTriangleSolver_1.0.0.4_neutral__2hr1s851qz6de\js\jquery-2.0.0.js has JavaScript syntax or other problems.
    Impact if not fixed: As a performance optimization to accelerate JavaScript execution time, JavaScript files ending in the “.js” extension generate bytecode when the app is deployed. This optimization significantly improves start-up and ongoing execution times for JavaScript.
    How to fix: You may need consider one or more of these steps to fix the issue:
    – Ensure that event logging is enabled
    – All JavaScript files are syntactically valid; otherwise exclude the respective files from the package
    – Please note that you should uninstall all previous versions of the app before deploying
    Otherwise exclude the respective files from the package.

    Basically, it doesn’t like the code for some reason or another. Does anyone here have a fix for that?