Forgot your password?
typodupeerror
Internet Explorer

jQuery 2.0 Will Drop Support For IE 6, 7, 8 250

Posted by Soulskill
from the go-big-or-go-home dept.
benfrog writes "The developers of jQuery recently announced in a blog entry that jQuery 2.0 will drop support for legacy versions of Internet Explorer. The release will come in parallel with version 1.9, however, which will include support for older versions of IE. The versions will offer full API compatibility, but 2.0 will 'benefit from a faster implementation that doesn't have to rely on legacy compatibility hacks.'"
This discussion has been archived. No new comments can be posted.

jQuery 2.0 Will Drop Support For IE 6, 7, 8

Comments Filter:
  • Like (Score:5, Insightful)

    by Krojack (575051) on Friday July 13, 2012 @03:41PM (#40642215)
    I like this however I'm guessing anyone that starts using this will have a boat load of complains thus 2.0 won't be used for several years. Sadly. Damn IE slowing down even non-IE users!
    • Re:Like (Score:5, Informative)

      by Kate6 (895650) on Friday July 13, 2012 @03:47PM (#40642333) Homepage
      You see the bit where it says "full API compatibility"? That means with a few lines of PHP (or some equivalent back-end language) you can have a look at the user's browser USERAGENT string, figure out if it's an MSIE browser or not and serve the preferable version of jQuery... 1.9 for legacy IE, 2.0 for IE9 and for standards compliant browsers. And the "full API compatibility" means the rest of your code will play nice with either.
      • This is fine for 1.9/2.0 but what happens when 2.1 and 2.2 come out? The API's will diverge.

        I hope 1.9 stays api compatible, but I would doubt it.

        • Re: (Score:3, Interesting)

          by Kate6 (895650)
          There's already a fair bit of divergence between what you can do in IE and what you can do in other browsers.  IE (including IE9) doesn't implement as much of HTML5 as other browsers.  IE's SVG support is in its infancy compared to other browsers', and completely nonexistent before IE9.

          So we might end up with some jQuery functionality silently being disabled in legacy versions of IE too.  Big whoop.

        • by dingen (958134)

          Once a version of jQuery 2.x comes out with an API which isn't compatible with 1.9, IE8 better be long forgotten.

          • jQuery comes out with new API's all the time.. Remember live was deprecated by delegate, then by on... this stuff seems to happen *EVERY* single version.

            • Re:Like (Score:5, Informative)

              by dingen (958134) on Friday July 13, 2012 @04:20PM (#40642883)

              But .delegate(), .on() and .live() all still work with recent versions of jQuery, so your old code still runs with newer versions of the library. New features being introduced is not bad. The pain starts when old features are dropped.

        • XP (and therefore IE6/7/8) is not going to be with us forever, either.

        • by kawika (87069)

          What are you specifically worried about? Dell is still using jQuery 1.2 on their site from 2007, and it seems to work. So in 2014, something will break in the (supported) 1.9 version that the jQuery team refuses to fix, but you can't upgrade to 2.1? Can you say what that something might be?

          • by Pieroxy (222434)

            And this is the reason I don't use jQuery. When something breaks down on a newer browser and you have to manually patch your JS as fast as possible, you've better patch your code. Patching jQuery might prove to be quite complicated depending on the fix.

            Not mentioning that support for legacy browsers is exactly what got jQuery where it is in the first place.

            Methinks some people are shooting themselves in the foot.

          • You don't appear to be thinking clearly about this.

            If my site uses jQuery 2, and I server 1.9 to IE users, then I want to upgrade to jQuery 2.1, or 2.2, i'm stuck because jQuery 1.9 may not be compatible with 2.1 or 2.2 or whatever later version i'm using. I'm then forced to continue to use jQuery 2 because it's compatible with 1.9.

      • by Krojack (575051)
        What about some jQuery plugin that requires 1.9 or 2.0?

        Sorry but I don't like having to write a website 6 times over. One for each IE 6, 7, 8, 9, 10 then Firefox and Chrome. Writing a site now and once I'm done go back and add CSS tweaks for special IE is already a pain in the ass.
      • Re:Like (Score:5, Insightful)

        by madprof (4723) on Friday July 13, 2012 @04:24PM (#40642947)

        Holy moley. I might be saying what others say but please, for the love of everything good, use conditional comments.
        They've been around since IE5. You will love them.

      • Re:Like (Score:5, Informative)

        by Art3x (973401) on Friday July 13, 2012 @05:46PM (#40643917)

        with a few lines of PHP (or some equivalent back-end language) you can have a look at the user's browser USERAGENT string, figure out if it's an MSIE browser or not and serve the preferable version of jQuery... 1.9 for legacy IE, 2.0 for IE9 and for standards compliant browsers.

        Or do it with HTML comments (this actually works):

        <!--[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]-->

        Less code. Also you've offloaded the CPU processing from your server to the user's browser.

        This was in the article by the way. . . . Oh . . . nevermind.

      • Re:Like (Score:5, Informative)

        by jmerlin (1010641) on Friday July 13, 2012 @06:48PM (#40644537)
        User Agent hacks are incompatible with caching. Bad idea. Use conditional comments so IE gets its familiar old diaper and every other browser gets a shiny new car. Either that or propose an If-User-Agent header so proxies and caches can figure out whether your request is the same as a previous one.
      • You see the bit where it says "full API compatibility"? ...

        This is the same unicorn as "platform independent". Many people talk about, but nobody really ever saw it.

    • Sadly. Damn IE slowing down even non-IE users!

      Even more sadly, this is not news. IE has been effectively sabotaging the non-IE community for years. The need to specifically code for IE6 and IE7 due to their crappy compliance with web standards has swallowed immense amounts of global developer effort, which could otherwise have been invested in improving the interwebs for everyone.

      Just die already.

      • by nedlohs (1335013)

        Given most (not all) web development makes things worse, that seems like a good thing.

    • by TheSpoom (715771)

      While normally useragent-based feature detection is a bad thing, it seems like one could selectively insert a script tag for either jQuery 1.9 or jQuery 2.0 (they are supposed to be API-compatible, yes?) depending on whether or not the user is using a legacy IE, without any performance hiccup.

      • This [microsoft.com] is a far better way since anything non-IE pretending to be IE will just ignore these. Web designers have been using these for years to load special CSS workarounds for all the bugs in IE.

        • by TheSpoom (715771)

          I hear the people saying that, but what would you do to make the page load either one or the other jQuery, but not both? Loading two jQuery instances causes all sorts of problems if not handled well.

          Having done web development for many years, believe me, I'm very familiar with all variety of IE-handling hacks. At the moment I can't think of a way to conditionally load jQuery 2.0 if and only if not using legacy IE, and load jQuery 1.9 if and only if using non-legacy IE or non-IE, using IE conditional comme

          • by kawika (87069)

            Conditional comments do exactly that. There is an example in the jQuery blog post.

          • They are called Downlevel-revealed Conditional Comments, and they are described in the linked article.

            <![if !IE]>Seen by everything but IE.<![endif]><!--[if IE]>Seen only by IE.<![endif]-->

            You're welcome.

          • Re:Like (Score:4, Insightful)

            by omfgnosis (963606) on Friday July 13, 2012 @06:12PM (#40644245)

            If you look at a set of the available conditional comments in an editor with proper syntax highlighting, it'll become obvious immediately how they work: everything that is targeted at IE (or specific versions thereof) is technically inside an HTML comment and ignored by other browsers; IE parses these comments and, in the presence of conditional directives it determines (by version) whether to treat them as if outside an HTML comment. Everything that targets non-IE browsers is outside of a comment, but IE will treat it as a comment.

            This is a comment, unless loaded in IE versions 8 and below:
            <!--[if lte IE 8]><script src="/path/to/jquery19.js"><![endif]-->

            This is a comment, unless loaded in IE versions 9 and above:
            <!--[if gte IE 9]><script src="/path/to/jquery20.js"><![endif]-->

            This is not a comment, unless loaded in IE:
            <!--[if !IE]><!--><script src="/path/to/jquery20.js"><!-- <![endif]-->

    • True, Walmart.com will have IE 6/7/8 visitors for years to come, but there are plenty of places where someone might be using jQuery but not need IE 6/7/8 support. It could be a cutting-edge public web site, a desktop app using an embedded HTML rendering engine, or a mobile app where oldIE doesn't matter. You can either use jQuery 1.9 for now, or use graceful degradation to give those people a really basic experience and a nudge to upgrade.

    • by hairyfeet (841228)
      Really? Because i thought the move to mobile was quickly making IE obsolete. After all we are seeing Chrome and iOS everywhere, and the market has been focused on consumers over corporate for a few years now so i figured the days of IE dictating squat were finally behind us, thank the FSM. Was i wrong?
  • by Anonymous Coward

    I thought a large part of the appeal of jQuery was that it allowed you to avoid writing the crufty legacy browser code that you would normally have to re-implement for every application. If they no longer offer that then what is the point of using it?

  • by lavaforge (245529) on Friday July 13, 2012 @03:46PM (#40642289)

    Does anyone here have enough knowledge of the JQuery codebase to say how the IE-specific cruft breaks down by version?

    IE6 is a monstrosity; that's pretty much a given, and IE7 isn't great either. I could see dropping support for both of those being a big win in terms of cleaning up the codebase. That said, how much do they gain by dropping IE8 as well? It was only released 3 years ago.

    • by tobiasly (524456) on Friday July 13, 2012 @03:57PM (#40642501) Homepage

      Does anyone here have enough knowledge of the JQuery codebase to say how the IE-specific cruft breaks down by version?

      IE6 is a monstrosity; that's pretty much a given, and IE7 isn't great either. I could see dropping support for both of those being a big win in terms of cleaning up the codebase. That said, how much do they gain by dropping IE8 as well? It was only released 3 years ago.

      The "promoted reader comment" in the linked Ars article [arstechnica.com] actually answers exactly that:

      Drizzt321 wrote:
      Wow, removing support for IE8? That's a really bold move. I can see IE6 & 7, those are rather old and should be deprecated and people should be really encouraged to move to newer versions.

      John Resig has said in interviews that most of the IE6 and IE7 code is needed for IE8 as well. While IE8 has far better layout and CSS engine evidently it still has pretty bad DOM API. Resig pointed out that dropping support for IE6 and IE7 would have very little impact on the size and complexity of the library unless they drop IE8 as well

    • by kawika (87069) on Friday July 13, 2012 @04:12PM (#40642757)

      As far as bugs and quirks go, a lot of the ones in IE6 and IE7 are also present in IE8. In specific, things like eating HTML5 tags, the lack of true opacity support and the proprietary IE event model that used attachEvent instead of addEventListener. There's quite a bit of code in jQuery to deal with IE event issues, for example the lack of a bubbling change event. IE8 managed to plug some memory leaks and wasn't as bizarre with the "attroperties" issue as IE7 was, but they still have a lot of sins in common.

    • by gsnedders (928327)

      IE8's big change was all the brand-new layout engine (thus the fairly rapid development in IE9/10, coming from nowhere to being right up there with CSS Level 3 module support). It changed relatively little elsewhere.

  • by tepples (727027) <{tepples} {at} {gmail.com}> on Friday July 13, 2012 @03:46PM (#40642291) Homepage Journal
    Developers tend not to write programs for Python 3 because most end users who have Python installed have Python 2 installed, and some Python environments (such as Windows) can't easily have multiple versions installed side-by-side. Likewise, developers will continue to use the jQuery 1.9 branch because until April 2014, when Windows XP reaches its end of life, a lot of people will still be using Internet Explorer 8.
    • by dririan (1131339)

      some Python environments (such as Windows) can't easily have multiple versions installed side-by-side

      The Python installers on Windows install to (by default) C:\Python$MAJOR$MINOR (Python 2.7 installs to C:\Python27, Python 3.2 installs to C:\Python32). For scripts that require a certain version of Python, you may have to open it with the proper version yourself, because (obviously) .py files can only be associated with one program at a time. But for scripts made to be run by end-users, (assuming they don

      • But for scripts made to be run by end-users, (assuming they don't ship their own Python runtime in the first place) a simple EXE wrapper can use the right interpreter. What part of this isn't easy?

        That depends. Is there an automated tool to create and deploy such EXE wrappers yet?

        Also, many developers make things compatible with both, which is made much easier with 2to3

        And harder when your program relies on third-party libraries that have not yet been ported to 3.

    • No, adoption of Python 3 is limited by library support, not install base. Libraries need to be rewritten for Python 3 and some major ones (e.g. Django) are not yet ready. In this case, jQuery 1.9 and 2.0 will have the same API, but 2.0 will not work on older versions of IE in order to optimize for speed. Your comment about Windows XP is apt; this is akin to software dropping support for older OS versions.

  • Missing the point (Score:5, Informative)

    by bobetov (448774) on Friday July 13, 2012 @03:51PM (#40642417) Homepage

    All, one of the big reasons for this move is to provide a cleaner, smaller, faster version of jQuery to apps dedicated to a given platform, such as iOS apps running as HTML5 shells. These applications know their "browser" environment, and thus can benefit from lack of IE support with no cost in terms of audience size.

    No one who has a general-public website should use 2.0 for years to come, but if you're developing a quickie Android app, or one of the dozen or so javascript-based desktop shells, etc, then this move is for you.

  • IE6 and 7? (Score:5, Insightful)

    by Anonymous Coward on Friday July 13, 2012 @03:52PM (#40642421)

    Find, finally kill the bastards. But 8?! This is the last IE available for XP, which is still widely used in companys....

  • by mpol (719243) on Friday July 13, 2012 @03:52PM (#40642429) Homepage

    I think it's a good thing. It might even be better if first IE6 and IE7 support was dropped, and IE8 support later, but that might be a lot of work.

    I axpect that for the first few years jQuery 1.9 will be the most used version, but you can afcourse load jQuery 2.0 on newer browsers, and only load 1.9 with conditional comments.

    I'm wondering how the big CMSs will handle this. Will Wordpress come with 2 versions for a few years?

    • More than likely, it's the same code for IE6/7/8 that they're dropping. If you leave it for 8, you may as well leave 6 and 7, because you don't gain much.

      • Too bad I am working on a corporate oriented site. I can imagine IE 6 and 7 will be over 50% usage by the biggest customers who spend the most, even if they are a small minority overall.

        I should not have to be reading books on IE 6 hacks in 2012.

  • "Full API compatibility" means the same identical code should be able to work with the slower-performing version 1.9 on legacy IE browsers *and* with the more optimized version 2 on IE9 and standards compliant browsers.

    All you need is some back-end code to examine the user's browser's "useragent" string and figure out which version of jQuery to serve.

    <?php
    preg_match( '/MSIE ([0-9\.]+)/', $_SERVER[ 'HTTP_USER_AGENT' ], $matches );
    if ( ( count( $matches ) == 2 ) && ( floatval( $matches[ 1 ] ) <
    • by flux (5274)

      What's the point in using 2.0 in the first place if 1.9 will do? Obviously 2.0 will have some functionality or fixes 1.9 won't. If you really want to do what you suggest, you would still have two code paths in your system, one for 2.0 and one for 1.9 (or possibly one for 2.0 and then gracefully degrade when there is no 2.0).

      • by dingen (958134)

        This is the web we're talking about. Especially with so many people on mobiles these days, bandwidth is limited so size matters. Even is 2.0 offers exactly the same features as 1.9, 2.0 will be a heck of a lot smaller, meaning faster downloading, faster loading, faster parsing. Especially on phones, that's not just a nice thing to have, it's a necessity.

      • Speed.

      • What's the point in using 2.0 in the first place if 1.9 will do?

        If you'll read TFA, they're doing it so that jQuery will be much faster and more modular. If you just use 1.9, you're punishing everyone who has a sane browser. Their code will run slower so that it won't break for the drones using ancient versions of IE. By offering both and choosing server side, you have the speed and support of the new versions and still support grandpa's Windows XP computer. Eventually Windows XP will die a long deserved death and version 1.9 can go with it.

    • echo + html tags is a huge fail...
  • by JDG1980 (2438906) on Friday July 13, 2012 @04:14PM (#40642803)

    I don't have any problem with dropping support for IE6 and IE7. These should have been phased out years ago, and their only reasonable present-day use is not as web browsers, but as legacy applications platforms for badly coded ActiveX apps.

    But IE8? For users with Windows XP, this is as high as you can go. IE9 is not supported. And WinXP continues to be supported by Microsoft through the end of 2014, and is still in very widespread use among businesses, and to a lesser but still significant extent among home users.

    I wish IE8 would go away (or more specifically, that Microsoft would take the time to backport IE9 to WinXP). Its continued persistence means a lot of css3pie hacks in the website I maintain, which are necessary to get rounded corners and drop shadows in this outdated browser. But it won't go away just because Google wants it to. And saying to use Firefox or Chrome instead of IE is not going to fly in most workplaces, which rely heavily on Internet Explorer's integration with Active Directory and its support for Group Policy. As far behind as IE falls in other categories, no third-party browser matches its abilities on these vital business fronts.

  • by michaelmalak (91262) <michael@michaelmalak.com> on Friday July 13, 2012 @04:23PM (#40642925) Homepage
    In the news from 2013: jQuery adopts the Dewey-decimal numbering system for its versions. The next version will be 1.9.3.2.
  • by kiehlster (844523) on Friday July 13, 2012 @04:28PM (#40643007) Homepage
    Why don't we manage these APIs in a manner like version controls? Maintain a 'core' branch that's compatible with the latest browsers and then have additional 'legacy' branches that break off whenever a browser version is deprecated. I know your first instinct is to argue, "Just install multiple versions of the API," but why not make the API a repository in and of itself? And for those people who want every ounce of speed out of their API, you can just offer a 'core' version of the API that only supports the latest browsers and doesn't include the legacy branches.
  • by JDG1980 (2438906) on Friday July 13, 2012 @04:29PM (#40643029)

    This is a bit off of the main topic... but any idea why none of the browser vendors have implemented native support for jQuery in their JavaScript engines? It seems to me that this would be an easy way to improve performance, considering how many websites use it, and considering that implementing native support for its API would remove the need to go through 2 layers of interpreters.

  • Maybe they were inspired by Google, which declared Chrome 20 would only support only OS X 10.6+, i.e. 80-85% of Mac users.
  • Good.

  • I'm having trouble understanding the "speed" argument. Couldn't you provide different code paths for different browser versions and still maintain full performance?

    I'm sure this means the size of the library is increased some but so what? aint that what cache is for?

    Seems a little odd considering one of the major highlights/selling points was browser compatibility. Write once without worries of platform specific hacks. If you adopt the position of getting rid of old browsers much of those same historical

    • Gone is the big reason for jQuery. So all the added bloat keeps it afloat while we should be bitching about official support for document.getElementBySelector().

      I always wondered why jQuery (last I read the source) didn't implement multiple functions and then dynamically reference the proper function after a test? That caused a minor speed gain for my own compatibility code for quite a long time now.

      Of course their other features that are kind of fun do not help matters.

    • by dingen (958134)

      I'm sure this means the size of the library is increased some but so what? aint that what cache is for?

      Mobile is the main reason. Obviously when bandwidth is tight, size matters a lot. And on top of that, phone browsers typically are a lot worse at effectively caching scripts than their desktop counterparts.

  • Good, people need to stop supporting crap if we want the crap to go away.
  • You cant run IE9 on older versions of windows can you ? Isnt one of the big reasons people used jquery in the first place was because it works well on most all browsers that are actually used? For any site with a fair amount of traffic you cant afford to just cut out so many of your users. Its true that you will be able to add in of If IE9 load 1.9 otherwise load 2.0 but that seems kinda lame and evnetually theres going to be a larger gap between 1.9 and the current 2.0+ version. I think they sh

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Working...