By Craig Buckler

jQuery 2.0 Drops Support for IE6, 7 and 8

By Craig Buckler

In a surprise announcement on the jQuery blog the team has decided that jQuery 1.9 will be the last edition to support legacy editions of Internet Explorer. jQuery 2.0 — planned for release in 2013 — will no longer support IE6, 7 and 8.

In essence, jQuery 2.0 will be a leaner, faster library without old IE bloat such as DOM selection routines, different event models and HTML5 shims. jQuery 1.9 will continue to be developed and support the older IEs. The team advise that you’ll be able to support every browser using conditional comments, e.g.

<!--[if lt IE 9]>
    <script src="jquery-1.9.0.js"></script>
<!--[if gte IE 9]><!-->
    <script src="jquery-2.0.0.js"><</script>

No one expects old editions of IE to be supported forever and some will applaud the decision to abandon browsers which have caused development grief for many years. But the statement is surprising for several reasons.


First, while IE6 and 7 usage has fallen to below 2%, they remain the browsers of choice for many large corporations, government departments and the Chinese. IE8 is likely to fall below 10% by 2013 but it’s the latest edition available to those on Windows XP. Almost one in three people use the OS and, while it’s dying, it’s lingering far longer than Microsoft anticipated.

[The following section has been revised. Thanks to everyone who pointed out the error in the original code.]

Second, conditional comments. Really? We’re still resorting to browser detection in 2013? That practice should have died out in 1999. Conditional comments were a temporary hack and have been dropped in IE10. JavaScript or server-side browser sniffing is no better.

It also introduces the problem of having two forked code bases for the same library. Inevitably, there will be bugs and differences between 1.9 and 2.0 — especially as jQuery evolves beyond those editions. What do you do when your code works in one but not the other?

Third: the primary reason developers use jQuery is to circumvent browser compatibility issues. The original purpose of jQuery, Prototype, Mootools, YUI and similar libraries was to provide a consistent set of objects and methods which abstracted the differing browser APIs. Wrappers are placed around features such as DOM selection and event delegation to smooth out implementation wrinkles.

Today, the differences between modern browsers is negligible. Consider the DOM querySelectorAll(CSS selector) method; it’s supported everywhere (even in IE8) and will always be faster than jQuery’s $(CSS selector). Core JavaScript features such as traversal, manipulation, events and Ajax are usable everywhere. jQuery’s animations and effects can also be replaced by CSS3. jQuery 2.0 will still provide useful utilities and compatibility fixes but, without legacy IE support, there’s less reason to use it.

Fourth is the confusion the update will cause. Currently, developers can usually migrate to the latest version without breaking their scripts. It doesn’t matter how much publicity jQuery 2.0 receives, many people will think it’s “better” than version 1.9. They’ll upgrade then complain bitterly when their site fails in IE7.

Finally, if jQuery 1.9 works on all browsers, why bother with jQuery 2.0 which doesn’t? It might run a little faster but will that difference be noticeable? The library is already efficient and uses native APIs when they’re available.

I can understand the motivation behind this decision but 2013 feels a little premature. jQuery became popular because of its support for legacy browsers; the team shouldn’t abandon that policy too hastily.

  • cpradio

    Wouldn’t it be ideal for jQuery 2.0 to load the APIs available for the browsers they support, and for unsupported to download and load a second script file that contains the necessary APIs to support the older ones? This way, most experiences will be leaner/faster, but those using legacy will have to download a second script to for the site to work?

    • Possibly, but you’d then need browser/object detection followed by script loading. It’d probably be slower than simply loading one larger library.

    • Peter

      Because then you would need THREE scripts (one extra to do the detection for supported features) and all browsers need to load two of them. Using conditional comments does not require any additional scripts, and is therefor executed faster. It only requires a few more lines of code in the webpage.

      • Unfortunately, if this experience is anything to go by, that few extra lines is very easy to get wrong and difficult to read!

  • Peter

    What do you mean “Conditional comments won’t work”??? The way you wrote them, they won’t work. But if you copy them correctly, they will work perfectly fine. It’s irrelevant they won’t be supported by IE10, because the 1.9 script is not targeted for IE10! They are not supported by any other browser either, which is also irrelevant because they will be loading the 2.0 version. I think you need to read up a bit more on conditional comments… :-)

    • Am I missing something here?

      The first code snippet (provided in the jQuery blog) will fail to load jQuery in non-IE browsers and IE10.

      The second code snippet (mine) will load jQuery 1.9 *AND* 2.0 in IE6, 7 and 8.

      • Lucas Rolff


        The one above works just fine..

      • Lucas Rolff

        Ok, something is not sanitized here lol.. Anyways, using the if !IE works fine in modern browsers.

      • Sorry, I did post a comment about this, but I got the corrected script from their blog now (what you wrote in the post is incorrect and missing some code)…



      • Yes, you’re missing something. Your first snippet pasted here is not the same as that on the original jQuery announcement. In particular, the closing of the comment on line 4, which makes the reference to 2.0 available to all non oldIE browsers.

      • TrubiT

        In original there is . You have it diffrent, so your code wont work as they say :)

      • Peter

        In the original code on the jQuery blog, line number 4 will be read will be read differently depending on support for CC:

        – Browsers that support CC will execute line 5 only when “if gte IE 9” is true.
        – Browsers that don’t support CC will see the whole of line 4 as a standard comment (because of the “” at the end, the bit you left out), and therefor will execute line 5.

        In other words; the code works for non-IE browsers and IE10.

      • Peter

        I’ll try again — the important part that you left out and that breaks support for non-CC browsers, is the code “<!–>” on line 4.

    • Joel

      I tend agree with Craig on this. What do you mean? It seems to me his solution would work to include the dreaded old IE versions and would allow new browsers to use a leaner jQuery.

      The release of v2 will cause some issues for the sites out there using “jquery-latest.js” though. It will break all of the sites being viewed with older IE versions when jQuery 2 is released.

  • Ike

    I guess the line is being drawn in the sand!

  • Tom

    Conditional Comments WILL work:


  • Interesting announcement. I think it’s a good thing, and smart developers should know how to handle it.

    And, Craig, you say in the article that “conditional comments won’t work” for this, but that’s not true. It looks to me that the jQuery blog post has now updated the code, which is slightly different from yours presented here (not to mention that both versions have a stray angle bracket). Here’s how you can ensure that you’re not serving an unnecessary file to any one browser:

    <!--[if lt IE 9]>
    <script src="jquery-1.9.0.js"></script>
    <!--[if gte IE 9]><!-->
    <script src="jquery-2.0.0.js"></script>

    Notice the extra code wrapping the “gte IE9” script’s conditional tags. That means that the script will load in all non-IE browsers and IE9+, but it will not load for IE6-8. IE10 should just ignore the conditional and load the script just like FF would. If you want to make it more readable, you could also do this:

    <!--[if lt IE 9]>
    <script src="jquery-1.9.0.js"></script>
    <!--[if (gte IE 9) | (!IE)]><!-->
    <script src="jquery-2.0.0.js"></script>

    Notice I’ve added the “!IE” clause. This isn’t really needed; Non-IE browsers don’t understand those anyhow, but it could help improve code readability, so it’s clear that the 2nd script is seen by non-IE browsers.

    I don’t think there are any flaws in what I’ve said here, but please correct me if I’m wrong. And I hope the code shows up correctly. :)

    • Thanks Louis. I have updated the article now, although who knows if I’ve got all those symbols in exactly the right place!

  • Francesco

    Uhm… I think that conditional comments will work for IE10 just as much as they “work” for Firefox and Chrome and everybody else but IE. Something like:


    Won’t they?

  • Todd

    I can see maybe 6 but 7 and 8 no way. Poor decision…

  • It’s harsh that they would drop IE8 support, but I fully understand why and it’s the right move.

    But to solve the conditional statement issue…


    That will only load 1.9 if less than 9, but all other browsers will load (though that script could be optimised).

  • Stephen Marx

    I don’t know how this will end up looking seeing as I’m trying to post HTML, but I imagine something like this would work without requiring any unnecessary downloading.

    if (!jQuery) {
    var js = document.createElement(‘script’);
    js.src = ‘jquery2.0.0.js’;
    var first = document.getElementsByTagName(‘script’)[0];
    first.parentNode.insertBefore(js, first);

  • Conditional comments will work just fine; use an else, the same way you would to support any browser except IE 9 and earlier.

  • Stephen Marx

    Hi Craig. Your comment system didn’t escape the HTML in my comments correctly, so I’ve created a paste of the code here:

    As far as I can tell that’ll only download one version of jQuery for all browsers and avoid unnecessary downloads of the wrong version.

    • That looks as though it’ll work but it’s a shame we need a JavaScript fix.

      • Craig, I’ve posted a comment here that hasn’t gone through yet. You definitely do not need JS for this. You can do it with CC’s alone. If you can fish my comment out of the spam filter and/or approve it, you’ll see my solution which ensures that no browser downloads a script unnecessarily.

  • PBrienesse

    I agree this seems a little premature. I disagree about peoples rush to upgrade to 2.0 only to find out it breaks. I have noticed alot of semi-developer types which I think make up the majority of the smaller sites on the web are still using 1.4 or whatever comes with the particular jquery plugin they are using (some sort of cycle, validate etc.). The don’t really use it for much else other than particular plugins. These are also generally the sites that get built and then seem to be neglected and never updated other than text content. I think the large site dev’s are probably educated enough to notice this difference and choose the appropriate course. For me I will just keep using the latest 1.x version. It’s IE8 that is the deal breaker for me. I have recently stopped bothering to really check much on IE7 and haven’t supported IE6 for some time but IE8 is still a large part of the market.

  • I think it is a good thing – in the same way that governments announced a cut point for leaded petrol to force people to upgrade either their cars or engines to use unleaded.

    Without the cut off point there is no leverage. I can now talk to my clients about not supporting IE8 and the benefits that will bring. Google prefers sites that download quicker – and without all the IE6/7/8 bloat things will certainly speed up.

    The argument that some developers won’t realise that earlier version of IE won’t be supported is as spurious as arguing that some people don’t know that drinking and driving is illegal. Any serious developer worthy of being paid will know exactly what jQuery can and can’t do.

    • Your metaphors aren’t quite accurate. This is like Governments stopping the supply of leaded petrol so your car won’t run any more.

      And the drink driving comparison is hardly the same! jQuery v2.0 is not an upgrade — it’s a different library. Not everyone will realise or understand that, even if you do.

      • Peter

        Craig, please! Apart from dropping support for IE6-8, the changes in jQuery 2.0 are minimal. To quote from the jQuery Conference 2012 keynote (

        – Same API as jQuery 1.9
        – No major feature additions

        Saying that jQuery 2.0 “[is] a different library” is very misinformed. I wonder where you got your information from.

        But I do agree with your remark (in another reaction) that if there are bugs in compatibility between 1.9 and 2.0 that we have to program around it. Though I think that proper unit testing will make this incompatibility very unlikely.

      • How can two different code bases not be a different library? The methods may be the same, but the internal code won’t be. Even then, how long will it last? Will v1.9 evolve at the same pace as v2.0? I doubt it.

        Do you really believe “proper” unit testing will make incompatibilities unlikely? Compatibility issues occur now — how much better will it be when there’s two sets of code to manage? I’m willing to bet hard cash that problems will be encountered within days, if not hours, of release … what odds are you offering?!

  • jv

    I can buy not supporting 6 and 7 (people have a choice there)… but not IE8? That’s a bad decision…

  • Matt Van Andel

    I don’t think it’s premature at all. Developers are already relying more and more on HTML5 and CSS3 – and mobile devices now make up more than half of all web traffic. Keeping jQuery small and speedy is extremely important in our new mobile-centric world.

    And frankly, most developers already prompt for ChromeFrame on IE8 or lower, so I would just imagine that best practice will pick up even more steam. People need to start moving away from that ancient software (and I mean both Windows XP and IE <= 8) and getting with the times.

    Windows 8 will be just $40 to upgrade. So if you or your company is still running on decade-old obsolete software, now is the time to upgrade.

    • jQuery minimized and gzipped is around 30Kb. How much smaller can it get? Even a 50% reduction wouldn’t make a radical difference.

      Yes, people should upgrade but the practicalities are not as simple as you make out. Consider large companies or government departments with 100,000 staff; Windows 8 will cost $4 million and take considerable time to upgrade. And that’s before you consider the testing and upgrading of internal apps which aren’t compatible with anything but IE6 or 7.

      But, if you’re happy to have more expensive goods or a higher tax bill, I’m sure these organizations will accommodate you!

  • Jim

    Why not use a downlevel-revealed conditional comment (as explained at to load jQuery 2 for IE9 and other browsers, and a standard conditional comment to load 1.9 for older versions of IE? No javascript necessary.

    • Peter

      That is exactly what the original jQuery blog post is suggesting. Note that the conditional comment that is used in *this* article is faulty and won’t work properly. (Also, it’s perfectly valid to use JavaScript to conditionally load jQuery, since that is a JavaScript component to start with…)

    • That’s possibly the case although IE10 would need to be tested. The syntax would be:

      <!--[if lt IE 9]>
      	<script src="jquery-1.9.0.js"></script>
      <!--[if IE 9]>
      	<script src="jquery-2.0.0.js"></script>
      <!--[if !IE]>-->
      	<script src="jquery-2.0.0.js"></script>

      It’s ugly and invalid HTML but it should work.

      The other issue is maintenance; you now need to ensure two libraries work consistently. I bet there will be issues especially if, for example, you had the latest 2.x but not the latest 1.9.x.

      • Peter

        Craig, please read up on conditional comments. The code as it is published in the jQuery blog will work on both older and newer IE version, and on browsers that don’t support conditional comments (that is, all non-IE browsers). The blog post is using a modified version of the downlevel-revealed conditional comment ( (Note that the name is misleading if you consider non-IE browsers to be superior, since Microsoft calls them downlevel…)

        The only “real” problem is IE4 and below. They will try to load the 2.0 jQuery library (since they don’t support conditional comments), but I don’t think IE4 has ever been supported by jQuery.

      • Francesco

        You don’t need to do that, the syntax used in the jQuery blog (without the typo introduced here) does exactly what’s needed, without being ugly.

        It doesn’t seem to be invalid either.

      • I’m not sure whether the original blog’s code has been changed or there was a problem copying it here, but I agree — it looks as though it should work. Although IE10’s still an unknown quantity at this stage.

        Let’s face it, though, it’s ugly code and prone to error. I’ll be tempted to stick with jQuery 1.9 until IE8 is dead — it’ll work in all browsers, won’t require CCs and won’t cause compatibility issues with differences in v2.

      • Francesco

        It’s the same code we’ve been using forever for these things. It’s right there around in the html tag in the HTML5 boilerplate, if that broke, hundreds of thousands of sites would break. :-)

        Why would IE10 behave differently than all the other browsers that don’t support conditional comments? They see them as normal comments, it can’t go wrong.

        Personally I believe it’s a brilliant solution to *keep* supporting old IEs.

      • Brilliant solution? I’m less sure. Let’s say there’s a subtle difference between a method in 1.9.x and 2.x — whether that’s intentional or a bug. You’re now testing against two different libraries; one may work and one may fail. Testing is more difficult and fixing it could end up with horrible solutions such as:

        if (jQuery.version > 2) $.methodX(c, b, a);
        else $.methodY(a, b, c);

        And don’t get me started on conditional comments. Even Microsoft want to kill a “solution” which, at it’s heart, is browser detection. Yet in 2013, jQuery is forcing us into using it again.

        There’s a lot of benefits to sticking with jQuery 1.9 until IE8 is dead. In fact, once IE8 is dead, jQuery is likely to become an unnecessary overhead.

      • Peter

        Chris, I seriously doubt the jQuery blog has been changed after you wrote your article. I read it within half an hour after you published it, and I already then the jQuery blog contained the correct code. I see that you haven’t updated your article yet for the proper code.

        I don’t know why you call IE10 an unknown quantity. Either it won’t support CC and behave just like every other non-IE browser (and load the 2.0 script), or it will support CC and react to the “if gte IE 9” (and again load the 2.0 script). That’s the same outcome.

        Whether CCs are ugly code is quite personal I think, but I believe your negative opinion is mostly based on you not completely understanding CCs.

        Also, please note that you are not forced to use CCs! The CC-code on the jQuery blog is just one possible solution, you could also use JavaScript, server-side handling, or just sticking to 1.9. Sticking with 1.9 will mean bigger downloads and code evaluations for your users with modern browsers, though the differences are small.

      • The code has now been updated and the article has been revised (note that it was written on Saturday; I’m not sure where the error originated, but it hardly matters). Apologies for the delay.

        Conditional comments == browser sniffing. So is any JavaScript or server-side solution. If you lived through the dark days of web development in the late 90’s you’d understand why I loathe it!

        Sticking with 1.9 means every browser works and you have an API which is guaranteed to be consistent! Besides, how much smaller and efficient is v2.0 going to be? Let’s assume it’s half the size — you’ll save a whopping 15Kb the first time your browser caches the file.

  • I’m a developer that has recently started a job with our provincial (think state) government.Previously I worked for private industry and we had free reign to install any browser of our choosing. That is definitely not the case now. Our standard workstation base is IE7 and windows XP. We can’t install any programs or make changes to our workstations. In addition most of the projects we work on are for internal purposes. Intranets is one but we also deliver many elearning programs via the internet to our large workforce all on legacy browsers.

    The only way we can leverage many of the newer techniques such as responsive web and dom manipulation is by using jQuery and things like modernizer. While there has been some talk about moving to IE9 and Windows 7 the wheels of change in large organizations move slowly. IT departments have to run their due diligence and make sure every security flaw is considered before upgrading.

    This situation isn’t unique and it happens in every large company or government organization. Be it at the state, national or global level (if it’s a multinational company). Many of the deisngers / developers responding to this news appear to be free of the restrictions I describe, so when I read “so what people should just upgrade” I think the proper perspective is lacking. This news may not affect you at your workstation, but it does affect a business or organization you work with I guarantee.

    And don’t fall into thinking that “well if they can’t download the latest version they’ll be forced to upgrade.” It doesn’t work like that, IT groups don’t care what the programming departments have to do to make things work, they just care that the corporation is secure. If that means delaying the upgrade to IE 9 to next year so it can be reviewed for security purposes so be it.

    Do I wish that we would upgrade? Absolutely. But that’s not the reality for most corporations (yet). Hamstringing internal departments by eliminating one of the few tools we have won’t help matters. Hope this sheds some light on a different perspective.

    • Peter

      Monk, I feel your pain. While the rules are a lot more relaxed in the state company I am webmaster for, we still are obliged by law to cater for *everyone*, regardless of what they use to access the web (think IE5/Mac, screen readers, even printouts).

      But that is the beauty of progressive enhancement and graceful degradation. I simply cannot rely on jQuery being available. (And to be honest, nobody should. Network errors causing jQuery not to load are still all to common.) The website has to function regardless, all content has to be available and accessible regardless.

      jQuery is the topping of the cake. What you and your colleagues are missing out of is the newest trends and optimizations in user interface design and usability. But your websites should function none the less, regardless of what version of jQuery is being used.

      • Monk

        Glad to see I’m not alone Peter! You also raise some really good points about progressive enhancement. If it’s a public website we definitely take that route.

        For our internal sites and products we can predict our future upgrade paths, and we know we won’t be going backwards to IE6 (Thank god!) So for internal sites we focus on our current base installation and future browser use. So we might not worry about how something will display in Opera since our internal site won’t even use it.

        Isn’t it a strange world being internal within a company? In the free market you generally worry about the main browsers from a certain point up. But internally you sometimes focus on a browser/platform that everyone else considers ‘obsolete’. This is especially true about internal initiatives.

      • Monk

        Peter I also failed to mention, many times tight timelines come into the mix. Here in Canada we don’t have the same legislation that exists in the states about accessibility. So we aren’t legally required to make anything accessible (bad for business? Yup). Often the progressive part of ‘progressive enhancement’ is the first to go so a timeline can be met. Generally there is more emphasis on “will it work in browser X and anything newer?” vs “does it work on all browsers older or newer?”.

      • Peter

        Hi Monk. To be honest, I shiver at your mention of “So we might not worry about how something will display in Opera since our internal site won’t even use it”. In my opinion, that is exactly the attitude that has made it impossible for IT departments to upgrade browsers. Because web developers didn’t worry about how something will display in Opera, or IE15, or Modern Browser X, they have been unable to get those websites to function with exactly those browsers when the the rest of the world started using them.

        Companies that want to maximize their income, will often make their sites compatible with a browser that is generally considered obsolete, because there is always a part of the market still using outdated browsers. The only difference lies in “how obsolete”, which is a cost/benefit evaluation.

        I am confused by how the progressive enhancement can be the first to go, but that probably depends on how you approach the challenges. For me, the initial most basic version is always the one that works on any legacy system. No JavaScript, no fancy layouts, maybe not even any images. Simply because that is the quickest to make. After that is finished and tested, I start adding layers of enhancement that may not be compatible with older browsers. But these enhancements are always optional, always keeping the baseline functional. I don’t see how making a website specifically for modern browsers can be quicker than making one for any browser, for me it’s always the opposite…

        That being said, I see *lots* of sites that don’t work on legacy browsers. (And I see just as many sites that don’t work on modern browsers.) In nearly all cases, this is because the developers didn’t understand the specific limitations and possibilities of web development languages, and tried to go against the flow by adding their own custom solutions, instead of focusing on a functional baseline. (SAP for example is very good at doing this wrong.)

      • Good points, Peter.

        The reason IE6 lingered for so long was because developers made sites and applications which we’re IE-specific. To be fair, IE6 was the only mainstream browser for several years and web standards were in their infancy. That’s not the case now, but there’s still an “I only test in browsers X and Y — damn everything else” attitude within the industry.

        Developers then complain that people won’t upgrade. Yet part of that reason is because people still need to use an application those developers created which only works in a specific browser.

        Web standards and progressive enhancement can make your site/app work in every legacy, current and future browser. That approach doesn’t take longer but, unfortunately, it’s rare to find developers who bother.

      • Monk

        Hi Peter and Craig,

        I agree that dropping progressive enhancement or going the other route and only worry about legacy browsers is bad. We should be reaching to include everyone everywhere, that’s the point of the web right? (Rhetorical… btw ;) )

        Often however the business needs and financial needs trump how much time or effort might go into a project. At the beginning of each project I’ve been on there’s always a discussion about what audience and browsers we author for. My experience is this happens in private or public sector.

        In the private sector it may be the client doesn’t want to spend money on responsive design since his target market don’t use cell phones, or he doesn’t want to pay for the extra design and programming effort. In the public sector, especially if the project is for internal purposes only, only for employees and not the public, there is a temptation to see that as a “closed platform”. By that I mean the business view is “why are we going to worry about browser Y when we use browser X v2.0 and in the future we only ever anticipate using browser X v3.0”. In a situation like that where time and finances come to play they often trump the development ideal; that is create content that can be consumed by everyone regardless of browser or device.

        In the end the decisions to include or exclude a technology aren’t usually made on the whims of designers or developers. Most of the discussions around topics like these tend to have a theme that “the developer/designer just doesn’t want to build it properly”. That thinking is an assumption about what the developer wants to do but isn’t something based on facts (desire or motivation are incredibly difficult to prove). Rarely if ever do I see the topics of scope and budget appear, both of which have a huge impact on outcome and project planning. I would argue these two factors have more impact on how a project is created rather than what someone, other than the client, desires.

      • Thanks Monk.

        Of course, your audience is everything. But targeting today’s audience can restrict tomorrow’s; which is why progressive enhancement is ideal.

        Developing sites which work in legacy browsers can be achieved without significant extra effort if (a) PE techniques are adopted, (b) testing is started early, (c) testing is done often, (d) you don’t expect pixel perfection, and (e) you’re happy to accept some functions working differently.

        Unfortunately, this process usually breaks down because the client either has unrealistic expectations and/or the developer prefers to rant about IE and Microsoft rather than getting on with it!

      • Monk

        You’re spot on Craig. Unfortunately I’ve run into points B, C, D and E. Far more often not. In many cases these issues weren’t raised by the client but rather the business owners I worked for due to a lack of understanding web technology fundamentals. Trying to educate bosses is a mind field…. let’s just leave it at that. ;)

    • Chris

      ‘reviewed for security purposes’? What does that even mean?

      • It means that IT departments don’t just install any software without throughly testing it first. Security, reliability, compatibility, etc. are all issues which have to be faced.

        Put it this way, if a software update on your machine caused a problem which meant an hour’s lost time, a similar issue in a 100,000-employee company loses more than 50 man-years of productivity!

      • Security is not the only concern here. Large corporations and agencies also depends on legacy applications that might (or might not) require an older version of an OS or browser to work effectively. Any upgrade to an end user workstation implies retesting those other applications. What you often see in a case like this is that you start pulling a thread and have a whole ball of updates to do (which increases risks and costs).

        It won’t matter what benefits you get if the legacy application cannot be upgraded or is not planned to be upgraded for a while. IT departments have to plan out for the oldest/non-upgradable/non-compatible component of their ecosystem.

  • All of this “concern trolling” about “incompatible API” between 1.9 and 2.0 is actually insane. Right now, we have 6753 unit tests for jQuery, all of which will have to pass for any release of 1.9 and 2.0. This will also apply to ALL FUTURE API (ie. tests will have to pass for both versions). So you can stop talking about it now, because you’re wrong. No — stop — I’m serious; there is no further argument to have about it.

    As for the benefit of jQuery, no one will ever WANT to write web applications using raw DOM APIs, because they’re awful and inconsistent. Additionally, there is a massive jQuery plugin and interface ecosystem (UI, Kendo, Wijmo — to name a few) that makes developing web applications simpler and easier.

    • Thanks Rick. Unit tests are fine, but there have previously been issues between versions of jQuery so you cannot claim they’re perfect. It’s impossible to test every situation where jQuery is used — especially when it’s used in so many places. Forking the library won’t help.

      No one uses raw APIs? I have and regularly do. The majority of raw APIs are consistent in every browser *except* for IE6, 7 and 8. The library certainly makes things easier but, without legacy IE support, there are fewer reasons to use jQuery.

  • My sewing website attracts a lot of old people that are using IE7 and IE8. Still, I just don’t care. Even old people with old computers can download Firefox,

    • As a good developer, don’t you have a duty to support whatever browsers your customers are using? You’re free to restrict access, but who does that harm? You or your customers — who can easily find a working site elsewhere?

      Besides, not everyone can install alternative browsers or upgrades. Few people know what a browser is and large organizations often have locked-down IT systems.

    • dermot

      Then you need a marketing 101 course. Finding a new customer costs 10 times more than keeping existing customers. You will push away your old customers and you will have serious problem to attracting the same number of them.

  • Peter

    Please note that jQuery is NOT telling you to use Conditional Comments. It’s just a possible solution they suggest. You are correct in that it would be better to do feature detection in JavaScript and based on those results load one or the other library. This is a perfectly viable solution, however it will require more downloads and more processing in the browser.

    Take a look at Google; they optimize their site heavily for speed and compatibility. However, from a viewpoint of standardization and cleanliness, their code stinks badly. What is “best” always depends on how you measure.

    • No, they’re telling us to use browser detection.

      I have not suggested that feature detection and loading is a better solution. After all, jQuery 1.x does feature detection and doesn’t make additional HTTP requests. If you require IE6/7/8 support, I would suggest that it’s best sticking with jQuery 1.x. Time will tell, but I’d be amazed if jQuery 2.0 offered a noticeable speed boost to other browsers. In fact, if jQuery 1.x is causing performance issues, you’re better off writing your own optimized library.

      Why are comparing the situation to Google? Google can do what it likes — it’s Google. The company releases some shocking code because speed to market is normally more important. Google can afford to fail and it has the resources to redevelop every system every day. Do you?

  • Patrick

    “the (jquery) team shouldn’t abandon that policy too hastily”

    2013 is too hastily? Well that’s a subjective opinion.

    • It’s only 6 months away!

      • Patrick

        Relative to what though?

        6 months from today? Yes.

        But even IE8 is 4+ years old. I don’t consider that hastily. How long should they wait in your opinion before it’s not considered “hastily”? 4+ years in the Internet industry is a decade in others.

      • Of course IE8 is “old”, but that doesn’t matter. Whether you like it or not, people out there are still using the browser. Those on corporate XP environments may not have a choice.

        It’d be great if everyone was on the latest browser edition and, one day, that may be a reality. But we’re not there yet.

    • dermot

      It does not matter how many years. The problem is that huge number of users are still on Windows XP and IE8. Most Corporate users will still use IE.

  • Patrick

    Also, for those where support of older browsers is a necessity…I suggest you also turn back the clock on your designs and functionality. This way, things such as jQuery and CSS3 are irrelevant. IOW, my thinking is that if your corporate environment does not officially support modern browsers….then as a developer/designer, you should not introduce modern browser techniques.

    • There’s nothing wrong with progressive enhancement. After all, adding CSS3 rounded corners won’t break IE6.

      But I agree that in a corporate environment where you’re restricted to a legacy browser there’s little point considering modern features which the browser doesn’t support. Of course, PE allows you to develop in a way which allows you to add them later.

  • I am in full support of jQuery’s decision. I think that by still supporting old browsers it limited what all the library could do. This is like the site that is now charging an IE7 tax. I think that people need to stay current with technologies. If they don’t they are holding everyone else back by making us support sites for them as well as the people who do have the latest stuff. It is not our fault as developers that people don’t update their systems.

    • dermot

      “by still supporting old browsers it limited what all the library could do”

      Like what?

      As article described IE8 is the last IE version available for Windows XP.

    • jQuery 2.0 will have the same API as v1.9. It offers exactly the same methods, except it’s dropping legacy IE support! There’s nothing in the core jQuery library which cannot be coded for IE6/7/8.

      As for fault, IE6 lasted so long because developers created IE6-specific systems. Who else is to blame? Besides, developers cannot force software on people. You can recommend updates but, ultimately, it’s their choice. You either support the applications people use or accept that you’ll lose a percentage of customers.

  • mmj

    > Consider the DOM querySelectorAll(CSS selector) method; it’s supported everywhere (even in IE8) and will always be faster than jQuery’s $(CSS selector).

    jQuery’s selector engine will actually use querySelectorAll() in most cases when it’s available – this has been the case for some time. One more good thing about jQuery up to this point.

    I agree with pretty much all your points, if this is indeed the direction jQuery is taking. The whole power behind jQuery, to me, has been its ability to abstract over browser differences.

    • If it’s available, jQuery will use querySelectorAll() — it only falls back to coded alternatives for IE6 and 7. My point is, if you’re not supporting IE6/7, querySelectorAll(selector) is provided by all browsers, is faster than $(selector), and is a live collection which has further benefits.

      In other words, do you really require jQuery if you’re not coding for IE6/7/8?

  • Nice to hear that.. :)

  • Interesting. Not sure what to make of it. Good for reasons such as trying to push the web forward + force some users to upgrade. Bad because we’re going to have code riddled with more conditional statements leading back to 1.9 for legacy IE.

    • Is is jQuery’s job to push the web forward? After all, people often use jQuery to avoid browser compatibility issues. Besides that, browser sniffing is backward step.

      • Rick

        … not only for browser compatibility: jQuery is adopted because it’s far more easy elegant and friendly than raw javascript in selecting, traversing, event handling, ecc.
        Is it jQuery’s job to push the web forward?
        It’s up to jQuery developers team to decide their own goals.

      • The jQuery team can do whatever it likes. But, if that causes problems for developers, there are plenty of other options.

  • I don’t think JQuery’s job is to push the web forward, I think it’s job is to make it easier for us to build applications that will work in a variety of web browsers. The applications we build push the web forward, JQuery was, and may still be, the tool we use to make that job a little bit easier on us.

    I’m not sure what the lifespan of JQuery will be if they drop IE 8. I think that may be pushing a little too far. The reason I use the library is so I don’t have to code around browser incompatibilities. If JQuery starts becoming a headache itself, I may not need it anymore.

  • I don’t see what all the fuss is about. the JQ team has done everything possible to make the transition painless.

    It’s not like they said they’re going to delete all the legacy versions. If a legacy browser (and face it, IE LTE 8 is legacy) makes up a large part of your market share use the legacy version (1.9).

    Even though I hate to admit it to myself, jQuery is note solely used for cross browser compatibility. You cannot expect Windows XP and IE 8 to limit the progression of the library.

    Use the version appropriate for you and stop complaining.

    • If the jQuery team wanted to make the transition painless, they’d retain legacy IE support until the browser died a natural death. Making developers choose will undoubtedly cause confusion and do you really think v1.9 will evolve at the same rate as v2.x?

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