JQuery 2.0 Drops Support for IE6/7/8; API-Compatible with jQuery 1.9.(blog.jquery.com)
blog.jquery.com
JQuery 2.0 Drops Support for IE6/7/8; API-Compatible with jQuery 1.9.
http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/
31 comments
Did anyone read the post? 1.9 will still support ie6/7/8, so just use that for compatibility. Let's move the web forward. I still use XP at home and don't care because I use Firefox. So if grandma/grandpa and corporate america don't get all the new bells and whistles, they are probably used to it, because they don't have rounded corners, text-shadow and box-shadow on everything anyway. They probably won't even know what they are missing on that HP/Dell POS. :p
Good stuff IMO; those who continue to insist on using IE<9 deserve a degraded experience. Those who are forced by their employers should lobby them to upgrade/move to FF/Chrome (and when they inevitably don't listen, then it's really too bad - but if said employer wants to use a service w/o old IE support it might force the upgrade).
In a world where technology is developing at such a pace, it really is time we stopped worrying about old, poorly built bits of software.
In a world where technology is developing at such a pace, it really is time we stopped worrying about old, poorly built bits of software.
I think this makes a lot of sense.
One of our products is a B2B analytics tool that leverages a custom Chrome extension for one piece of functionality. As a result, all of our users are on Chrome.
We already use chai for testing, which doesn't really work in older IE versions, and it'll be great to get the performance improvement from this change as well.
One of our products is a B2B analytics tool that leverages a custom Chrome extension for one piece of functionality. As a result, all of our users are on Chrome.
We already use chai for testing, which doesn't really work in older IE versions, and it'll be great to get the performance improvement from this change as well.
I won't be using for a few a years but I am glad it is leading pushing people to CSS3 compliance.
huh?
IE 7 and 8 are still a huge chunk of the market, and they dont support CSS3.
The important metric is how much of a chunk they are to your business. You shouldn't care if some other site (or all other sites!) have significant traffic from such old browsers. Measure your traffic.
wat?
Isn't one of the reasons for jquery to "abstract away" the differences between browsers so I don't have to worry about it?
Dropping support for popular browsers doesn't seem to help me much.
Dropping support for popular browsers doesn't seem to help me much.
It does seem a strange decision. They even address it in their post:
"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 [still using] oldIE. Yet we also want to move ahead and take advantage of modern browsers, especially the growing mobile market."
The whole point of jQuery is that it's supposed to allow you to move ahead without losing backwards compatibility. Making this split -- especially with a version number, which implies a feature-freeze for 1.9 and new stuff only in 2.0 -- seems like they're just admitting defeat on their primary function.
"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 [still using] oldIE. Yet we also want to move ahead and take advantage of modern browsers, especially the growing mobile market."
The whole point of jQuery is that it's supposed to allow you to move ahead without losing backwards compatibility. Making this split -- especially with a version number, which implies a feature-freeze for 1.9 and new stuff only in 2.0 -- seems like they're just admitting defeat on their primary function.
I think they just realized they can continue to support the old IE versions while other JS libraries advance in functionality, or they can stay competitive.
Which other libraries would those be? (I'm serious.)
There were several fairly well known libraries a couple of years ago, but as far as I can tell, jQuery won that battle decisively. It has almost 100% penetration in the projects I'm familiar with that use a general purpose JS library, and it seems to be the default for articles and blog posts I find on-line these days too.
Part of that success came from the ecosystem reaching critical mass. Many people know jQuery. Many plug-ins are available for jQuery. And the vast installed base usually means quick bug fixes even for recent browser compatibility problems.
If there is something out there that is better by a wide enough margin to justify giving up that established ecosystem, I'd love to hear about it. The ecosystem has plenty of imperfections, but I haven't come across anything yet that seems nearly comprehensive enough to displace the incumbent here.
There were several fairly well known libraries a couple of years ago, but as far as I can tell, jQuery won that battle decisively. It has almost 100% penetration in the projects I'm familiar with that use a general purpose JS library, and it seems to be the default for articles and blog posts I find on-line these days too.
Part of that success came from the ecosystem reaching critical mass. Many people know jQuery. Many plug-ins are available for jQuery. And the vast installed base usually means quick bug fixes even for recent browser compatibility problems.
If there is something out there that is better by a wide enough margin to justify giving up that established ecosystem, I'd love to hear about it. The ecosystem has plenty of imperfections, but I haven't come across anything yet that seems nearly comprehensive enough to displace the incumbent here.
> If there is something out there that is better by a wide enough margin to justify giving up that established ecosystem, I'd love to hear about it. The ecosystem has plenty of imperfections, but I haven't come across anything yet that seems nearly comprehensive enough to displace the incumbent here.
David Mark's My Library[0] is the best DOM library available by a wide margin. It has supreme browser support, and it's "modular" with a custom builder. The code is so solid that many people have borrowed from it, including the jQuery project and myself.
I've also created a DOM library, but with a more limited feature set (it's only a few months old). See my submissions for details.
[0]: http://www.cinsoft.net/mylib.html
David Mark's My Library[0] is the best DOM library available by a wide margin. It has supreme browser support, and it's "modular" with a custom builder. The code is so solid that many people have borrowed from it, including the jQuery project and myself.
I've also created a DOM library, but with a more limited feature set (it's only a few months old). See my submissions for details.
[0]: http://www.cinsoft.net/mylib.html
The JS community has moved beyond DOM abstraction libraries entirely. Using polyfills is now the preferred way to reach older browsers. JQuery serves a role of abstracting the stuff that polyfills can't fix, or to go all the way back to IE6 where the differences are too great to mess with on your own. Without that, there really is no reason to use JQuery at all.
I appreciate the reply, but I can't help noticing that you didn't actually answer my question.
I think jQuery 2.0 is partly a response to Zepto.js [1] -- they're both jQuery-API-compatible, and they both drop support for OldIE (Zepto drops all of IE, though [2]).
[1]: http://zeptojs.com/ [2]: http://zeptojs.com/#platforms
[1]: http://zeptojs.com/ [2]: http://zeptojs.com/#platforms
What do you mean by "comprehensive enough"? Can't you read the code?
I mean in terms of functionality.
To be worth shifting away from the jQuery ecosystem to something new, the latter needs a compelling advantage and it needs to not have any deal-breaking disadvantages. Nothing I've come across so far myself seems to meet both criteria.
To be worth shifting away from the jQuery ecosystem to something new, the latter needs a compelling advantage and it needs to not have any deal-breaking disadvantages. Nothing I've come across so far myself seems to meet both criteria.
I'm sorry if we imply a feature freeze by bumping to 2.0... I'm not where you got that. The plan is to backport any API changes to 1.9 or even 1.10 if we need to make one in 2014.
Here is the magic: IE 6 - 8 are not popular browsers. They are only used if the person using them doesn't know what a browser is. And all it would take for them to switch is one webpage they use popping up "You are using an outdated unsupported vulnerable awful browser, here are Firefox or Chrome, take your pick and don't ruin your web experience any more".
And the corporate clients could finally get through their heads it is not ok to expect employees to be accessing the internet through IE. Businesses don't have the rights to stick their fingers in their ears singing 'lalala' while the internet attempts to grow around the tumour of conditional comments and other crap.
And the corporate clients could finally get through their heads it is not ok to expect employees to be accessing the internet through IE. Businesses don't have the rights to stick their fingers in their ears singing 'lalala' while the internet attempts to grow around the tumour of conditional comments and other crap.
People won't switch because sites are hectoring them with lectures about how something they might be fine with is actually awful. All it would take for them to switch are compelling apps (whatever definition of "compelling" applies to each person) which exploit the capabilities of, and therefore require, the newer browsers, and whose existence is advertised to them. Not "your browser is bad and you should feel bad", but "this site is awesome and will make you feel awesome, there's just one thing - you need to install this awesome browser to get your ticket to awesomeville". Same as any other platform.
Unfortunately it's not a matter of sticking fingers in your ears, I can tell you. If you've got 50-100,000 workstations to worry about, and a couple of intranet apps that only run in older versions (there are more of these than you might think,) upgrading IE could be a fabulously large and expensive project.
Still you gotta catch up at some point. The product I work on is dropping IE8 in January, which will cause some of our larger and less nimble customers to get stuck on an older version until they can fix their browser situation.
Still you gotta catch up at some point. The product I work on is dropping IE8 in January, which will cause some of our larger and less nimble customers to get stuck on an older version until they can fix their browser situation.
"If you've got 50-100,000 workstations to worry about, and a couple of intranet apps that only run in older versions (there are more of these than you might think,) upgrading IE could be a fabulously large and expensive project."
So... don't upgrade IE, but give people the option of - you know - running another browser. The IT folks can even lock it down so no one can do anything useful with it, but they could give people firefox, chrome, safari or opera as another tool on their desktop.
Holding back an entire company's ability to do any modern browsing because you're still tied to one HR intranet app from 2003 is just silly. There's no sane argument to be made for it, in light of the short- and long-term opportunity costs it imposes.
So... don't upgrade IE, but give people the option of - you know - running another browser. The IT folks can even lock it down so no one can do anything useful with it, but they could give people firefox, chrome, safari or opera as another tool on their desktop.
Holding back an entire company's ability to do any modern browsing because you're still tied to one HR intranet app from 2003 is just silly. There's no sane argument to be made for it, in light of the short- and long-term opportunity costs it imposes.
A nasty situation no doubt, but manageable. What I would do is:
0. Rename IE to 'intranet'. 1. Configure IE to only access Intranet. 2. Switch everyone to chrome/firefox, keep bookmarks, etc 3. Hire some university students to temp man the support line as you are flooded with support requests.
As I said a nasty situation. Perhaps it would be best to spread a rumour that someone was fired thanks to IE. That way you are not evil IT getting in the way of everyone's job.
0. Rename IE to 'intranet'. 1. Configure IE to only access Intranet. 2. Switch everyone to chrome/firefox, keep bookmarks, etc 3. Hire some university students to temp man the support line as you are flooded with support requests.
As I said a nasty situation. Perhaps it would be best to spread a rumour that someone was fired thanks to IE. That way you are not evil IT getting in the way of everyone's job.
It isn't sticking fingers in ears, it is yelling at business that software can not be treated like vending machines where you buy one model that lasts decades on end regardless of what new revisions come out. The vulnerabilities and inefficiencies of the old IE browsers are detrimental to the businesses that are resisting change, and the entire web supporting the bad habit is why change doesn't come.
> They are only used if the person using them doesn't know what a browser is.
...or their company doesn't have the budget to upgrade their entire department to Windows 7.
...or their company doesn't have the budget to upgrade their entire department to Windows 7.
Did you read the article? 1.9 will keep oldIE support, get minor updates, and be API-compatible with 2.0.
Fuck IE - they've done the same to us for years.
> Fuck IE - they've done the same to us for years.
You're not "fucking IE" though, you're fucking the end-users; many of whom might be stuck on XP (and therefore IE8) without a huge choice. Corporate users, education users, those without the money to upgrade their OS/machine, etc.
You're not "fucking IE" though, you're fucking the end-users; many of whom might be stuck on XP (and therefore IE8) without a huge choice. Corporate users, education users, those without the money to upgrade their OS/machine, etc.
The reason IE is still clinging on is because not enough people are making noise about it.
The less usable the net is for older browsers, the closer we move the users of those browsers to the threshold of upgrading.
It may mean more complaints from the staff to the IT department, it may mean grandma asking her grandkids why the google is broken, but if enough people are vocal about it, it will encourage upgrading.
Every time you support IE, you are slowing the uptake of newer browsers, and you are a bad person for it.
The less usable the net is for older browsers, the closer we move the users of those browsers to the threshold of upgrading.
It may mean more complaints from the staff to the IT department, it may mean grandma asking her grandkids why the google is broken, but if enough people are vocal about it, it will encourage upgrading.
Every time you support IE, you are slowing the uptake of newer browsers, and you are a bad person for it.
Why are XP users stuck on IE8? (I mean I think there are a myriad of options that are pretty reasonable). It doesn't cost anything or fairly little labor to upgrade to a real browser over the course of a couple years. How far do we take this, why don't we all support IE5? It's time to let it go.
You can either stick with JQuery 1.9 for as long as you want to support IE8 (hopefully not more than 10 or 20 more years).
You can either stick with JQuery 1.9 for as long as you want to support IE8 (hopefully not more than 10 or 20 more years).
Hi, from work, on Chrome, on XP.
>stuck on XP (and therefore IE8)
Being stuck on XP does not mean that you have to use IE8. You can still use the latest version of Chrome, Firefox, Opera, or even Safari.
Being stuck on XP does not mean that you have to use IE8. You can still use the latest version of Chrome, Firefox, Opera, or even Safari.
What is stopping those users from using Firefox?
Corporate; awareness; familiarity
Corporate: the only reason for this is because web apps and sites are written for a particular browser, and not based on standards.
Awareness: when sites don't work, they'll be aware of the problems. The truth is, most users at getting more educated about browsers all the time. It can't e helped that Microsoft has tied browser innovation and standardisation to their operating system.
Familiarity: really fairly bogus as an argument. There is really not that much different between the interfaces of Opera, Chrome, Internet Explorer and Firefox these days!
Awareness: when sites don't work, they'll be aware of the problems. The truth is, most users at getting more educated about browsers all the time. It can't e helped that Microsoft has tied browser innovation and standardisation to their operating system.
Familiarity: really fairly bogus as an argument. There is really not that much different between the interfaces of Opera, Chrome, Internet Explorer and Firefox these days!
Those are bad reasons to hold the web back. They don't adapt because they're lazy or don't know better. Making it hard to use obsolete browsers is doing them a favor. They'll like the present when they try it.
Not sure if you read the article, but 1.9 and 2.0 will basically be the same, just different underlying code. 1.9 will support IE<9, and 2.0 will be smaller/faster/more stable
Ok. So, if I upgrade and someone does visit from an older IE browser what happens? :) I'll be back to testing browser differences.
I guess those are pretty old browsers, so oh well.
I guess those are pretty old browsers, so oh well.
It's pretty simple– if you want to support IE<9, don't upgrade to jQuery 2.x. A lot of people are already dropping support for IE<8.
It's really not that simple. Now you have to check to see if a plugins support 1.9 or 2.0, and plugin writers will have to support both or IE8 supporters will have to live without new plugins.
The article specifically states that 1.9 and 2.0 will be API compatible. So no, you won't have to do anything other than include the proper version and forget about it.
well they do provide 1.9 to handle that, this is is how they recommend you handle that
<!--[if lt IE 9]><script src="jquery-1.9.0.js"></script><![endif]-->
<!--[if lt IE 9]><script src="jquery-1.9.0.js"></script><![endif]-->
I love this product roadmap write up!
Explanations littered with reasoning and also a code-level solution for something that won't be an issue until one year down the road. Hopefully that 93KB (un-Gzipped) beast can be knocked down a bit with 2.X.
Explanations littered with reasoning and also a code-level solution for something that won't be an issue until one year down the road. Hopefully that 93KB (un-Gzipped) beast can be knocked down a bit with 2.X.
Zepto is already a popular option for those who want jQuery features in a lightweight library. The API is essentially identical to jQuery, making it a drop-in replacement at a fraction of the size.
zeptojs.com
zeptojs.com
Zepto is not drop in. Not even close.
Could you expand on that at all? I realise that Zepto covers a (very) small subset of jQuery functions, but I thought that in a lot of use cases it would be an appropriate substitute?
It doesn't normalize DOM events, which is a big one for many people.
Last I checked zepto doesn't have support for any of the simulated selectors like `:checked`, `:input` and friends. If you use any of them, its not drop in.
If you build zepto with experimental CSS selectors you can. https://github.com/madrobby/zepto/blob/master/src/selector.j...
That doesn't list IE as a supported platform at all (not even the current IE9), so while you should be OK (if IE is now as close to compliant as MS claim it should just work) if you find problems in IE you might be on your own when it comes to researching and fixing them.
See http://zeptojs.com/#platforms - specifically "we may add support for Internet Explorer 10 ... depending ..." and the lack of any mention of IE before 10.
See http://zeptojs.com/#platforms - specifically "we may add support for Internet Explorer 10 ... depending ..." and the lack of any mention of IE before 10.
Kudos to the jQuery team for taking a risk.
it's not their risk, it's ours.
It isn't your risk. You can continue to use jQuery 1.x.
Is it? There are other JavaScript libraries available, and 1.9 will still support IE.
Sorry, but this is a disaster.
Dropping support for IE6 may be OK, IE7 is a bit too soon, but IE8?
I haven't tested my stuff on IE6 and IE7 for a long time, but I still do it on IE8 everyday. It was released in 2009! And it's decent enough, PNG transparencies, etc.
jQuery's main raison d'être might have gone out the window.
I haven't tested my stuff on IE6 and IE7 for a long time, but I still do it on IE8 everyday. It was released in 2009! And it's decent enough, PNG transparencies, etc.
jQuery's main raison d'être might have gone out the window.
The premise is that jQuery 1.9 and 2.0 are API-compatible, so you can do something like:
<!--[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]-->
We deal with enough conditionals already. Besides, sharing the same API won't stop you from bumping into some bug that's present in one version and not the other.
We'll have to deal with two codebases.
Download and runtime speed are not a problem on the Desktop.
They should have had the guts to admit that this is all about mobile. Their denial at the end of the post is symptomatic.
We'll have to deal with two codebases.
Download and runtime speed are not a problem on the Desktop.
They should have had the guts to admit that this is all about mobile. Their denial at the end of the post is symptomatic.
> We'll have to deal with two codebases.
You already have to deal with two codebases, IE8 and IE9. One can have bugs that the other doesn't.
Right now, you deal with:
* IE8 + jQuery 1.9 * IE9 + jQuery 1.9
I assume you are testing both? If so, then all you will have to do is instead test:
* IE8 + jQuery 2.0 * IE9 + jQuery 2.0
You already have to deal with two codebases, IE8 and IE9. One can have bugs that the other doesn't.
Right now, you deal with:
* IE8 + jQuery 1.9 * IE9 + jQuery 1.9
I assume you are testing both? If so, then all you will have to do is instead test:
* IE8 + jQuery 2.0 * IE9 + jQuery 2.0
Will running functional tests help?
Download and runtime speed are definitely a problem on desktop OSes -- mobile broadband, slow DSL, netbooks, that sort of thing.
If you don't like conditionals, then don't use them. Stick with 1.9 or 1.8
Download and runtime are absolutely a problem on the desktop. There will always be a decent amount of people on unreliable connections and mobile devices with slow processors
Download and runtime are absolutely a problem on the desktop. There will always be a decent amount of people on unreliable connections and mobile devices with slow processors
>Stick with 1.9 or 1.8
That's a terrible solution.
>unreliable connections and mobile devices with slow processors
Which are not Desktops, so I don't see your point.
That's a terrible solution.
>unreliable connections and mobile devices with slow processors
Which are not Desktops, so I don't see your point.
Why is it a terrible solution? What jQuery API features (that might be developed in 2.x) are missing that you need? The current API fulfils the purpose of the jQuery Project; many of the recent API changes have been syntactic sugar changes and I imagine most future ones will be as well.
>Which are not Desktops, so I don't see your point Oops... Well anyway, I know plenty of people who cannot get DSL or cable in their area and rely on spotty wireless connections
>Which are not Desktops, so I don't see your point Oops... Well anyway, I know plenty of people who cannot get DSL or cable in their area and rely on spotty wireless connections
> Download and runtime speed are not a problem on the Desktop.
When I'm stuck in the wilderness with nothing but an atom based netbook tethered to a patchy and expensive GPRS connection, I beg to differ.
Anyway, it isn't just about your bandwidth to your desktop - if each user is transferring less it can be significant for the server-side.
If they make proper efforts to maintain 1.9.x for a goodly amount of time the "hitting a bug in one version but not the other" issue shouldn't be more significant than the current "hitting a bug in a third party library (jQuery) which I don't have the expertise to locate+fix" issue that we already have to consider. Of course the "if" at the start of that sentence could be cause for concern but I think the jQuery project has done well enough at QA in the past for me to give them the benefit of the doubt (or at least to reserve judgment) at this point.
When I'm stuck in the wilderness with nothing but an atom based netbook tethered to a patchy and expensive GPRS connection, I beg to differ.
Anyway, it isn't just about your bandwidth to your desktop - if each user is transferring less it can be significant for the server-side.
If they make proper efforts to maintain 1.9.x for a goodly amount of time the "hitting a bug in one version but not the other" issue shouldn't be more significant than the current "hitting a bug in a third party library (jQuery) which I don't have the expertise to locate+fix" issue that we already have to consider. Of course the "if" at the start of that sentence could be cause for concern but I think the jQuery project has done well enough at QA in the past for me to give them the benefit of the doubt (or at least to reserve judgment) at this point.
>When I'm stuck in the wilderness with nothing but an atom based netbook tethered to a patchy and expensive GPRS connection, I beg to differ.
Who cares about outliers like that? How many people using your webpage are connecting like that? 1%? 0.1%? Less? Are you really going to make major decisions based on 0.1% of your users?
And what's more, if you're building a website for that kind of usage, you probably shouldn't be using a big javascript library in the first place. And the people on those connections should experiment with scriptblocking and selective script whitelisting so they're in control of their poor connection.
Know your audience, I think, is the most important factor when deciding how to go forward.
Who cares about outliers like that? How many people using your webpage are connecting like that? 1%? 0.1%? Less? Are you really going to make major decisions based on 0.1% of your users?
And what's more, if you're building a website for that kind of usage, you probably shouldn't be using a big javascript library in the first place. And the people on those connections should experiment with scriptblocking and selective script whitelisting so they're in control of their poor connection.
Know your audience, I think, is the most important factor when deciding how to go forward.
>When I'm stuck in the wilderness with nothing but an atom based netbook tethered to a patchy and expensive GPRS connection, I beg to differ.
That's not a Desktop. That's a cellphone conection and processing power that, by todays standards, reassembles a phone more than a laptop.
But even on mobible, latency is a much bigger problem than file size.
>"hitting a bug in one version but not the other" issue shouldn't be more significant than the current "hitting a bug in a third party library (jQuery) which I don't have the expertise to locate+fix" issue that we already have to consider.
All things being equal, you have twice as many chances of hitting a bug with two code bases than with one.
That's not a Desktop. That's a cellphone conection and processing power that, by todays standards, reassembles a phone more than a laptop.
But even on mobible, latency is a much bigger problem than file size.
>"hitting a bug in one version but not the other" issue shouldn't be more significant than the current "hitting a bug in a third party library (jQuery) which I don't have the expertise to locate+fix" issue that we already have to consider.
All things being equal, you have twice as many chances of hitting a bug with two code bases than with one.
I can think of a lot of reasons this approach won't work well for most of the sites I work on (other than a few blogs).
1) Combining jQuery with other JavaScript at build time (to reduce HTTP requests). At built-time, we don't know which browser they're using. We'll end up with two assets (the combined version w/ jQuery 1.9 and the combined version w/ jQuery 2.0).
2) Testing costs. For larger sites it's not a trivial thing to test and support two different versions of jQuery. For any site that still needs to support IE8 (and 7 and 6), it will not be feasible to test and support two different versions of jQuery. As such, we'll never get the benefits of using jQuery 2.0 and would not be able to do so for many years.
3) Plugins will be written that only work for one of the two versions (1.9 or 2.0). This will divide the plugin ecosystem. Ideally, plugins should work for both, but many people will only test and support their plugins on one of the versions.
1) Combining jQuery with other JavaScript at build time (to reduce HTTP requests). At built-time, we don't know which browser they're using. We'll end up with two assets (the combined version w/ jQuery 1.9 and the combined version w/ jQuery 2.0).
2) Testing costs. For larger sites it's not a trivial thing to test and support two different versions of jQuery. For any site that still needs to support IE8 (and 7 and 6), it will not be feasible to test and support two different versions of jQuery. As such, we'll never get the benefits of using jQuery 2.0 and would not be able to do so for many years.
3) Plugins will be written that only work for one of the two versions (1.9 or 2.0). This will divide the plugin ecosystem. Ideally, plugins should work for both, but many people will only test and support their plugins on one of the versions.
It will be very difficult to develop a plugin for 2.0 that won't work on 1.9 - they will be 100% API compatible, and pass the same set of unit tests.
You do realize that IE 10 dropped conditional comments, right?
If you look at the second conditional comment, it will not be parsed as a comment in browsers without conditional comment support.
In other words, it will correctly use jQuery 2.0, like any other browser without conditional comment support.
In other words, it will correctly use jQuery 2.0, like any other browser without conditional comment support.
It's a conditional conditional comment. I feel ill.
It's known as a downlevel revealed conditional comment. You will see it in use in the HTML5 boilerplate. That said, I echo your sentiment, it is an immensely horrid syntax. For more info: http://css-tricks.com/downlevel-hidden-downlevel-revealed/
[deleted]
You do realize that IE 10 will be supported by jQuery 2.0, right?
You do realize that saying "you do realize, right" is about the rudest and most condescending way to pass on information, right?
[deleted]
Elegant solution, but it's not possible if you bundle/minify all your scripts in one giant file, as more and more do.
It is only not possible if you are incapable of changing your build script.
>[IE8] was released in 2009!
Yep, it's ancient. Chrome and Firefox are on average about 3 weeks old. IE8 is over 50 times older.
>jQuery's main raison d'être might have gone out the window.
Normalization was just one part. It still provides a much nicer API. There are also events, AJAX, effects, and some useful helpers.
Yep, it's ancient. Chrome and Firefox are on average about 3 weeks old. IE8 is over 50 times older.
>jQuery's main raison d'être might have gone out the window.
Normalization was just one part. It still provides a much nicer API. There are also events, AJAX, effects, and some useful helpers.
[].slice.call(document.querySelectorAll('p')).forEach(function (el) {console.log(el);});
$('p').each(function () {console.log(this);});Agreed, [].slice.call is show-offy and pointless. Array.prototype.slice.call is the way to go.
I hope you realize that by saving yourself a few characters you've sacrificed an unknown amount of performance from your site. For such a simple query I'd use getElementsByTagName instead.
I hope you realize that by saving yourself a few characters you've sacrificed an unknown amount of performance from your site. For such a simple query I'd use getElementsByTagName instead.
>Array.prototype.slice.call is the way to go.
The point was to demonstrate that the API is somewhat flawed since it doesn't return something usable. The "clever" short version was used to show that you have to write quite a bit more code - even if you make it really ugly.
>For such a simple query I'd use getElementsByTagName instead.
It's a generic example. The selector was kept short and simple for the sake of brevity.
The point was to demonstrate that the API is somewhat flawed since it doesn't return something usable. The "clever" short version was used to show that you have to write quite a bit more code - even if you make it really ugly.
>For such a simple query I'd use getElementsByTagName instead.
It's a generic example. The selector was kept short and simple for the sake of brevity.
Good point.
BTW that could be written like this:-
BTW that could be written like this:-
[].forEach.call(document.querySelectorAll('p'), function (el) { console.log(el); });Array.prototype.forEach didn't arrive in IE until 9, so if the point is that you can do anything that jquery can do, this won't work.
huh? Might want to check the comment I was replying to.
"jQuery's main raison d'être might have gone out the window." - my thoughts, exactly!
I'm not sure I see the issue here. If someone convinced me that jQuery 2.1+ will get great new features (not available for those forced to use 1.9) then maybe I'd feel differently. What's more likely is that innovation on 2.+ versions will be specific to modern browser features not supported by IE <= 8 anyway. If feature envy hit critical mass, I'm sure there'll be a new OSS project to port these features anyway. Also, months/years from now when Chrome 30 is released (for example), these 1.9ers will still have a library that supports both Chrome 30 and IE6! Maybe jQuery is a lib that has hit its API and performance limits for IE <= 8.
The app I work on dropped IE7 a year ago, and is dropping IE8 in January 2013. Therefore this is the opposite of a disaster, pretty timely actually.
They're pretty clear that 1.9 and 2.0 will have API compatibility so there is an option for those who still have to support oldIE and one for those who don't have to. Seems like the best possible arrangement.
They're pretty clear that 1.9 and 2.0 will have API compatibility so there is an option for those who still have to support oldIE and one for those who don't have to. Seems like the best possible arrangement.
API comparability does not ensure functional comparability. Two code bases too.
Unless users of oldIE versions contribute more revenue than it takes to support them (which is obviously app/site-specific), screw them. It's simple economics.
I don't disagree with you one bit. This will vary for each company depending on industry, the average browser of the target market, and the price-point for the product.
More the reason I think jQuery could be shooting itself in the foot. Its ubiquity is based on the fact that if you're doing client side javascript, jQuery is the best option. Coupled with what I started this comment with - its possible that jQuery isn't the best option for everyone anymore.
I personally am not a huge fan of frameworks. Too often I see people solving problems by adding frameworks. Maybe I'm just a crusty guy who doesn't use a lot of tools.
More the reason I think jQuery could be shooting itself in the foot. Its ubiquity is based on the fact that if you're doing client side javascript, jQuery is the best option. Coupled with what I started this comment with - its possible that jQuery isn't the best option for everyone anymore.
I personally am not a huge fan of frameworks. Too often I see people solving problems by adding frameworks. Maybe I'm just a crusty guy who doesn't use a lot of tools.
> IE7 is a bit too soon, but IE8?... It was released in 2009!
That's old!
When JQuery 1.9 is released in 2013 it'll be four years old. Windows XP is eleven years old and will be end of lifed in early 2014. At what point will you pull the pin?
I think this is a good roadmap for phasing out Old IE support. It's not like they're yanking the rug out from under you - 1.9.x will be around for a while yet.
That's old!
When JQuery 1.9 is released in 2013 it'll be four years old. Windows XP is eleven years old and will be end of lifed in early 2014. At what point will you pull the pin?
I think this is a good roadmap for phasing out Old IE support. It's not like they're yanking the rug out from under you - 1.9.x will be around for a while yet.
You realize IE8 is the default browser that shipped with Windows 7, right?
I fail to see your reasoning. IE6 was (I believe) the default in Windows XP, which people are still using. Should we demand that JQuery support every default browser on every default OS until they're all end-of-lifed?
What, nobody uses Windows update?
yes, a lot of people (generally the people who don't know what a browser is) don't. Also IE8 is the last available browser on winXP.
Oh come on - this is voted down?
Firefox and Chrome do automatic updates, and almost never has issues. That's because they stick to standards in an open and transparent manner. Why wouldn't Windows Update be able to do the same thing? Are the Microsoft software developers really that bad that they can't do what the Chrome and Firefox developers can do already?
Firefox and Chrome do automatic updates, and almost never has issues. That's because they stick to standards in an open and transparent manner. Why wouldn't Windows Update be able to do the same thing? Are the Microsoft software developers really that bad that they can't do what the Chrome and Firefox developers can do already?
This grates me.. I'm sure the MS devs are more than capable of doing what Chrome / Firefox "do already".
This looks far more likely to be a political decision to avoid whatever backlash even a single failed update would produce.
Help, i've lost all 93 of my open tabs..
This looks far more likely to be a political decision to avoid whatever backlash even a single failed update would produce.
Help, i've lost all 93 of my open tabs..
Sure most people do
It makes more sense to use the dates they were superseded, than to use the dates when they came out. Most new computers were still shipping Windows XP until Windows Vista came out in 2007. That's just over five years ago.
jQuery was never good at this. When I first used it on a project they had already drooped support for Safari 1.x, despite that being available version of Safari available for Mac OS X 10.4.
I was, at the time, living with my girlfriend and a friend of hers, both of whom used 10.4 and Safari 1.x: it was honestly quite common among people who couldn't quite afford new computers.
Regardless, when we sent the demo of our product for the local school district I was getting reports that the entire browser was crashing, which I traced down to some sketchy code in jQuery that had been tested so poorly on this version of Safari that no one noticed this highly fatal error.
When I reported the issue to a major jQuery contributor (a friend of mine), all I got was flak that people shouldn't be using that browser and should upgrade to 10.5... obviously I have never used jQuery in a project again.
I was, at the time, living with my girlfriend and a friend of hers, both of whom used 10.4 and Safari 1.x: it was honestly quite common among people who couldn't quite afford new computers.
Regardless, when we sent the demo of our product for the local school district I was getting reports that the entire browser was crashing, which I traced down to some sketchy code in jQuery that had been tested so poorly on this version of Safari that no one noticed this highly fatal error.
When I reported the issue to a major jQuery contributor (a friend of mine), all I got was flak that people shouldn't be using that browser and should upgrade to 10.5... obviously I have never used jQuery in a project again.
> When I first used it on a project they had already drooped support for Safari 1.x
Which was a perfectly sensible decision from a developer POV considering how bad Safari's JS and DOM support was until 3.x
> despite that being available version of Safari available for Mac OS X 10.4.
10.4 was released with Safari 2.0 and got updates up to 4.1.3. Are you talking about 10.3?
Which was a perfectly sensible decision from a developer POV considering how bad Safari's JS and DOM support was until 3.x
> despite that being available version of Safari available for Mac OS X 10.4.
10.4 was released with Safari 2.0 and got updates up to 4.1.3. Are you talking about 10.3?
I simply cannot agree with you on this one; in my book, it is not in any way a perfectly sensible decision to make a browser that a ton of people were still using entirely crash when webpages using the library were opened.
The project I was working on was the kind of thing that probably had just a couple hundred people (if that, maybe even less) visit it during our testing period, and I got multiple reports of that crash.
If you want to popup a dialog box on these devices that says "I'm sorry, you are not supported" that's fine, but if it isn't even being on a browser like that, then no: it becomes entirely correct to point out that it was never actually good at handling cross-browser compatibility issues.
The project I was working on was the kind of thing that probably had just a couple hundred people (if that, maybe even less) visit it during our testing period, and I got multiple reports of that crash.
If you want to popup a dialog box on these devices that says "I'm sorry, you are not supported" that's fine, but if it isn't even being on a browser like that, then no: it becomes entirely correct to point out that it was never actually good at handling cross-browser compatibility issues.
What have you been using instead?
Just FYI saying "main raison d'être" is redundant.
It's a little like saying "the main sole goal of your existence".
It's a little like saying "the main sole goal of your existence".
IE8... released in 2009
Microsoft is the only major browser vendor to believe that a 3-year-old browser is acceptable on a supported OS (XP). Google, Mozilla, Apple, Opera support XP with their latest browsers.
I agree it's too soon to drop support for IE8, but I'd love to see more pressure put on MS for leaving XP+IE users stuck with a second rate browser.
Microsoft is the only major browser vendor to believe that a 3-year-old browser is acceptable on a supported OS (XP). Google, Mozilla, Apple, Opera support XP with their latest browsers.
I agree it's too soon to drop support for IE8, but I'd love to see more pressure put on MS for leaving XP+IE users stuck with a second rate browser.
Yea, MS has in general never released new versions of IE for a version of Windows that entered extended support, and the extended support phase lasts for five years!
How is this "dropping support" for old IE? They've said the 1.9 branch will still receive bug fixes for a while. I doubt they'll leave the 1.9 branch behind (in regards to new API features) until IE8 gets close to IE6's current market share.
What do you mean dropping IE8 support? The jQuery Core team still supports IE 6, 7, and 8, and has not announced that they are dropping it. That's what jQuery 1.9 is about.
I'll play the cynic here and try to diagnose why this is even being considered.
jQuery is a very invasive API. Its goal is to steal all the work from the developer, and to "guarantee" what it deems to be "correct" input for a certain subset of browsers. This approach may ostensibly work, but inevitably falls apart, which leads to thousands of "bugs" being reported.
Because the API has grown to be so massive, goalposts "must" be moved in order to create a lighter API. Once again, this is because of a design flaw. Goalposts will continue to be moved in cyclical fashion unless an alternative design is used. Fellow developers may denigrate me for it, but I will explain how this problem can be avoided.
An API that tries to cater to everyone cannot and will not succeed. This is evidenced by the upcoming "fork". Conversely, an API that provides a set of tools to developers without catering can work in many environments. The burden is then placed upon the developer to choose which environments matter. As has been outlined by mobile developers, object inferences for IE 6 really are unnecessary for mobile Webkit environments. I have written here on this concept before, mostly on the topic of "graceful degradation". Browser specificity can and will kill a client-side API.
jQuery is a very invasive API. Its goal is to steal all the work from the developer, and to "guarantee" what it deems to be "correct" input for a certain subset of browsers. This approach may ostensibly work, but inevitably falls apart, which leads to thousands of "bugs" being reported.
Because the API has grown to be so massive, goalposts "must" be moved in order to create a lighter API. Once again, this is because of a design flaw. Goalposts will continue to be moved in cyclical fashion unless an alternative design is used. Fellow developers may denigrate me for it, but I will explain how this problem can be avoided.
An API that tries to cater to everyone cannot and will not succeed. This is evidenced by the upcoming "fork". Conversely, an API that provides a set of tools to developers without catering can work in many environments. The burden is then placed upon the developer to choose which environments matter. As has been outlined by mobile developers, object inferences for IE 6 really are unnecessary for mobile Webkit environments. I have written here on this concept before, mostly on the topic of "graceful degradation". Browser specificity can and will kill a client-side API.
So does this mean that there will be ongoing development in the 1.9 line which will add new features available in the 2.0 line, or is this just the end of the line for IE <= 8? The blog seems to imply the latter, and that 1.9.x is only going to be used for bug/security updates, without new functionality.
If that's true, this seems like an odd line in the sand for them to draw. IE9 isn't available before Win7, so it can't die until users upgrade their OS.
According to StatCounter[1], IE8 still represents 13.78% of Worldwide visits (plus 1.4% for IE7; IE6 is just part of 'other' now), and 14.92% of North America (IE7; 1.79%).
[1] http://gs.statcounter.com/#browser_version-ww-monthly-201206...
If that's true, this seems like an odd line in the sand for them to draw. IE9 isn't available before Win7, so it can't die until users upgrade their OS.
According to StatCounter[1], IE8 still represents 13.78% of Worldwide visits (plus 1.4% for IE7; IE6 is just part of 'other' now), and 14.92% of North America (IE7; 1.79%).
[1] http://gs.statcounter.com/#browser_version-ww-monthly-201206...
IE9 is available for Vista too. It's not available more crucially for XP, but XP is EOL in April 2014, which is within the timeframe for 1.9.x and 2.x to remain API compatible.
I don't know if I can get behind this or not. I understand their desire but I don't see this as a viable option just yet. I'm not so concerned with 2.0 and 1.9 as you can load the right one, but what about when 2.1 comes out? Are they going to back-port all the new features to 1.9.1? If not then I now have a big fragmentation issue if I rely on anything specific to 2.1.
Don't forget that IE 8 is the last version XP will get and XP is going to be out there for a long time yet (sadly), especially in corporate environments. Effectively (as far as IE only environments are concerned) JQuery has just set a time limit on proper web access for an entire OS.
Don't forget that IE 8 is the last version XP will get and XP is going to be out there for a long time yet (sadly), especially in corporate environments. Effectively (as far as IE only environments are concerned) JQuery has just set a time limit on proper web access for an entire OS.
> JQuery has just set a time limit on proper web access for an entire OS.
What time limit? The blog post says jQuery 1.9 will be supported even after 2.0 is released, and that the two APIs will be the same.
What time limit? The blog post says jQuery 1.9 will be supported even after 2.0 is released, and that the two APIs will be the same.
If you look further into my comment you'll see I mention when 2.1 comes out. I doubt they will be back-porting 2.1 features into 1.9, and thus the time limit.
The plan is if we ever release a 2.1 to backport what makes sense to a 1.10 if the oldIE's are still a big enough market share.
I'd also like to point out that this concern only comes into play 2 years from now. We are not intending to drop support for oldIE forever, but we do want to make jQuery smaller and as efficient as possible in the newer browsers, and leaving all the oldIE code in as we progress past these browsers wastes time.
I'd also like to point out that this concern only comes into play 2 years from now. We are not intending to drop support for oldIE forever, but we do want to make jQuery smaller and as efficient as possible in the newer browsers, and leaving all the oldIE code in as we progress past these browsers wastes time.
Only if you can't live without some feature in 2.1 and can't backport it yourself.
What jQuery 2.1 feature can't you live without?
What jQuery 2.1 feature can't you live without?
I agree, I can understand IE6 since not even ms supports it anymore but 7 and 8? Seems a bit drastic to me.
This flat-out does not make sense. We all may hate IE6, 7, and 8, but a vast number of people still use it, and leaving them out just means alienating an audience and customers. Why do it? Spite?
Because removing all of the special case code paths in jQuery 2.0 will inevitably remove bytes from the library, allow us to use newer browser features with less polyfills, and increase performance for modern browsers. Read the post, we are not "dropping support" - 1.9 is going to be API compatible with 2.0.
The cycle here is pretty long:
jQuery 2.0 will be released in "Early 2013". For some time (probably at least 6 months if not longer), jQuery 1.9 and 2.x will be perfectly API compatible. That means that the conditional comment approach will work with very little downside.
That gets us to summer or Fall 2013. At this point, there may be a release of jQuery 2.1. According to the blog post, it will probably contain few new features, and some speed improvements. It will almost certainly not break backwards API compatibility. At this point, you can upgrade to jQuery 2.1 for the speed improvements and simply not use the new features. The conditional comment approach will still work.
That gets us to Spring 2014. At this point, Microsoft will EOL Windows XP. It's frankly hard for me to imagine more than a tiny number of Windows XP users using IE8 at this point. There was a lot of similar-sounding concern about IE6, which has mercifully vanished. IE8 was at 30% last November; it is now down to 15%.
Even at this point, a jQuery 2.2 will likely not break API backwards compatibility. If IE8 clingers are more stubborn than we expect, we can always modify the strategy to be more aggressive about strict compatibility between the branches.
Unfortunately, many of us are still fighting the last war, where the cutting edge (IE6->IE7) was plodding and the slow upgrading tail was huge. It's time that we acknowledged that the ecosystem has changed: the slow upgrading tail grows smaller all the time, as the cutting edge absorbs more of the mindless browser population. At the same time, the pace of the cutting edge grows faster and faster. We aren't quite there yet, but we should prepare for a future that is not a simple clone of the 2004-2008 era of browser development.
jQuery 2.0 will be released in "Early 2013". For some time (probably at least 6 months if not longer), jQuery 1.9 and 2.x will be perfectly API compatible. That means that the conditional comment approach will work with very little downside.
That gets us to summer or Fall 2013. At this point, there may be a release of jQuery 2.1. According to the blog post, it will probably contain few new features, and some speed improvements. It will almost certainly not break backwards API compatibility. At this point, you can upgrade to jQuery 2.1 for the speed improvements and simply not use the new features. The conditional comment approach will still work.
That gets us to Spring 2014. At this point, Microsoft will EOL Windows XP. It's frankly hard for me to imagine more than a tiny number of Windows XP users using IE8 at this point. There was a lot of similar-sounding concern about IE6, which has mercifully vanished. IE8 was at 30% last November; it is now down to 15%.
Even at this point, a jQuery 2.2 will likely not break API backwards compatibility. If IE8 clingers are more stubborn than we expect, we can always modify the strategy to be more aggressive about strict compatibility between the branches.
Unfortunately, many of us are still fighting the last war, where the cutting edge (IE6->IE7) was plodding and the slow upgrading tail was huge. It's time that we acknowledged that the ecosystem has changed: the slow upgrading tail grows smaller all the time, as the cutting edge absorbs more of the mindless browser population. At the same time, the pace of the cutting edge grows faster and faster. We aren't quite there yet, but we should prepare for a future that is not a simple clone of the 2004-2008 era of browser development.
At the same time, the pace of the cutting edge grows faster and faster.
It better grow pretty fast. By late 2012, jQuery will still be supporting a browser released in 2001 but by early 2013 it won't support a browser that was only replaced by MS in 2011.
Corporate America is not IE8's only domain. There are a lot of people who don't even know what a browser is. And IE8 was the default browser on Windows 7.
It better grow pretty fast. By late 2012, jQuery will still be supporting a browser released in 2001 but by early 2013 it won't support a browser that was only replaced by MS in 2011.
Corporate America is not IE8's only domain. There are a lot of people who don't even know what a browser is. And IE8 was the default browser on Windows 7.
You're comparing apples to oranges. A more correct assertion: By late 2012, jQuery will still be supporting a browser replaced by MS in 2006 but by early 2013 it won't support a browser that was only replaced by MS in 2011.
It's still a valid point, but comparing release dates with replacement dates just hurts the whole argument.
It's still a valid point, but comparing release dates with replacement dates just hurts the whole argument.
You are right.
Probably the best way would have been: By late 2012, jQuery will still be supporting a browser released in 2001 but by early 2013 it won't support a browser that was released in 2009.
Probably the best way would have been: By late 2012, jQuery will still be supporting a browser released in 2001 but by early 2013 it won't support a browser that was released in 2009.
jQuery 1.x supports all Microsoft browsers released over the past 11 years, while jQuery 2.x will only support Microsoft browsers released a little over a year before today.
I think it is MS's fault for taking years to speed up pace of browser development. DOM2 (important for jQuery) and XHTML are at least 10 years old now, and both are not supported by IE8 and took until IE9 to support.
You know what? At this point I'm not sure it's worth catering to people who "don't even know what a browser is."
They've had nearly 20 years to hop on the bandwagon and start understanding this crazy "internet" thing, and they haven't. A person that behind the times isn't going to buy anything on the internet anyway.
They've had nearly 20 years to hop on the bandwagon and start understanding this crazy "internet" thing, and they haven't. A person that behind the times isn't going to buy anything on the internet anyway.
>A person that behind the times isn't going to buy anything on the internet anyway.
Do you actually have some data to back that up? Because all the data I've seen says the exact opposite to what you are saying.
Do you actually have some data to back that up? Because all the data I've seen says the exact opposite to what you are saying.
Looots of people shopping at work using the corporate-standard browser.
1. You can buy things even if they're taxed. 2. You can buy things from places that are not kogan.
And when more places start doing this, or quietly dropping support for IE6, 7 and 8? People are going to start clamoring to be able to install a decent browser.
I am extremely skeptical that more places will start imposing an IE tax. It's simply too unfriendly toward customers. And rational people drop browser support based on usage stats, because it's a cost-benefit decision, which means that this clamoring will never happen.
A person that behind the times isn't going to buy anything on the internet anyway
I just had my largest ever budget approved by someone who uses IE8 at home in 1024x768 resolution. Not that this proves anything, but only goes to show that money is not always where you think it is.
Besides, visitors may interest you in ways other than making a sell.
I just had my largest ever budget approved by someone who uses IE8 at home in 1024x768 resolution. Not that this proves anything, but only goes to show that money is not always where you think it is.
Besides, visitors may interest you in ways other than making a sell.
That works fine for your blog, but what percentage of customers are you willing to turn away from your web business?
I the cost of maintaining apps exceeds their value as customers, then they're going to lose support. Don't forget supporting these old broweres isn't free, cheap, or easy.
That's so much BS. Like supporting old browsers is that hard/expensive.
Everyone keeps saying that, but I have never ever seen numbers to back it up.
Letting it all blow up in the user's face is not an option to me. And I do business with publicity agencies, they don't give a fuck about this stuff, as far as they know everyone owns the latest macbook.
Everyone keeps saying that, but I have never ever seen numbers to back it up.
Letting it all blow up in the user's face is not an option to me. And I do business with publicity agencies, they don't give a fuck about this stuff, as far as they know everyone owns the latest macbook.
No, it's not difficult to support oldIE. Single Column, nothing fancy. But the business people don't want that. They want it to look identical in every browser, and the web designers are scared shitless of losing money to tell them different. The problem is that business people don't know that hours of extra work are required to do this. And when they are told they don't care.
There is a simple solution for that, add it to your bill / launch estimates. Every client I have had always understands when you say "It'll cost X to support that, or it'll bump your launch date 2 weeks". They may not understand the technical details but they will understand when you put it in their terms and ask them "Worth it to you or not?"
An old boring website?
No, that isn't that difficult.
Try to do an interactive webap.
No, that isn't that difficult.
Try to do an interactive webap.
Definitely. Something as simple as a bookmarklet can become hell with all the IE-specific rules for cross domain messaging, third party cookies and the like. We're still trying to be IE-compatible but man it does take a hell lot of time.
AFAICT, jQuery is a general purpose library, not one meant to build bleeding edge web apps.
There's different versions of jQuery. If you require a version that supports older browsers, you might not be able to use the bleeding-edge version. The current libraries will continue to work as they always have. There's no reason for newer versions to be limited by outdated browsers. Developers are free to choose the version they want to use.
New versions do not need to be limited by old browsers. Why not build a mutable API? Your browser doesn't support canvas? Oh, too bad, but the Canvas module will just be undefined so you, the developer, can choose what to do with your user.
I'll tell you the numbers. We spend way too much effort trying to make our sophisticated web app work with ie7. The industry demands innovation in ux but it's nearly impossible to provide it when you are writing for 4 browsers. In a lot of cases we struggle for hours on one problem and end up writing a separate implementation for that feature that doesn't perform as well.
Now we have segmentation in experience, help documentation, and support.
It's expensive as fuck.
Now we have segmentation in experience, help documentation, and support.
It's expensive as fuck.
FYI: you didn't mention any numbers like you promised.
Sorry - you are right.
1) 90% of our visual front-end bugs come from IE, sometimes only showing up in certain versions of IE7.
2) Our mac developers either need a license for VMware fusion or multiple boxes/VMs to test IE 7/8/9 which of course behave very differently. Maintaining these boxes, Windows licenses, and VMware licenses adds additional stress to IT, and the context switching for our developers is expensive.
3) For the ones that do run a VM, we've had to upgrade their RAM so they could run the app and the VM at the same time. RAM is cheap, but its still money for each new mac-based frontend developer we have.
4) A lot of our distributed application message passing is actually done through the browser via client-side javascript. This makes it even more of a pain to test since automating this is difficult and expensive (more setup code, and capybara tests), and needs to be run in each supported browser.
1) 90% of our visual front-end bugs come from IE, sometimes only showing up in certain versions of IE7.
2) Our mac developers either need a license for VMware fusion or multiple boxes/VMs to test IE 7/8/9 which of course behave very differently. Maintaining these boxes, Windows licenses, and VMware licenses adds additional stress to IT, and the context switching for our developers is expensive.
3) For the ones that do run a VM, we've had to upgrade their RAM so they could run the app and the VM at the same time. RAM is cheap, but its still money for each new mac-based frontend developer we have.
4) A lot of our distributed application message passing is actually done through the browser via client-side javascript. This makes it even more of a pain to test since automating this is difficult and expensive (more setup code, and capybara tests), and needs to be run in each supported browser.
For 2: Any reason why your developers can't use VirtualBox with the free IE-test VM images that Microsoft provides? I don't know if the license allows them to run on a non-MS OS, but you can at the very least have several of them run on a single box and enable RDP in VirtualBox.
That "single box" needs to be able to support enough instances for our entire development team. This is more hardware and IT maintenance costs. Also, if we are doing network maintenance and wifi goes down, developers have to stop working.
The point is - even that solution costs time and money.
The point is - even that solution costs time and money.
1) Maybe it's a design problem, do you really have to provide the exact same experience to everyone?
2) As others have said, there are "free" (of course, there's a cost in setting up) alternatives.
3) Indeed, we bumped every iMac RAM here as well. It's very cheap, though.
4) Well, not really. Any logical piece of software can (and should) be isolated to run by itself. That's how you unit test them. This is the kind of thing that you build once, test everywhere and stop worrying about it until you have to change the set of features.
My point is: why don't we all serve a lo-fi version of our apps based on the features present in the current agent? This way we can stop worrying about release numbers once and for all. If nothing, it usually result in a more stable code base.
2) As others have said, there are "free" (of course, there's a cost in setting up) alternatives.
3) Indeed, we bumped every iMac RAM here as well. It's very cheap, though.
4) Well, not really. Any logical piece of software can (and should) be isolated to run by itself. That's how you unit test them. This is the kind of thing that you build once, test everywhere and stop worrying about it until you have to change the set of features.
My point is: why don't we all serve a lo-fi version of our apps based on the features present in the current agent? This way we can stop worrying about release numbers once and for all. If nothing, it usually result in a more stable code base.
1) Yes. Our user experience, look and feel, and "funness" is part of the brand experience that we can't compromise. Does Apple compromise?
2) Nothing is free if you are buying more hardware. Considering the costs of supporting Chrome/Firefox are very incremental, doing anything other than running the browser natively increases time and cost.
3) Cheap yes, but you have to do it, and its not like buying one piece of hardware. You have to do it for every person. Better, but not great. No one likes running VMs on their boxes because it still crawls, even with 2 cores and 8GB ram.
4) Don't disagree with you at all. I was against this design decision from the beginning but lost that battle. It doesn't change the fact that we need to test all of it.
2) Nothing is free if you are buying more hardware. Considering the costs of supporting Chrome/Firefox are very incremental, doing anything other than running the browser natively increases time and cost.
3) Cheap yes, but you have to do it, and its not like buying one piece of hardware. You have to do it for every person. Better, but not great. No one likes running VMs on their boxes because it still crawls, even with 2 cores and 8GB ram.
4) Don't disagree with you at all. I was against this design decision from the beginning but lost that battle. It doesn't change the fact that we need to test all of it.
Why not use chrome frame for ie users? If you're building a 'sophisticated web app' then you really are nuts to try to support way back to ie7.
Chrome frame takes about 30-45 sec to DL & install. Doesn't require a browser restart and doesn't require admin rights. Its incredibly slick. and then you're free to work with HTML5 and CSS3 in ie6+
Chrome frame takes about 30-45 sec to DL & install. Doesn't require a browser restart and doesn't require admin rights. Its incredibly slick. and then you're free to work with HTML5 and CSS3 in ie6+
We have no control over whether or not our users use chrome frame. Asking them to install it isn't always an option, especially for government installations.
I dont have any experience developing for govt, so for all I know the barrier against installation of CF may be insurmountable. Have you ever tried? It really is extremely painless and would result in a net + in terms of security.
Definitely insurmountable in the environment of many of our users. They're doctors working with medical data, so IT has to certify anything new installed.
So they're stuck with IE6, because that was the latest & greatest when large custom web-based applications really took off, so they're all certified for IE6 only and would have to be replaced at enormous cost before the users can be allowed to upgrade (or install chromeframe, for example).
It's a big barrier.
So they're stuck with IE6, because that was the latest & greatest when large custom web-based applications really took off, so they're all certified for IE6 only and would have to be replaced at enormous cost before the users can be allowed to upgrade (or install chromeframe, for example).
It's a big barrier.
I beg to differ. It is extremely hard to support so many browsers. Try testing your website on 8 versions of Firefox, 5 versions of Internet Explorer (Mac and PC), 3 versions of Opera and 5 versions of Safari. Ironically, this is what jquery insulates you from to a degree, but at the same time it tends to stifle new features.
We're talking about supporting IE8, not every version of every browser that's ever been made.
Where I work, we support browsers with over 2% of traffic, which means IE7,8,9, Chrome (latest), FF (latest and possibly 3.6 or something like that) and Safari (latest, IIRC, possibly latest + 1 older version.) The last 4 are largely the same, except for small bugs, and minor visual degradation is fine for the IEs. If your work requires you to support every browser, maybe you should start trying to build a case against that by making clear that requiring you to support every browser is a poor business decision.
Where I work, we support browsers with over 2% of traffic, which means IE7,8,9, Chrome (latest), FF (latest and possibly 3.6 or something like that) and Safari (latest, IIRC, possibly latest + 1 older version.) The last 4 are largely the same, except for small bugs, and minor visual degradation is fine for the IEs. If your work requires you to support every browser, maybe you should start trying to build a case against that by making clear that requiring you to support every browser is a poor business decision.
I might have been a little unclear - I'm not currently developing (hope to soon). Of course it depends on your market - if your market is a whole bunch of corporations that have IE8, then use jquery 1.9.x... if 2% of your clients bring in a substantial amount of money and it's worth your while, then by all means develop for them.
But at some point, it becomes a zero-sum game. I believe this is what is happening with jquery: the amount of effort to support new features on older browsers (yes, that includes IE8) becomes less and less of an advantage. Hence their decision to compromise and support two versions of jquery, and have all or most of the new features implemented in the 2.0 version.
But at some point, it becomes a zero-sum game. I believe this is what is happening with jquery: the amount of effort to support new features on older browsers (yes, that includes IE8) becomes less and less of an advantage. Hence their decision to compromise and support two versions of jquery, and have all or most of the new features implemented in the 2.0 version.
I say we all just start defaulting anything that isn't bleeding edge IE to the mobile experience. That'll sort em.
And the users in large institutions who aren't allowed to install or upgrade their browser will just have to suffer if they use your site.
Or they'll go with your competitor.
Obviously, if your users are all home users, this probably isn't a factor. If you want people using your site from the office, it might be.
Or they'll go with your competitor.
Obviously, if your users are all home users, this probably isn't a factor. If you want people using your site from the office, it might be.
For CSS, perhaps you're right. For Javascript, it may only take an extra hour or so to monkeypatch their JS implementations for things like Array.indexOf().
Now many of the things I do involve Canvas and SVG for information display. Try a map of the United States with a few layers of SVG with a few thousand datapoints. It simply won't happen on IE <= 9. You can try all the shims all day long. It just won't work.
Saying "it's not that hard" means you haven't tried anything more than CSS2 box model stuff.
Now many of the things I do involve Canvas and SVG for information display. Try a map of the United States with a few layers of SVG with a few thousand datapoints. It simply won't happen on IE <= 9. You can try all the shims all day long. It just won't work.
Saying "it's not that hard" means you haven't tried anything more than CSS2 box model stuff.
> Like supporting old browsers is that hard/expensive.
OK, make your new website work in Netscape 4.
OK, make your new website work in Netscape 4.
Only you can make that call for your app... But do the math. Don't assume that supporting oldIE is automatically a bad investment.
Ever heard the notion of "opportunity cost"?
You shouldn't assume that everyone with money or education shares all of the same interests as you.
I can't imagine the internet is very useful or fun for those people either. Every other site must be broken in some way. And that's still not enough for them to ask someone about it.
That's what they call "The Internet". They may wonder why everyone else likes it so much, or they like it well enough as they see it that they're not even aware of what they're missing.
I'm not much of a car guy, but I like my car just fine. Someone who's really into cars and has test-driven hundreds of them could probably point out dozens of deficiencies in my car and the way I drive it that I'm totally oblivious to. He might not like my car at all, but I'm happy with it and see no reason to 'upgrade' it.
Same goes for any other product field, hobby, interest, etc. People who are more interested are better acquainted with what's available and the way to get the best experience, and people who are less interested are happy enough with their point of view and oblivious to any short-comings.
I'm not much of a car guy, but I like my car just fine. Someone who's really into cars and has test-driven hundreds of them could probably point out dozens of deficiencies in my car and the way I drive it that I'm totally oblivious to. He might not like my car at all, but I'm happy with it and see no reason to 'upgrade' it.
Same goes for any other product field, hobby, interest, etc. People who are more interested are better acquainted with what's available and the way to get the best experience, and people who are less interested are happy enough with their point of view and oblivious to any short-comings.
it's not always just about buying. having information accessible to people is... generally... a good goal to have.
And MS will technically support IE8 for Win7 with security updates till 2020 for the same reason IE6 on XP is still supported until 2014 (and IE 5.01 on Win2000 was supported until 2010).
>JQuery has just set a time limit on proper web access for an entire OS.
doesnt chrome work on xp?
doesnt chrome work on xp?
People will switch from IE when they have to. Firefox, Chrome, and Opera all run well on XP. As for corporate America, they'll wait it out as long as they can too.
However, if forced, technology departments are quite capable of installing Chrome or Firefox. I don't feel sorry for corporations who have IE[6-8] only apps. I was there 10 years ago when people said that it only had to run in IE, when I said we should test in Firefox too.
However, if forced, technology departments are quite capable of installing Chrome or Firefox. I don't feel sorry for corporations who have IE[6-8] only apps. I was there 10 years ago when people said that it only had to run in IE, when I said we should test in Firefox too.
I've just been told yesterday that a banking/financial software web product we're supposed to use works only on... firefox! actually the guy who said it to me didnt know if it worked on chrome/safari/opera, but he was 99.9% sure it doesnt work on IE (infact they had to deploy firefox everywhere). I was quite surprised, I think the financial sector is not so open to technological changes (I still remember talkin to a large fund corp no more than 5-6 years ago and they had security policies that said that they cannot use VPN (or FTPS/SFTP) on the internet and they must use CDN or ISDN with callerid verification for transferring operations) but if this vendor is still alive, it means that probably its product is good enough to make people install firefox (let me add that it's a tiny vendor for small financial entities, so you wont deploy this kind of software in large banks, but it's still quite odd for that market).
agreed. They'll only replace those systems when the expense of maintaining them is greater than re-writing. I'm 100% in favor of making it increasingly more painful for companies to hold back progress.
I do have to say that my impression from comments that some devs don't actually comprehend the scope of the trouble for some of these companies. On the surface you might think it's just a lazy IT department who won't upgrade the browsers. But really the situation is that companies built their internal infrastructure using things like ActiveX components for IE and these systems are probably more like desktop apps than web-based apps. They use all of the old IE components to interact with the desktop and do things that may still not even be possible with a regular web-based app. So it is not necessarily that they're surfing the web with IE6 because they're too lazy to upgrade the browsers or their javascript code - rather they are stuck with it because they have huge infrastructure that depends on those old components to run. It's hard to actually understand that now, but at the time 15 years ago it was really cutting edge stuff and MS managed to get some serious vendor lock-in.
I do have to say that my impression from comments that some devs don't actually comprehend the scope of the trouble for some of these companies. On the surface you might think it's just a lazy IT department who won't upgrade the browsers. But really the situation is that companies built their internal infrastructure using things like ActiveX components for IE and these systems are probably more like desktop apps than web-based apps. They use all of the old IE components to interact with the desktop and do things that may still not even be possible with a regular web-based app. So it is not necessarily that they're surfing the web with IE6 because they're too lazy to upgrade the browsers or their javascript code - rather they are stuck with it because they have huge infrastructure that depends on those old components to run. It's hard to actually understand that now, but at the time 15 years ago it was really cutting edge stuff and MS managed to get some serious vendor lock-in.
Add in that they may be using these custom apps to handle medical data, or financial data, or something similar that can cost lives or staggering sums of money if a browser upgrade causes even subtle errors... so there's a time-consuming and very costly certification process that must happen even for rewritten software, on top of the cost of development.
And certification would need to happen again before any subsequent browser upgrades.
So I hate supporting IE6, but I'm working in health care, so I'm pretty sure that I'm going to be supporting IE6 for a while yet.
And certification would need to happen again before any subsequent browser upgrades.
So I hate supporting IE6, but I'm working in health care, so I'm pretty sure that I'm going to be supporting IE6 for a while yet.
Don't be silly. There are alternative browsers. XP will not lack proper web access.
Yes, I realize corporate settings can be inflexible enough that it won't happen in some corporations, but isn't it a good thing that corporate IT get more pressure to accomodate?
Yes, I realize corporate settings can be inflexible enough that it won't happen in some corporations, but isn't it a good thing that corporate IT get more pressure to accomodate?
So if the market share report links below are in the ballpark, that is about 60% of IE's current 49% market share, or about 29% of all current browsers. This makes jquery 2 a non-starter. Even using 1.9 is suspect because the questionable decision making process here makes me think I will have more headaches in the future if I stick with jQuery.
IE Market Share: http://bit.ly/LUhxlA
IE Version Market Share: http://bit.ly/LUh9n2
IE Market Share: http://bit.ly/LUhxlA
IE Version Market Share: http://bit.ly/LUh9n2
Interesting way of looking at it. Except that is about 70% of browsers that will work with jquery 2.0. Puts it into perspective!
I'm seeing a lot of hate here, but I think this is a good decision. I know what a pain it is to support older versions of IE because I was doing it before jQuery came onto the scene. They took a lot of that pain from us and hoisted it onto themselves, but we can't expect them to carry that burden forever.
My company dropped IE 7 support months ago, I look forward to the day we can drop IE 8. We'll probably be suck with jQuery 1.9 for a while, but my side projects will start using 2.0 right away.
My company dropped IE 7 support months ago, I look forward to the day we can drop IE 8. We'll probably be suck with jQuery 1.9 for a while, but my side projects will start using 2.0 right away.
Hard to tell whether this will be good or bad; it does bring to mind some of the gyrations commercial software vendors have forced, from time to time.
I think this is a good move from jQuery. Other popular software/services should do it too, and it'll be THE END of awful IE versions.
I still do support IE8 but it is a pain in the ass to have to work around stupid bugs...pseudo elements are not well supported, font rendering is subpar, no css3 support, sloooow JavaScript engine...and I could go on for ever.
I still do support IE8 but it is a pain in the ass to have to work around stupid bugs...pseudo elements are not well supported, font rendering is subpar, no css3 support, sloooow JavaScript engine...and I could go on for ever.
To all the people upset about IE8 being the last browser supported on XP ... Isn't that Microsoft's problem rather than JQuery's? Apparently, Microsoft is not interested in providing a modern Web experience to their users.
I don't really see the problem anyway. JQuery can move forward, and those that want to support IE8 have JQuery 1.9 and I'm sure there will be a cottage industry of people maintaining updates to support IE8 for the next 20 or 30 years. In the meantime, the rest of the world will be able to move on. Perhaps people could even use UserAgents to provide legacy experiences for the IE8 crowd ... multiple views ... what a concept.
I don't really see the problem anyway. JQuery can move forward, and those that want to support IE8 have JQuery 1.9 and I'm sure there will be a cottage industry of people maintaining updates to support IE8 for the next 20 or 30 years. In the meantime, the rest of the world will be able to move on. Perhaps people could even use UserAgents to provide legacy experiences for the IE8 crowd ... multiple views ... what a concept.
But it's not the last. Chrome, FF and Opera works. I can't understand all the whining here. Corporate world can run IE for it's shitty apps and a modern browser for whatever else. Also, that's their problem, not mine, jQuery's or the majority of people that have to download a bloated codebase to support a 3 year old, no standards browser.
For all the "just upgrade" comments:
Internal IT departments have no, no, no incentive to upgrade browsers. "Surfing the internet" is not a reason for IT departments to upgrade.
Internal IT departments have no, no, no incentive to upgrade browsers. "Surfing the internet" is not a reason for IT departments to upgrade.
Yup, a lot of web apps are using ancient versions of JS libraries, aren't compatible cross browser, and updates are few and far between. The issue is with enterprise apps, you really need to have a solid release schedule/plan. If you update an app and say "You are now forced to use a new browser to get the functionality of this." you will piss off a lot of people.
It's much easier for the app developer to create poorly written hacks for the older js libraries, because they are less likely to force a browser requirement change.
For enterprise apps, 1.9 is going to be around for an extremely long time.
It's much easier for the app developer to create poorly written hacks for the older js libraries, because they are less likely to force a browser requirement change.
For enterprise apps, 1.9 is going to be around for an extremely long time.
It's not for enterprise apps.
If your startup is C2C, everything is fine, if your B2C or B2B your in trouble. If your B2X then you even do not have the leverage of a contract etc.
If your startup is C2C, everything is fine, if your B2C or B2B your in trouble. If your B2X then you even do not have the leverage of a contract etc.
Then they will be left in the past. It's unreasonable to expect me to hold my own product back because of lazy corp IT depts.
Unless they are contributing more revenue than it takes to support them, screw them. For me at least, this is not remotely the case and I'm happy to leave them in the dust.
Unless they are contributing more revenue than it takes to support them, screw them. For me at least, this is not remotely the case and I'm happy to leave them in the dust.
So i have to stick with jquery 1.9. People that ask me to create web page are IE user. Here, those who use firefox, opera, or safari can create their own web by themself.
This is worst of both worlds. Compared to naming branches, they both encourage sites to unnecessarily break compatibility, and are held back from developing new features.
They should give 1.9, 2.0, and 2.1 names, and make 2.0 mainline, and call 1.9 "compat" or something and encourage the conditional comments. Then, soon, they should start working on 2.1, which isn't API compatible with a version that's compatible with IE 6/7/8. The current plans for 2.1 are an awfully long time to wait for features that aren't available with IE 6/7/8, for apps and sites that need such things (and have a target audience that is ready for it).
They should give 1.9, 2.0, and 2.1 names, and make 2.0 mainline, and call 1.9 "compat" or something and encourage the conditional comments. Then, soon, they should start working on 2.1, which isn't API compatible with a version that's compatible with IE 6/7/8. The current plans for 2.1 are an awfully long time to wait for features that aren't available with IE 6/7/8, for apps and sites that need such things (and have a target audience that is ready for it).
This is a retarded decision which I do not support.
IE6 fine, IE7 fine but not IE8. IE8 is required for most corporate environments where they haven't killed of Windows XP yet. That is a surprisingly large amount of people.
If this happens, we'll fork jQuery 1.9 and support it separately.
IE6 fine, IE7 fine but not IE8. IE8 is required for most corporate environments where they haven't killed of Windows XP yet. That is a surprisingly large amount of people.
If this happens, we'll fork jQuery 1.9 and support it separately.
2 will come out in 2013 just a bit before Microsoft officially removes all support for XP. If your IT department hasn't made moves to upgrade everyone from XP by this point you have bigger issues to deal with than jQuery availability.
Forced obsolescence doesn't mean people aren't still using it and it doesn't mean that because Microsoft stop patching that it's still vulnerable. Using it after April 2014 is not a problem.
The NHS in the UK has over 1 million Windows XP deployments out there still on NHSnet which is a nationwide secure private WAN. A lot of software vendors have to support that.
Your view is popular but naive.
The NHS in the UK has over 1 million Windows XP deployments out there still on NHSnet which is a nationwide secure private WAN. A lot of software vendors have to support that.
Your view is popular but naive.
Ok how about this then. If you're still supporting an unsupported OS why do you care about using the cutting edge version of a JS library?
Yeah this is exactly the thing. It's not like 1.9 or 1.8 or even 1.4 will stop working in the future when the new versions are released.
I duplicated a project for a client today that needed a one-page form and a two-page admin section, and I have only a couple of hours of budget to make it work. They don't care that it's running jQuery 1.3.x. It's working fine.
I duplicated a project for a client today that needed a one-page form and a two-page admin section, and I have only a couple of hours of budget to make it work. They don't care that it's running jQuery 1.3.x. It's working fine.
Because historically jQuery has been a buggy pos that we've had to work around a lot.
That argument doesn't really hold though. You're not upgrading your base(the OS) to fix the problems with it yet you're complaining about a minor(in the grand scheme of things) library removing support in a modern version. If your network is closed off like the NHS one you mention, why not just stick with the old versions you've already fixed?
It's like complaining your 56' Chevy doesn't work with the new battery technology coming out in the Chevy Volt.
It's like complaining your 56' Chevy doesn't work with the new battery technology coming out in the Chevy Volt.
The problem comes is that the older versions that we've fixed have the fixes integrated in later versions.
We really don't want to have to maintain the versions that we've fixed as that kills the entire value proposition of using it in the first place.
It's nothing like the 56' Chevy / Volt analogy. The technology is the same - they just can't be bothered with supporting one vendor's product any more.
We really don't want to have to maintain the versions that we've fixed as that kills the entire value proposition of using it in the first place.
It's nothing like the 56' Chevy / Volt analogy. The technology is the same - they just can't be bothered with supporting one vendor's product any more.
Why do those fixes matter? Again if you're in a closed environment then you can surely control the versions of a JS library. So fix it until it works in your space then move on. Them dropping support for your outdated choice of platform isn't a problem. Your desire to use cutting edge software with your outdated platform is the problem.
Picking a platform and sticking with it is a nobel and occasionally needed position to have. Expecting everyone else to hold themselves back because you chose to do so is impossibly greedy however.
Picking a platform and sticking with it is a nobel and occasionally needed position to have. Expecting everyone else to hold themselves back because you chose to do so is impossibly greedy however.
Really? That seems a little harsh. It's free, it's open source, and it's made web development hugely more productive for massive numbers of us for the last 5 years or so.
That it has, but it has still been very buggy for us. We use a number of commercial and open source products and it's the worst supported, least reliable of the lot. The developers don't seem to take defect reports seriously, there is no consistency between releases and the plugin ecosystem is like a landfill site (full of poorly written crap with a few gems here and there).
I genuinely wish at this point that we'd written our own smaller, tighter framework. Unfortunately, a huge amount of lock in is present now, so it's a case of trashing it entirely.
I genuinely wish at this point that we'd written our own smaller, tighter framework. Unfortunately, a huge amount of lock in is present now, so it's a case of trashing it entirely.
I wonder if the code would be a bit cleaner if they dropped IE9 and year-old Firefox / Chrome / Safari support too. That would allow them to use new stuff like XMLHttpRequest 2, ECMAScript 5 Strict Mode, Typed Arrays, requestAnimationFrame and CSS transitions / animations.
All this talk about IE usage numbers led me to a website Microsoft made to say goodbye to IE6: http://www.ie6countdown.com/
The site reports that in the US, IE6 has 0.6% market share — relatively nothing. But look over at China: 22.4% of its 500 million Internet users still browse with IE6. Moving forward benefits the Internet as a whole, but the Chinese market is one instance where backward compatibility is important.
The site reports that in the US, IE6 has 0.6% market share — relatively nothing. But look over at China: 22.4% of its 500 million Internet users still browse with IE6. Moving forward benefits the Internet as a whole, but the Chinese market is one instance where backward compatibility is important.
I grew up in China and this is def true. IE6 is still popular in China is because a lot of banks and governments website only works in IE(6). Since banks are state owned, they don't have incentive to compete to make their site better.
I think the only hope is to wait till their computers die and when they install new windows IE6 will be gone.
Jquery does what most open source projects do not. That is providing a clear roadmap with 99% questions answered.
I think there's a key point that hasn't been mentioned yet, that there may just be no need to deliver JavaScript to IE 6-8 at all. A lot of smart devs are already taking a similar approach with CSS, serving up a minimal 'print' stylesheet for oldIE [1] [2].
- If you're using JS for progressive enhancement on an otherwise static site, e.g. form validation, pjax, image carousels, tabs, animations... simply drop that JS for 6-8. Form validation should just round-trip to the server as it has to do anyway, pages should just link normally, other visual enhancements can be dropped. That's the progressive enhancement way after all.
- If you're trying to build a single-page web app for IE 6-8 and this is your reason for wanting jQuery to work, then you're going to find those browsers have JS engines that are incredibly slow and a JS-heavy web app for oldIE is not going to deliver a good user experience even if you get it to 'work'. I think frankly this is an unrealistic goal from the get-go. The pitiful speed of JS on these browsers is something that does seem to be often overlooked.
If you absolutely have to push a single-page web app to a corporate customer stuck on oldIE, Chrome Frame is a very sensible option. This has served us well and we've yet to encounter a customer who complains, as long as you give them plenty of forewarning and explanation. It can be tied down to only trigger on your site, so sysadmins really have nothing to gripe about with respect to FUD about attack vectors etc.
Anyway I'm not saying 'you definitely shouldn't be serving JS to oldIE' I'm just putting it out there as something to consider, as usual in this business there's no single answer.
[1] http://css-tricks.com/ (serves a print stylesheet for oldIE - possibly just IE6 I forget)
[2] http://www.stuffandnonsense.co.uk/blog/about/universal_inter...
- If you're using JS for progressive enhancement on an otherwise static site, e.g. form validation, pjax, image carousels, tabs, animations... simply drop that JS for 6-8. Form validation should just round-trip to the server as it has to do anyway, pages should just link normally, other visual enhancements can be dropped. That's the progressive enhancement way after all.
- If you're trying to build a single-page web app for IE 6-8 and this is your reason for wanting jQuery to work, then you're going to find those browsers have JS engines that are incredibly slow and a JS-heavy web app for oldIE is not going to deliver a good user experience even if you get it to 'work'. I think frankly this is an unrealistic goal from the get-go. The pitiful speed of JS on these browsers is something that does seem to be often overlooked.
If you absolutely have to push a single-page web app to a corporate customer stuck on oldIE, Chrome Frame is a very sensible option. This has served us well and we've yet to encounter a customer who complains, as long as you give them plenty of forewarning and explanation. It can be tied down to only trigger on your site, so sysadmins really have nothing to gripe about with respect to FUD about attack vectors etc.
Anyway I'm not saying 'you definitely shouldn't be serving JS to oldIE' I'm just putting it out there as something to consider, as usual in this business there's no single answer.
[1] http://css-tricks.com/ (serves a print stylesheet for oldIE - possibly just IE6 I forget)
[2] http://www.stuffandnonsense.co.uk/blog/about/universal_inter...
I was just thinking that it Netflix can be sued under ADA for not close-captioning material that didn't provide closed captioning, then someone is eventually going to sue someone for not providing access to a public website via the only browser they can use.
The real losers will probably be the public libraries that provide Internet access, but don't have the resources to afford equipment or manpower to upgrade machines and browsers.
The real losers will probably be the public libraries that provide Internet access, but don't have the resources to afford equipment or manpower to upgrade machines and browsers.
There are so many reasons for using jQuery. Myself, I'm using it for a ton of reasons: speed up development, create more compact and readable code for myself and coworkers, enjoy the huge range of plugins, theming... you name it.
Support for IE-ancient is not on my list. Actually I would love to see it gone, die, disappear, vanish.
Even though jQuery handles most of my cross-browser issues I still have to test and worry, create workarounds and lots of additional code, consider it in my architecture, take care in the design and handle it in the application lifecycle.
I have been looking for and at able framework that DON’T support old browsers. Thank you for not supporting IE-ancient in your 2.+ releases, I will continue using you jQuery!
Even though jQuery handles most of my cross-browser issues I still have to test and worry, create workarounds and lots of additional code, consider it in my architecture, take care in the design and handle it in the application lifecycle.
I have been looking for and at able framework that DON’T support old browsers. Thank you for not supporting IE-ancient in your 2.+ releases, I will continue using you jQuery!