jQuery Core: Version 1.9 and Beyond
Please check out the followup post before jumping to the wrong conclusion.
As the last blog post discussed, jQuery version 1.8 is undergoing a spring cleaning to remove insecure, inefficient, ineffective, and inadvisable features. We’ve also begun the work to allow you to build custom versions that exclude parts of the library for even greater savings. Those efforts will make it possible for you to enjoy the jQuery API you need without carrying around the parts you don’t want.
Now that we’ve cleaned house, it’s time to take a look forward. There’s just one thing interfering with our vision of the future, and that’s the ghost of browsers past. Internet Explorer 6, 7, and 8–collectively, oldIE–have been a thorn in the side of web developers for a decade. Collectively, these browsers of a bygone era still represent up to one-third of users visiting some sites. That is a lot of users–people who still want the information, services and products that web sites provide. For many web sites that use jQuery, it’s not practical or profitable to ignore that audience.
jQuery was conceived specifically to address the differences in browsers, so we’re not going to abandon the essence of our philosophy and simply disregard the millions of active Internet users who (for whatever reasons) still use oldIE. Yet we also want to move ahead and take advantage of modern browsers, especially the growing mobile market.
The Road Ahead
jQuery 1.8 should arrive within a month. Here is our thinking about the next two versions of jQuery to follow it, and when they’ll arrive:
- jQuery 1.9 (early 2013): We’ll remove many of the interfaces already deprecated in version 1.8; some of them will be available as plugins or alternative APIs supported by the jQuery project. IE 6/7/8 will be supported as today.
- jQuery 1.9.x (ongoing in 2013 and beyond): This version will continue to get fixes for any regressions, new browser bugs, etc.
- jQuery 2.0 (early 2013, not long after 1.9): This version will support the same APIs as jQuery 1.9 does, but removes support for IE 6/7/8 oddities such as borked event model, IE7 “attroperties”, HTML5 shims, etc.
Our goal is for 1.9 and 2.0 to be interchangeable as far as the API set they support. When 2.0 comes out, your decision on which version to choose should be as simple as this: If you need IE 6/7/8 support, choose 1.9; otherwise you can use either 1.9 or 2.0.
Questions and Answers
If jQuery 1.9 and 2.0 are basically the same API, what makes 2.0 compelling? Smaller size, better performance, and the lack of problems introduced by the need for oldIE support. We expect that we can improve error handling in the $.Deferred implementation in 2.0, for example, whereas we can’t do that as long as oldIE is supported.
My site still has many IE7/8 visitors but I want to use jQuery 2.0. Can I do that? If your web site needs oldIE support, and we expect most sites will need it for at least another year or two, you can use IE conditional comments to include version 1.9 only when visitors are using oldIE:
<!--[if lt IE 9]>
<script src="jquery-1.9.0.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
<script src="jquery-2.0.0.js"></script>
<!--<![endif]-->
Why not make an “oldIE plugin” for jQuery 2.0? Special dispensations for oldIE are sprinkled throughout jQuery. Refactoring the code to provide enough hooks so that oldIE support could be added as a plugin would complicate the code for the modern browser case. Plus, developers supporting oldIE and using a public CDN would then need to include two files (jQuery 2.0 and the oldIE plugin) instead of one.
Once jQuery 2.0 is released, what happens to 1.9? In a departure from the past, we’ll continue to fix bugs in 1.9 (as minor releases). Having just gone through a spring cleaning for 1.8 and 1.9, we don’t anticipate adding a lot of new APIs in the future. Instead, we prefer to add new functionality through plugins compatible with both versions where it makes sense. So don’t feel like you’re being left behind when using version 1.9.
Is jQuery 2.0 basically for mobile devices? No. Although jQuery 2.0 will be a great fit for HTML mobile apps, including ones written with jQuery Mobile, it is not a Webkit-only library that targets just iOS and Android. In addition to mobile browsers, 2.0 will support (and be tested!) with modern desktop versions of Internet Explorer, Opera, Firefox, Safari, and Chrome.
How much smaller/faster will jQuery 2.0 be? We won’t know until we’re done, or at least close to being done. You can bet that we’ll tell you more as the release date for 2.0 draws near. Better yet, you can try the beta when it is released and see for yourself!
Good decision to drop support for old IEs. Makes it much easier now to explain to clients why our agency does not support old IEs anymore. Because it’s a waste of time.
PS: I’m looking forward to this snappy new core :)
It seems like the jQuery team is now driving the standards that they worked so hard to get other companies to stop doing.
I understand dropping support for IE6 and even IE7, but why IE8? IE8 is still 10% of the browser market and doesn’t require half as many hacks as IE6 and IE7. Dropping IE8 is premature, IMO.
This is a good thing. I’ve already completely dropped support for 6 and 7, and I spend very little time messing with 8. I just make sure the site functions and mostly looks right and call it good. By next year IE8 usage will drop even further. But even if IE8 usage were still high, it wouldn’t matter one bit. Those of you saying that you cannot use jQuery 2.0 because you have a large IE8 user base are doing it wrong. You should not be developing a website that requires ANY javascript of any kind whatsoever. Build with progressive enhancement in mind. IE6-8 users should still see a site that is fully functional with javascript disabled. Those with modern browsers will get the nice fancy site with all the wizbang features. I build all of my sites with zero javascript, then I will add in extra stuff using jQuery if I feel the need. That’s the way it should be IMO.
Great news!!! Adios IE6!!!
Thanks for having the balls to drop support for crappy browsers. And even so, you’ll still support them for a while longer through 1.9, so even developers that still live in year 2000 are not actually left behind.
@TedWood:
1) IE8’s codebase may have a lot of similarity with IE6/7, but it had many fewer bugs and many more features. The vast majority of special cases to deal with IE6/7/8 only apply to IE6, and most of the rest to IE7. IE8 is actually pretty good in comparison. Supporting it without needing to support IE6/7 is actually a pretty benign concept.
2) I’m not looking for new “features” to be added; what I’m looking for is continued support for IE8 – ie that I can use jQuery and know that if a problem is found it will be fixed and I’ll be able to use that fix. And I’m not looking at the 1.9/2.0 transitional period; I’m looking beyond that, to when 2.1 is released. Unless they plan to keep supporting 1.9 beyond that point, it will be a big problem for a lot of people.
3) I am looking at current browser stats, and yes, you’re right: IE8 is on the decline. It is not, however, anywhere close to being small enough to drop support for yet, and is unlikely to get there for a few more years yet.
@Andrew
I cracked open my Analytics. IE(total) makes up about 12% of users on most sites I develop.
So essentially, it can take a running jump…
” If you rely on jQuery to solve browser quirks, then either you are working on some edge-case projects, or I should advise you use other methods to tackle these problems.”
Really? That seems odd since one of the three primary selling points on jquery.com is “cross browser.” The other two are “lightweight footprint” (ok…) and “css3 comliant.”
Come on. Eliminating cross-browser problems is THE WHOLE REASON that most people started using jQuery. Do I need jQuery to wrap “querySelectorAll” in “$” for me? I think I could handle that code myself, if you only care about browsers that have a selection engine built in. If every browser returned the same value for “innerWidth” then why would I need jQuery’s methods?
The value of jQuery isn’t just a bunch of methods for moving nodes around, or a bunch of utility methods that are easily available in other libraries. That’s nice, but it only matters if we can be assured it works everywhere. That’s the whole point.
I think much of this argument is semantics and speculation. A suggestion that may help and doesn’t deviate much for your current plans would be to just change the naming conventions and packaging of the versions. You have already talked about the ability to do a “Roll your Own” version of jQuery that only includes the parts you need. Don’t do a version 1.9 and 2.0, just give people the ability to include the compatability layers or not. Why have the confusion of two different versions when they have effectively the same API.
I think it would be far simpler to just use the same version numbers, but add a letter designator saying it is Old IE Compatable, Version 1.9 or 1.9c. When you are packaging your own jQuery setup you could also select regular or c components for the package.
Maybe I am wrong, but I think this would reduce the confusion and uncertianty about the versions, plus help maintain a focus on OldIE compatable components.
Personally I can’t wait for old IE to die and I am even considering putting links to upgrade users of old IE right on my pages. Hopefully with a little polite nudging we can get more of our users off IE6/7/8. I don’t care what browser they use, just not those.
Let me stick my .02 in here too. I love jQuery! But what would REALLY be cool would be just a tiny stub that can do basic Ajax and detect if some part of jQuery is referenced in code and then lazy load it. That way, you REALLY only get the parts you need and they stay in the browser cache too. Plus, you’d always have the option to regular load the parts you want, or to utilize any plugin you wanted just by referencing it.
As has been mentioned, the reason JS libraries came into existence in the first place was cross-browser quirks. So someone just needs to write a jQueryQuery metalibrary that handles the conditional comment for you, so you don’t have to. One script tag, same as it always was, and it injects the right version of jQuery based on the browser. ;)
It will be interesting if/when other libraries follow suit, since the difference will then be about what features the libraries actually provide. That’s always been a difference, but it’s never mattered as much as how well and how efficiently they deal with browser quirks.
Disclaimer: My corporate clients are mostly IE. IE7/8 and some 9. I have to ensure 100% compatibility on every site with those 3 browsers.
I can’t understand those talking about completely dropping jQuery _now_ because jQuery 2.0, which won’t be out for at least another year, will be dropping support for it.
What exactly are you developing that you must upgrade the version of jQuery the moment every new release comes out? I would assume nothing with any significant amounts of jQuery code.
After QA testing a site and launching, we generally ‘freeze’ a site, as updating jQuery versions can introduce bugs. We have sites that are running perfectly happily on jQuery 1.4+. If you’ll note, jQuery UI even supports jQuery 1.3.x.
I will most likely be using jQuery 1.9 without the conditional when it comes out. I don’t believe there will start to be majorly compelling needs to switch to 2.0 for quite a few years. In which time, worst case scenario, use the conditional.
VICTOLY
KILL OLDIE SUPPORT AND DON’T BACK DOWN
Finally, I have been doing web design for 10+ years now (believe it or not) and this should be a pretty large nail in that complete POS’s coffin.
And to all the “I still support IE6 cause my great grandmother still uses it”, you have NO place in this profession, leave now.
We dropped support for IE6 a year ago. We dropped support for IE7 on 50% of our sites 6 months ago. We will completely drop support for IE7 within the month. IE8? That will be a while still, and it times perfectly with the jQuery team. If 1.9 comes out next year, we will use the conditional to select the appropriate library. So long as 1.9 gets supported and in sync with 2.0 for will likely be a year, then that’s works for us.
If it gets dropped sooner than that, or if 1.9/2.0 become out of sync then we will have to freeze jQuery at that point.
Good.
It will cause some work and difficulties, but not much in comparison to the work and difficulties that IE has caused over the past 10 years.
Shame though, if a third of the world’s websites became inaccessible to IE users overnight MS would probably release the real fixes for the IE problems within a week or two.
As it is they will continue to drag their feet all the way to 2022, doing just enough to avoid prosecution, and not enough to give the world the impression that standards can be set without either full MS approval, or a 20 year uphill struggle costing millions of man hours.
However it may look today, it’s probably a win win for MS in the grander scheme of things.
If you drop support of IE8 you will lost all the enterprise world that have still XP desktop. As a consequence most development will stick for years to come on 1.x.
IMHO, you should support at least IE8 until XP EOD and drop it then.
What about all levels of government websites that use jQuery? Government departments are typically stuck on older versions of browsers for much, much longer than is usual. You could argue that it doesn’t matter since users and the general public are unlikely to have the same restriction — but that’s assuming that you don’t have a public office/services on a website that need to be demonstrated in that public office.
Libraries (part of local government), for example, with public computers on older browsers, will probably have to use an older version of jQuery if they use it on their websites (so that it works with those public computers).
What about China, where 35% of the people there are still using IE6?
Conditional comments will not exist in IE10, so the proposed solution in the post won’t work as IE10 won’t load the jQuery file.
I greatly support this movement. By supporting old and very outdated browsers, you are allow you to stay in the past. By dropping the support in 2.0, we can finally move forward and optimize for current and up to date technology.
Backwards compatibility makes sense, but only till a certain degree. In time, we have to move forward in order to stay competitive. That moment in time has come and gone for the over ten year old Internet Explorer 6 and I refuse to make Internet Explorer 7 compatible as well. With IE8 getting obsolete in 2015(XP support officially dropped), the time to soley move forward with 2.0 has come.
Keep up the good work!
Dropping old IEs is going to make enough sense by 2013. People using those old browsers are probably not really anyone’s target audience anyway. IMO IE6/7 are already dead. IE8 will linger until XP is obsolete (b/c it’s the highest the XP can be updated to). But the people using IE8 are either brainless, corporate drones, or devs doing testing ;]
My only concern with this is that a number of our sites are used by Western Europe’s largest employer (with well over 1 million employees!) who still use IE6 as that is the web browser on which all their core web-applications were developed for – and they are not compatible with other version of IE or other web-browsers…
@James: Well thats the sad fact… I just dont understand how companies can be so damned backward. But its the IT-departments, many of thoose people are for some reason afraid of changes, luckily our customers IT-department have realised that updates wont kill you.
I would think that dropping IE7 and down would be wise but IE8 should perhaps stay on supported for a while more. Cause even though statistics say that older IE is getting used less and less. Most of the Firefox and Chrome users are private persons, the big mass of customers for IT-companies are in businesses where they for the most part use IE.