jQuery 2.0 Will Drop Support For IE 6, 7, 8
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.'"
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!
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?
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.
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.
I hate old IE versions as much as every other web developer, but I don't think this is the right way to go yet. One of the main reasons most developers love jQuery is because it allows them to forget about IE quirks and lack of compliance, and just write code. I think it would be better if they continued to support IE in their main branch, but also offer a "lite" version without IE support.
Since 10.0 is the ESR that is the lowest supported baseline now even though it is only supposed to be used in corporations. Too many people still using the unsupported 3.6 release and below. Getting major web toolkits to drop it will provide a force to push people up to date. Then when ESR 17 and 24 come out do the same.
Unfortuatley IE 8 will be here for a while. Purely because Microsoft won't give anything above it for XP. XP is here to stay for a long time despite being "officially" dropped in 2014. Yes you can install other browser on XP but not in corporate controlled environments.
This is horrible - not because i like these browsers, but because so many people use jQ for just that - make web sites work in as many browsers as possible.
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.
Looking for a Rails developer in Chapel Hill?
Find, finally kill the bastards. But 8?! This is the last IE available for XP, which is still widely used in companys....
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?
Well, don't worry about that. We can get you back before you leave. (Dr. Who)
The alternative is sticking with jQuery 1.9 until April 8, 2014, and then flipping to jQuery 2.0.
Another reason why Dojo Toolkit is more attractive than jQuery. Clients don't care that the JS executes however many milliseconds faster, and they also don't care that the developers have an easier time not supporting older browsers.
What they do care about is stuff that "just works", and being able to add new features at the speed of *click*. Like any tool, if it hinders you from delivering either of these, it's fit for the trip out behind the woodshed.
I'd like to hear comments from other toolkit devs (Sencha, YUI, etc).
I can see dropping IE6 & IE7, because there's no sound reason for anyone to still be using them. But IE8 is the terminal version of IE for Windows XP, which remains one of the most widely-used operating systems on the planet. It's not going to go away just because someone doesn't want to support it any more.
http://alternatives.rzero.com/
"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 ] ) < 9.0 ) )
echo "<script type='text/javascript' src='jQuery-1.9.min.js'></script>";
else
echo "<script type='text/javascript' src='jQuery-2.0.min.js'></script>";
?>
Remember that IE can be used in Conditional comments
that is
<!-- if IE lt 9 ->
jquery 1.9
< endif -->
So use both, that's why there's API parity.
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.
I think the primary cause of the confusion is that there are two version numbers. It sounds like the "new" version is dropping IE6-8 support when, in fact, both 1.9 and 2.0 are "new" versions. It would have been better if they shared a version number with some sort of modifier:
2.0 - 2.0 without legacy support
2.0L - 2.0 with legacy support (IE6-8)
Simply changing the version number makes the difference clear while mitigating the worry/panic.
In the news from 2013: jQuery adopts the Dewey-decimal numbering system for its versions. The next version will be 1.9.3.2.
Workplaces should actually be the least problematic. You can dictate what version of IE people are using, and at this point any responsible IT department REALLY should have a migration plan in place for getting rid of any legacy XP boxes.
Heck, if a workplace hasn't already moved to 7 by now - they've got bigger issues than worrying about jQuery.
#DeleteChrome
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.
And so having completed a library that addresses the weaknesses and incompatibilities it seeks to address, jQuery will reach it's ultimate version at 1.9. jQuery 2.0 won't be very popular for years.
Remember, IE 7 is old, but people are buying computers less frequently, so I don't think it's going away so quickly. It is going to be REALLY hard to kill Windows XP. And so it will be really hard to get everyone onto IE9.
Anyway, I think the future browsers will just be made with jQuery in mind. They'll probably all run a version of the jQuery selector natively. I think future browsers will integrate jQuery away.
Their 1.9 branch will continue to support IE8 at least as long as Microsoft does.
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.
I'm having a "Gangs of New York" moment here yall.
"The Earth turns, but we don't feel it move. And one night you look up. One spark, and the sky's on fire."
-Amsterdam Vallon
JQuery 2.0 won't see really widespread use on the 'desktop' web until the userbase has largely moved away from XP. In the mobile world, though, we are grateful for any speed boost, so it'll build up a head of steam there for awhile.
This isn't anti-MS flamewar crap. JQuery is fully embraced by Microsoft, and is basically their ordained way of doing things in ASP.net MVC.
If JQ2.0 has major features that developers really want/need, I would expect that MSFT would maintain their own fork for older versions of IE.
Hell, if it's call compatible with 1.9, a few simple lines of javascript should be sufficient to load the right library for the browser. Browser detection in javascript is an ugly hack, but it'd be a workaround, at least.
Or you could use chormeframe, but that's an even uglier hack, IMO.
Just because MS doesn't officially support it anymore, doesn't mean it's going to just go away.
Even if Windows XP itself doesn't go away, old IE will if web sites start putting up wording like this: "As of April of 2014, Internet Explorer for Windows XP is no longer supported by Microsoft. It has known security defects that Microsoft will never fix, through which someone could break into your computer. Viewing any web site with Internet Explorer for Windows XP is potentially not safe. For your safety, we recommend using Firefox, SeaMonkey, Chrome, Safari, or Opera software to browse the web."
When enough websites do this, the IE-users will figure out the internet is broken with their browser
But if not enough web sites do this, IE users will defect from web sites that no longer support IE to web sites that advertise that they still support IE. It's a prisoner's dilemma.
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.
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.
If by 250k you mean 80k, then sure..
-rw-r--r-- 1 xxxxx staff 85260 Apr 30 10:28 jquery-1.5.1.min.js
If you're building any sort of complicated website these days, you will use alot of jQuery.. Do you really want to go write a custom ajax handler? why bother..
Plus, using jQuery allows you to leverage tons of other pre-written libraries which were all written on top of jQuery and will avoid alot of cross-browser bugs and repeated code..
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.
If governments and other organizations aren't willing to move beyond XP
Then their IT departments are acting as if they want proverbial egg on their face. The first post-EOL exploit for XP will result in high-profile computer intrusions at such organizations.
I wonder if those older browsers can still be supported with Jquery 2.0 by using Modernizr?
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.
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 compatibility issues solve themselves.
Good, people need to stop supporting crap if we want the crap to go away.
Mod parent up.
If you know anything about Ajax, you'd understand that unfortunately even now in 2012 Ajax is not a standard cross-browser API. Virtually every browser has a different way to do this. Implementing it by hand means basically writing something like jQuery on your own - what's the point? Even if you don't use anything else from jQuery, the Ajax handler alone is worth every byte of the framework bloat right there.
The problems from Perl do not apply to Javascript with its runtime binding, JIT compilation, and no persisted binary code. Even if you don't code specifically to make things version-insensitive, from my experience the chances that things will work just fine after you make an upgrade are pretty high, as long as you stick to mainstream frameworks who are maintained by people with a clue.
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 should still include support for IE9 and just have it automaticaly handle switchign between the faster and slower code. Either way its way way too early to drop IE8 and maybe even IE6-7
http://interserver.net/
I like this alot.
Cross-browser compatibility is the only reason I even use jQuery.
Browsers are converging, there is no question about it. I don't doubt that as browsers get closer and closer to standards that jQuery gets slimmer and it's bac-end code gets simpler. So... why will we even need it anymore when regular JS and HTML5 work equally well?
Not till the end of 2014, till *April* 2014.
A much, much better idea would be to provide the base code for a compatibility shiv for IE versions 6, 7, and 8 (individually), and then write jQuery in a completely open manner. If any other browser requires a similar compatibility shiv, release one for them, rather than polluting the core codebase with any "temporary" code.
Of course, that means pressuring MS, Mozilla, and Google to all support conditional comments (not a bad idea), or to add a "for-agent" attribute to css/script tags.
The alternative is that conditional comments disappear, and web developers are tasked with finding a way to identify the various browsers in javascript code, or worse, by doing the detection based on the user agent string.
It's probably too late for anyone to see this and mod it up, but there is no need for the header you propose. All you need to do is add a
Vary: User-Agent
response header and that tells the upstream proxies the response is dependent on the value of the User-Agent header. It's good practice to do that whenever your content changes based on any of the request headers.
Why do you think businesses are still on XP? Because people have been tolerant of slow business upgrades. As XP becomes more painful businesses will be forced to migrate. That's a good thing. Vista was released January 30, 2007. Windows 7 ships with an XP compatibility mode to handle legacy. There is no good reason that any business computer at all anywhere should be using XP. One of the ways of making that happen is for stuff to start breaking in XP.
Workplaces should actually be the least problematic. You can dictate what version of IE people are using, and at this point any responsible IT department REALLY should have a migration plan in place for getting rid of any legacy XP boxes.
Heck, if a workplace hasn't already moved to 7 by now - they've got bigger issues than worrying about jQuery.
Many are not. Even if they did switch to Windows 7 it comes with IE 8 and corporations paranoid and scared from the IE 6 experience will also lock that browser from being upgraded too and refuse to upgrade until 2019.
http://saveie6.com/
I hate IE as well. love you jQuery