I think what a lot of people are upset about here, is jQuery entered the web development scene as "the library that solved cross-browser compatibility issues". Now while IE 6 is an obvious one to drop, IE 7 is a little tougher, and IE 8 is down right impossible to drop at this time. I understand that jQuery wants to promote a modern framework, but people didn't adopt it for it's fancy features. They adopted it because those fancy features worked the same in every major browser .
The stop gap solution of 1.9 as being parallel to 2.0 but with compatibility, is understandable, but will probably promote distrust in developers who just need a stable cross-platform solution. I think the immediate concern with 1.9, is how long it will continue in parallel with 2.x before being dropped
Sorry if I seem cranky, but did you READ the blog post? jQuery 1.9 supports those browsers and the jQuery team still supports it. Do you have a problem with us supporting a second version that can be smaller, faster, and work in places other than obsolete browsers?
The final 2.0.0 file is 12 percent smaller than the 1.9.1 file, thanks to the elimination of patches that were only needed for IE 6, 7, and 8.
Dropping IE 6, 7 and 8 support for a 12% smaller file size while effectively forking your code base for the foreseeable future is a lousy decision. Increase complexity tremendously for what, 3-4 KB when gzipped?
Actually, it's decreasing complexity and getting a happy side effect of a 12% smaller file. It was probably a mistake to add the file size difference as a benefit, as it has obviously confused a lot of people who appear to have perceived it as a primary design goal.
I'll say the size drop is the primary reason I'm going through having the browser tags for ie lt 9, vs other... even though 3-4K isn't much, that's quite a few packets on mobile (though there is Zepto, it's nowhere near complete enough for a lot of needs).
I'm working on some revamped UI at the moment, and so far the script load (uglified, not gzipped) is around 250K, anything that can get that down imho is a good thing.
The article also says they hoped to remove more, but early android browsers became "the weakest link" instead. Presumably, support for them will be dropped without much fanfare as soon as their market share goes below X %.
Listen, I would be happy to just serve different versions of jQuery for different browsers. This is what's supposed to happen, and Google does it right.
Well, it's an open source community project so the answer is obvious.
1.9 will be supported for as long as people care about to support it.
Do those complaining want to somehow tell the developers what they should be working on? Where does the sense of entitlement come?
Even if the whole core team insists on going 2.0 only at some point (high unlikely), it's not like it needs any highly technical skills for interested people to jump in and maintain 1.9.
Most of the stuff has been stable for ages, and small fixes are easy to add if needed.
> 1.9 will be supported for as long as people care about to support it.
This is what worries me. You only need to spend an hour on HN or Reddit to see that web devs couldn't care less about legacy browsers, even when most businesses need to support them.
I support the decision to fork jQuery, but I too am worried about whether the 1.x branch will continue to be supported, and also whether we'll see people releasing plugins that work well for both versions. It sounds like a 1.9 plugin will largely work on 2.0, and vice versa, but we'll have to see.
>This is what worries me. You only need to spend an hour on HN or Reddit to see that web devs couldn't care less about legacy browsers, even when most businesses need to support them.
As I wrote, even if the whole core team insists on going 2.0 only at some point (high unlikely), it's not like it needs any highly technical skills for interested people to jump in and maintain 1.9.
>I support the decision to fork jQuery, but I too am worried about whether the 1.x branch will continue to be supported,
You worry too much. You can use 1.9. 1.8, 1.7, even 1.6 indefinitely. It's not like they would stop working on old browsers for some reason. I have websites that serve 2-3 jQuery versions behind, and they work just as well in any old and modern browser, including using several plugins (and a matching jQuery UI). So why do you even need to upgrade to 1.9 for the next 3-4 years?
Not to mention they also said they'll release 1.10.
Seriously, people, this is a non problem.
Want to continue supporting IE6?
1) Trust the jQuery team and use 10.9, and eventually, 1.10.
2) Continue using 10.9, 10.8, 10.7 etc indefinitely. They still work on the latest browsers, and of course they will work forever on the older ones.
3) Go in 10.9 and fix any incompatibility you find with the latest browsers yourself. Or wait for someone of the multi-million strong web dev community to do it for you.
Don't get me wrong. I agree with you, and I don't think it's really a problem. Hell, if it is it's not a problem to use both libraries, and to serve 1.x to those using older browsers. It's just a shift in the core mentality of what people view jQuery as.
Many of us use jQuery because it works, regardless of what browser a user is on. For a lot of others, jQuery IS JavaScript. If they want to do something on their site, they look for a jQuery plugin and use that, otherwise in their mind it'll be too much work to get it done. It's depressing, but it's the reality of development.
One point you raise that I do disagree with is:
> Go in 10.9 and fix any incompatibility you find with the latest browsers yourself. Or wait for someone of the multi-million strong web dev community to do it for you.
This is the classic open-source "fuck you with a smile" response. Fixing new functionality is not an attractive problem, and out of the multi-million strong community I can see very few people with both the skills, the time, or the desire to fix these problems, and those that could fix the problems are more likely to wait for someone else to do it.
I'd consider myself fairly handy with JavaScript, but I'm also a very busy man, and my office won't want me spending company time fixing a bug in a plugin if there is another way. Also, there isn't a developer alive that likes fixing legacy bugs. I can think of a million things I'd rather do than fix IE6-7 bugs.
> This is the classic open-source "fuck you with a smile" response.
Since open source is free and open, it really can't fuck you †. You can however screw yourself by relying on it to do your work for you.
As you say, few people have the skills, time and desire to fix these sorts of problems, and that means you can't rely on open source to fix them for you.
Fortunately, there is a simple solution to this called "money" which companies have and which can be given to a developer with the skills who will magically convert that money into the time and desire to fix the problem.
† If your company is willing to use open source, but only when it is perfect, and not willing to help improve it, maybe they are the doing the fucking?
The point is that if you're a company that's relying on an open source project and not contributing back to it then you have no basis to be "fucked" by the project.
Well, I believe the person in question wasn't saying that the project itself was saying "fuck you", but the people answering the response were saying it. The point being that there are too many people that say if you don't contribute then shut the fuck up. But, of course, different people contribute in different ways. Not everyone who uses open source software are developers, and for many of these people the simple fact they use the software is their way of contributing. So when one of these people stand up and say, "I have this problem", the appropriate response is not "contribute or shut the fuck up". This is the response that is being encouraged here. It is irrelevant if the statement about a problem came from an individual or a company. The reason that such a response is a bad idea is that it actively encourages people to not use the software in question. If the goal is to get everyone to stop using open source software, then by all means continue to tell them to fuck off.
There's more than just source code contributions that help an open source project.
Being the lead dev of a fairly well used open source project I can say for certain that too many people I've had interactions with that want a bug fixed or a new feature added do so with entitlement. As if by not doing it they're being told to fuck off.
I may have dramatized it a bit but there's something about software that people feel entitled to get value at no cost.
So, you treat the entire group based on the actions of individuals? Do all the people who use your software behave in this manner? Do you think it's possible that people researching your software will see any of your possible bad behavior (I don't know if you do or not) and decide not to bother?
I never said that someone like you were telling people such things by not doing what they request. I'm describing people who's immediate reaction to almost anything is "only contributors may complain!" and if you don't fit that category then good for you. That means I'm not talking about you.
If someone submits a bug report or feature request that you feel you cannot get to in a timely manner or don't feel is necessary then you can politely explain why. If the person responds to this with an entitled attitude then the problem then lays with that person, not you. If you respond to a bad attitude with a bad attitude then what picture are you painting to everyone else?
It's classic customer service, you are polite to everyone but firm in your decisions. No one says that you must cater to every single person who says anything about your software, but you should be polite in saying no. How you say no provides a much clearer picture of your project than how you say yes.
Agree with all of that except you saying that I'm generalizing. I mentioned it is a subset, but that's the subset I'm talking about. I hope anyone who asks politely will get a polite response.
But the idea of "being fucked" [1] implies some level of entitlement or deserving something.
Providing feedback is very useful for open source projects. But there's a fine line between providing feedback and feeling like you're getting a "fuck you" when it's not implemented or fixed.
[1] > This is the classic open-source "fuck you with a smile" response.
I think at this point we're not agreeing on the terms in use.
When you say someone is "being fucked" by an open-source project I see that as the project itself, or the people on the project, causing a significant problem for the person involved. In fact, I would say that such a strong term means that the the detrimental aspect is likely intentional. The project itself is causing a negative action to that person. This is not what I'm describing.
When I say the response is "fuck you with a smile", there's no detrimental action involved. I see it as a very impolite way of saying no. The person receiving the response can ignore it or choose to go somewhere else, either way there's no real negative action being done to them. All I'm saying is with that response I would assume most people would choose to go somewhere else.
Again, this issue isn't whether someone acts with a sense of entitlement if they complain that their suggestion or bug report isn't implemented. As I said before, if someone whines in that instance then the problem is with them, not the developers. On the other hand, if someone makes a statement along the lines of "this feature doesn't seem to work right", or "this bug prevents me from doing something I want to do", or "it would be nice if this feature was implemented" then responses like "only contributors can complain!" or "learn to code and fix it yourself!" are developers using the "fuck you with a smile" response. I feel that is wrong and not productive in any way. It is actions like this that will push people away from the idea of open-source software because who wants to deal with that nonsense?
>This is the classic open-source "fuck you with a smile" response. Fixing new functionality is not an attractive problem, and out of the multi-million strong community I can see very few people with both the skills, the time, or the desire to fix these problems, and those that could fix the problems are more likely to wait for someone else to do it.
If it was something like a database engine, an obscure language, some network utility, a server, etc, I might have agreed. That is, if it was something esoteric, that needs high skills, and only some very knowledgable of it's internals could adopt it.
But this is jQuery we're talking about. Not rocket science. Lots of guys have the skills and time to fix these problems.
>I'd consider myself fairly handy with JavaScript, but I'm also a very busy man, and my office won't want me spending company time fixing a bug in a plugin if there is another way. Also, there isn't a developer alive that likes fixing legacy bugs. I can think of a million things I'd rather do than fix IE6-7 bugs.
And wouldn't the same exact reasonings apply to the jQuery team? They can also could think "of a million things they'd rather do than fix IE6-7 bugs".
Still, they said the will release 1.10, and support old browsers for as long as needed. If they hadn't released 2.0 that would also be the case. They would support old browsers for as long as needed. The only difference is now they are doing it with two codebases.
That said, your company might not want you "spending company time fixing a bug in a plugin", but for popular plugins there are companies with the money and the resources to have their stuff fix them if the need arises.
I think we'll get a lot less from the open source community if they think they have to support all legacy crap for all time. Eventually there comes a time to move on.
We're just arguing about if its time yet. People can still keep using IE 6/7 for the shitty inhouse apps written for it by their company a decade ago, and use a damn modern browser for everything else.
> People can still keep using IE 6/7 for the shitty inhouse apps written for it by their company a decade ago, and use a damn modern browser for everything else.
You should try working for an agency that handles large clients.
A year ago I was still building pages for an airport that needed to support IE6 to a functional level. We charged a huge number for that support, but this was such a large client that had a proven need for it (analytics and sales data) that they would happily pay several thousand for us to build a section that supported these users. Luckily we left that client, but we still have a number of clients that want IE7 browser support.
I'd like nothing more than to ditch older browsers, but until XP dies many of us will still have to support older browsers. Once XP is gone, the older browsers are gone.
>> A year ago I was still building pages for an airport that needed to support IE6 to a functional level. We charged a huge number for that support
Bravo. What you did was rational, explains why the jQuery team is doing this, and gives you your solution.
You and they both recognize that supporting old browsers is expensive. They're dropping that support. You're charging a lot to deal with it, which incentivizes clients to stop asking for it.
With the extra money you are charging, you can, if necessary, pay someone to fix bugs in jQuery that affect those clients' projects. You can contribute those patches back. Everyone wins.
I understand your emotional response to "losing" support for browsers, but this is not a story of open source failing you. You could have been paying for a proprietary library instead of using jQuery. jQuery has already saved you thousands by being free. You don't get to dictate the project's direction, but you have lots of savings ready to patch it as needed.
> You're charging a lot to deal with it, which incentivizes clients to stop asking for it.
On the contrary, clients couldn't care less about how hard something is for us to do. Sure, if you're working for a creative agency and people are held back by the limitations of what they can accomplish when dealing with IE6 you'll notice a drop in morale, and in the quality of work that is produced, but ultimately the client does not care. Would you care if a plasterer said that plastering your ceiling would cost more because of the materials used? You'd still want it done, because the perceived value far outweighs the cost of doing the work.
Some of my employers' clients are large companies, with fairly large budgets and a good idea of what they want and what they need. As a result, despite charging a lot more for legacy browser development (easily over double, last time I checked) the client is fine with this. If the client believes they are earning £2k a month from IE6/7 users then charging £5k extra for a job that originally cost £2k isn't a problem for them.
> With the extra money you are charging, you can, if necessary, pay someone to fix bugs in jQuery that affect those clients' projects. You can contribute those patches back. Everyone wins.
Absolutely, and on occasion I've been lucky enough to contribute my findings from work to Stack Overflow, or directly to a broken open-source project. Hell, one of my best answers on Stack Overflow was as a result of fixing a problem at work that numerous others appear to have with a certain jQuery plugin.
However, this falls apart if you're working towards deadlines. The client often isn't going to wait very long for you to fix an issue in a product you use, and if they know that you're spending their time and money fixing a bug in a product you use the first thing they'll ask is "why don't you use something that works like [competitor]?". The reality of the situation is, like many others, when working towards a deadline with legacy browsers everything is a hack, and not a hack that we are necessarily proud of. I usually don't care what I publish, because work I'm proud of a few months ago looks inefficient or ugly to me now, and frankly I'm quite happy to have people criticise my code if they offer better solutions, but I'm willing to bet that a lot of people either won't publish their fixes, or would risk their jobs if they were found to be publishing code written on company time. I've worked for companies that would probably flip if they discovered that I had patched a plugin with code that I had written for one of the companies projects.
> I understand your emotional response to "losing" support for browsers, but this is not a story of open source failing you. You could have been paying for a proprietary library instead of using jQuery. jQuery has already saved you thousands by being free. You don't get to dictate the project's direction, but you have lots of savings ready to patch it as needed.
A developers emotions are different to the "emotions" of a company or a client. A developer is more likely to understand the rationale of this decision, whereas a company or a client won't care. All they want is a working product as quickly and as cheaply as possible.
That last one. Given our past record on supporting things you shouldn't be too worried. But if you are, go to our GitHub project and click the Fork button.
Although I am probably just being a stupid person, I really dislike this argument "If you don't like it, fix it yourself".
While it might feel offensive that people are complaining left and right about the new version, it is actually a compliment. I am not trying to be a love-all hippie here, but people are complaining because they really fucking love the solution jQuery put out there to support multiple browsers.
I wouldn't call it "if you don't like it, fix it yourself." I'd call it "you need code that does X? We don't have that, but we have something that does 99.9% of X, and you can have it for free!"
Whereas if they said explicitly "we will support it for 5 more years" how would have changed anything? They can change their minds at any time, and it's not like you can sue them or anything.
Not to mention that the whole question is moot, for reasons I states on my comment above.
How relevant will IE8 be in just two years, though? If it's 3-5 which is what it sounds like, then that's just more of a nail in the coffin for IE8 support.
> How relevant will IE8 be in just two years, though?
That very much depends on your target audience.
For home users IE8 is pretty much dead already, the only subset of people stuck there are the few who are using XP and have not switched to Firefox/Chrome/other. As more and more game-y things on the web start demanding newer features rather than creating/using/supporting fallback options for IE8 (canvas in particular).
In more corporate environments, IE8 is often still king and will be for several years. Most of the clients for the product I spend most of the working day panel beating are large banks and most of them have only just migrated to IE8 from IE6 because they have to soon (IE6 falls out of extended support in less than 12 months, along with XP+sp3). If they follow the same pattern (and I see little reason why they won't, slow moving mammoths that they are) I and many others will have to be concerned about IE8 until at least 2018 as IE8 falls out of extended support in 2020 (as it's support windows are tied to Windows 7's). Hopefully jQuery's idea of "several years" is as least as long as this.
XP falls out of support next year: any bank using it would be going against very strong security guidance from Microsoft.
Once you're on non-antique Windows, there's nothing preventing you from going all the way to IE10 which, again, starts getting into situations where not upgrading for security reasons starts approaching negligence.
But Vista and 7 do not, and you can can run IE8 on them just fine. IE8 itself is supported as long as Windows 7 is, which is Janurary 2020 for the extended support phase.
> Once you're on non-antique Windows, there's nothing preventing you from going all the way to IE10
Nothing. Nothing at all. Unless you consider a large collection of legacy applications that either just plain don't work in anything other than legacy IE or simply haven't been tested (and signed-off as compatible and SLA-covered by the supplier) in anything else.
They can't take the risk of not getting getting those apps thoroughly tested before upgrading and that will cost money (as will any changes, or complete replacemets, needed) and more importantly a huge amount of time (nothing moves quickly inside a bank no matter how hard enthustic and/or concerned people push - organisations of that size have trouble working up the inertia for significant internal changes).
My suggestion has always been to install something else alongside IE and migrate that way: keeping IE around for those applications that require it (or have not been signed-off as working well on something else) but having something better for applications that don't rely on "classic" IE's excetricities. I get funny looks for that suggestion though - the thought of training users to cope with two programs where they once had one seems to trike TS people cold.
> approaching negligence
One of the key drivers working against building up change inertia is fear of neglidence (or accusations there-of). Large organisations have a significan aversion to risk, organisations within regulated industries (where you may do more than fail: you may fail and pick up a hefty fine and/or loss of license along the way) in particular, if they were people you'd probably call them neurotic on the matter. Change without sufficient plannig is a form of negligence, and fear of this is a large part of what adds friction to any forward movement.
Ok, what if my analytics disagree with their analytics? That was my point. Every website's needs will be slightly different than others. The point is that someone saying "I don't need to support browser X" doesn't mean that everyone else can stop supporting browser X.
Did you consider an alternative to major version bumping, e.g. a slightly different name for this fork, such as jQuery-slim ... or a much better name? :-) I think the problem is that 2.0 just implies 'better' to such an extent that a lot of people will be concerned about 1.9's imminent sunsetting.
If you think about it it's like how Microsoft have handled MSIE. They've dropped support for older OS, ie XP and earlier, in IE9 but are still offering support/patches for IE8.
In fact, they actually support all the versions of IE supported on a given Windows version using the lifecycle of that Windows version. I personally have a MSRC case pending against IE7 on XP.
I don't work on jQuery any more but I (and I know many others on the jQuery team) all build web sites as part of their day jobs (and, thus, need to continuing supporting IE 8). It's going to be a very long time before support for the 1.x branch is dropped. But hopefully soon, death of IE 8 willing.
You're missing an important part of this. There's a large number of companies whose web capabilities need to support people who use their website while working at the companies that have older versions of IE. The company I'm with has embedded video players on a large number of web retailer's pages (we're hiring a javascript+flash developer in Austin, TX right now, particularly around video players. If you're interested, drop me a line) and a significant portion of them have requirements to support IE6 or IE7 with analytics that back up the need based on percentage of their traffic and conversions from those users.
However, I (not speaking for the company, just me personally) strongly disagree with the focus on "identical experience" amongst browsers. Instead, I prefer the route of graceful degradation where not all features may be available for all browsers, but it's fully functional and aesthetically pleasing (not necessarily identical) in all browsers.
That being said, not all companies have the same browser support requirements...it's entirely based around what the site's individual traffic and conversion rates are.
"I [...] strongly disagree with the focus on "identical experience" amongst browsers. Instead, I prefer [...] graceful degradation [...]"
I fully agree. This is what we have accepted with the mobile web since the 1990s.
This is a smashing opportunity for web application frameworks to provide that sort of accessible experience while permitting more "flashy" features on more capable platforms.
A js meta-library that abstracted 1.9 and 2.x as long as possible would be worth a licensing fee for many sites. The others would make the decision based on their own analytics.
There's a large number of companies whose web capabilities need to support people who use their website while working at the companies that have older versions of IE.
Like who? Honest question. I know that not all users currently have modern browsers (which is total bullshit, by the way--with free, open-source browsers as well as Chrome and the like, there is no excuse for this) but this isn't something we should treat as anything but detestable and fixable.
As for "identical experience", I will have to disagree. I have no problem with gracefully degrading sites due to screen size or compute power, but there is no reason that desktop browsers should be permitted to render things differently from one another (and if the spec is ambiguous, we should fix the damn spec). Developers are lazy, or shortsighted, or both, and given the option of "Hey, works on my machine/browser/whatever", we should expect only annoying fragmentation.
There are thousands of users in major banks and financial institutions which still use IE and have NO plans on moving forward anytime soon. None.
I don't mean the users. I mean the companies. You really think the banks that LITERALLY control the world's economy are somehow going to be 'shamed' into upgrading their internet browsers? You might as well try shaming the moon into changing color.
I don't mean to sound condescending, but there's no other way to put this...the comments about browser support on this board show just how inexperienced many developers really are. We are not talking about installing Firefox or Chrome on a few PCs. We are talking about MASSIVE companies with BILLIONS (with a 'B') of dollars flowing through WORKING systems that have been tested into infinity and are the backbone of our economy. Should they upgrade? Sure. Will they? No. not until they've stretched the technology they are already running until it collapses.
This move by JQuery devs, I get it, but it's quickly pushing itself out of the realm of 'awesome' to 'annoyance', only suitable for small projects. I hope not, but that's what it looks like. Even 1.9.x deprecated some features that should have been left alone - we had to code them back in.
Which companies? Give us some names--that's why I'm proposing this list.
We always, always hear the same threadbare stories about mythical magical enterprise customers that can't/won't upgrade, and the little tail wags the dog, and the life for the rest of us is made harder.
All this for a use case which is basically hearsay and rumors.
As for inexperienced developers--I'll go and say that the experience I've had of watching bad compilers and system headers and christ only knows what else force native code to get uglier and uglier and less maintainable are what motivate me to try and discourage the same mistakes in Happy Web Land.
The web is barely twenty years old, arguably much younger--let's at least try and avoid sins we don't have to commit.
Edit: Or, you know, downvote me without explanation. That's pretty cool too.
I work at Montefiore Medical Center in The Bronx, NY. Much of what I do is building intranet web apps. About a year ago they upgraded (yes, upgraded) to IE7. We have 18,000 employees, but let's say we have 10,000 computers. Upgrading all of those computers, verifying that all of the hundreds of apps provided by dozens of vendors used in scores of departments is a huge and expensive project. Healthcare in NYC is a business that earns you a margin of - if you're lucky - 1%. It is difficult to justify the cost
Note that I'm not a decision maker - in fact, I'm not even in the IT department. Please don't try to argue this with me, as I may be totally wrong about what their decision factors even were. Personally, my life would be much easier if they would upgrade, but I can understand why they have not.
No one working at that level is going to disclose their customers and the technology agreements they have. That would be business suicide (and would ruin lives). Again, this isn't mom and pop shop level stuff.
But I will give you a clue. Go find a list of the top 10 biggest banks in the United States. It's almost all of them. Then go find the biggest credit card companies. It's most of them.
Have you ever walked into a Chase branch and noticed they're running IE as they browse through your bank account, and wonder why such insanely sensitive, secure information is being run through IE?
Find me a bank that doesn't run IE, for that matter. I'm a Chase customer, so I can only confirm them. But I honestly wonder how many banks don't run IE.
The problem is that some of these big companies outsource their IT. They don't want to upgrade from, say, IE6 because they know it's going to cost them a FORTUNE.
I know of at least 2 big blue chip companies with this problem.
In fact, I once had a requirement that the software we write have it's own independant auth mechanism and NOT be linked to Active Directory, "because it costs us thousands every time we ask to add a user or change a role".
For the 'Like who?', I'm too lazy to check which companies are our customers that have a "can be used to endorse our service" clause, the categories off the top of my head are: major telecom providers, major PC sales companies, office furniture sales companies, major clothing companies, major beauty product companies. Note that this doesn't cover new companies or technology focused ones, there's a particular demographic that they are selling to that at a minimum browse their sites while at work. And after rereading everything, I may have been a bit ambiguous, so I'll clarify. People, while they are at work, use browser A because they work for shitty company X. While at work, they browse, add to cart and buy from an unrelated company. And for whatever reason, people buying from the unrelated company are disproportionately doing so while at work and working for a company with outdated browsers.
For the degradation, I especially don't mean a lazy approach. In fact, having good degradation is typically harder for newer developers (or requires them to check in more browsers). The core way to do it is to develop for what's common across browsers (what's handled the same way), then for ambiguities in the spec (does the border count as part of the width of a div or not?). Once that's done, you then add the extra. The idea is, if browser A supports, say, easily defined gradients on a button, but browser B doesn't, should we have a special case for browser B to load an image to give the identical gradient, or should we let it be a flat colored button? Or let's say a browser has some extensions that make client-side form validation easy and simple. Using that functionality for that browser makes sense, but is the development effort to do the validation on all browsers worth it when server-side validation will happen also? The functionality is the same, the experiences are both good, but the experiences are not identical.
It's pretty clear that you don't know many people who use IE8. What you're saying sounds nice in theory, but falls down in practice. Many people lack the knowledge of better browsers, or are simply afraid of changing, because they've learned how to use IE, and they don't want to learn a whole new set of routines. They don't use computers in the way you do, because they don't understand the underlying principles - they learn step by step how to do a task, and then they replay those steps every time, like an Excel macro. This is why, when something unexpected happens, they're helpless.
Switching browsers may break many of those macros, and at the very least, will be very uncomfortable for many.
Look, there are two camps: companies that refuse to run modern browsers, and individual users.
I posit that we should list the members of the former camp, and that we should educate the members of the latter camp. Changing from IE to Firefox to Chrome shouldn't be a big deal, and if we've only managed to instill idiot monkey-level tools usage in our users we have (as developers and human beings and tool-users!) failed.
You do not, do not want to encourage the intellectual sloth of these folks--it will come back to bite all of us.
You keep banging on this drum as if you're going to somehow name and shame big businesses for making perfectly reasonable business decisions.
Please understand that a web browser is just a software tool like any other. You don't install a web browser at your business so you can say you use some bleeding edge shiny. You install a web browser to get some useful job done. Much of the time, that involves accessing in-house systems. Some of the time, maybe it involves accessing the external WWW, perhaps to research or buy something. Supporting the latest browsers so everyone can spend even longer playing on-line games or posting on Facebook is, shall we say, not a business priority.
Now, please understand that perhaps the single most important attribute for most large businesses with significant IT operations and mostly non-technical staff is predictability. If everyone is running on a stable software foundation, then tools can be built on top of that foundation. If everyone is running the same version of their end user software, then help desk staff can provide canned step-by-step guides to doing things, or remotely access someone's machine to fix a problem or guide a user through a new process for the first time. If every server in a group is running the same operating system distribution then you only have to keep track of one set of security patches and apply them uniformly. And so it goes on.
In this context, it is entirely reasonable that businesses "refuse to run modern browsers". Your modern browsers do stupid things like moving the goalposts every six weeks (or every few months if you jump through special hoops to use a laughably named long-term support version). Your modern browsers include new technologies that introduce security and privacy risks we didn't have before. Your modern browsers break backwards compatibility and won't run the $5,000,000 bespoke CRM package on our intranet any more! And in most cases, your modern browsers offer no business benefit compared to the tried and tested tools already in use.
In short, while you may wish that everyone ran the latest shiny new browser, there are very good reasons why many big businesses don't. If you think the guys running IT for those places somehow didn't notice that there are other options or just can't be bothered to upgrade or suffer from "intellectual sloth" then you really have no idea how things work at that level at all.
I won't give you a name - but I know of a very large international company (hundreds off offices, tens of thousands of employees, etc.) that runs older versions of IE across much of their network. Some of it is budgets for testing newer versions. Some of it has to do with specific applications that are business-critical, but only work on older IE versions and haven't been updated / upgraded to run on new versions of modern browsers. It's easy to say "just upgrade" but large organizations just don't operate that way unfortunately.
We have a large number of users in rural areas of Kenya who only have access to a very old computer which barely has enough steam to start up each day. They still use IE6.
RBS. Aviva. NABG. And that is just the larger ones I have experience of. Those are pretty big hands to wave. If we say "sorry, our products might not work as well in IE8" they'll say "sorry, we can't use your products any more".
And it isn't just that they demand IE8 support in case their customers need it, their desktop builds used for all their internal uses have nothing but IE8. "Maybe they'll upgrade soon" we hope, "or perhaps given their users one of ff/chrome/other as an alternative along side IE8", but given they only upgraded to IE8 from IE6 over the last two years (the last of our clients to move from IE6 completed that transition about three months ago) I doubt I'll be seeing them use anything better internally for a good few years.
You can shame Amazon/whoever all you like for supporting IE but I don't think they're just going to shut down their store for even .5% of their userbase.
Go into a local small business with about [$|€|£]2-5m in turnover per year. A moderately successful veterinary practice comes to mind.
They have applications that need to be managed by what is undoubtedly an outsourced IT service, very likely related to some other system (practice management, diagnostic hardware, goofy industry-specific file formats, accounting, back-office, etc.).
They will stay on XP for ages because it works with everything they bought when they last "modernized" their practice ten years ago. Upgrading will be prohibitively expensive, on the order of making the decision to hire one junior staff member for a year.
The same upgrade will cost the same in a year, or five years, so there's no business purpose to upgrade until they need to migrate to another platform, either due to lack of support for modern hardware as the existing gear ends its lifecycle, or because of a strategically imperative application that requires an upgrade.
They may need enough "modernity" in their web browser for industry sites and (increasingly) wikipedia, but most uses of web 2.0 will be shrugged off as inessential, whether it's Facebook or Highrise/Salesforce/whatever.
Bigger companies have to refresh hardware due to failure at a higher rate. As a result, they can retain a permanent staff of people who manage OS images and upgrade on a next-to-last type cycle. Smaller companies are often using "personal" grade equipment and will take the accelerated depreciation when they need to buy one new laptop because the old one is too slow.
I understand the issues with small businesses--believe me. I also understand that in those environments, getting Firefox installed doesn't magically break everything.
The purpose of having a list like this is to record the service providers who do have products out there that break using modern browsers--because they're ripe opportunities for "doing it righter and cheaper".
Do people not see how hard they are making the lives of future developers (or even their own lives down the road) by continuing to coddle these people?
Your vet example would be happy to switch to a cheaper service (cheaper because the devs were cheaper, because the tech is more modern and less finicky) if it were available, and a hitlist of companies ripe for displacement (due to running old platforms) would help the vet as much as help the devs.
"Do people not see how hard they are making the lives of future developers (or even their own lives down the road) by continuing to coddle these people?
Your vet example would be happy to switch to a cheaper service (cheaper because the devs were cheaper, because the tech is more modern and less finicky) if it were available, and a hitlist of companies ripe for displacement (due to running old platforms) would help the vet as much as help the devs."
The benefit of change has to outweigh the cost. How long would they have to close, or "click over to the old system" with clients, until they were fully transitioned? These are not organizations that use webapps as their primary app delivery platform. (Or, rather, they don't know that's an embedded IE control in their x-ray viewing application.)
Who cares about the devs? Seriously, they are the group that should be paying for access to the markets, either via currency (buying software that makes this problem go away) or by labor (maintaining ten versions of their sites).
The problem is that most developers, and web developers especially, are squatting on the properties of large organizations with goals that are not always aligned with theirs. At best, we own our way down to the OS system call level. Increasingly, our dependencies are bound much higher in the application stack. .NET and Java versions can be changed out from under us, web browsers can be swapped out, and even features such as HTTP pipelining or keepalive can force us to reevaluate our scaling strategies.
I agree that the lack of control is frustrating. This is the nature of the industry.
For an example in another industry, read about Swatch Group's desire to stop supplying watch movements (and parts) on the open market. ETA has become so central in the industry (very similar to a late 90s MSFT) that the Swiss government became involved in slowing the policy change of a corporate entity. Even so, a number of smaller watchmakers will cease to exist because they won't be able to adapt.
Many of these people don't care about "support" from Microsoft. They care about compatibility with some piece of mission critical software, whether it's a DOS-based app, an old FoxPro database that won't run on a newer release (compatibility mode what?), or an ancient version of Peachtree that can't be upgraded without going through ten intermediate versions.
Whether it's XP, 98, 95, NT, OS9, SCO, OS/360, etc. isn't really the issue. It's that customers need a reason to upgrade, and making life easier for a web developer is usually not that reason.
Many of these people don't care about "support" from Microsoft. They care about compatibility with some piece of mission critical software, whether it's a DOS-based app, an old FoxPro database that won't run on a newer release (compatibility mode what?), or an ancient version of Peachtree that can't be upgraded without going through ten intermediate versions.
Or, for a significant number of businesses, support for some expensive custom hardware that came with a software package that runs on (for example) Windows XP, but doesn't work because of the device driver architecture changes on Windows 7. The odds of places like that upgrading just to get a new version of IE are approximately zero, and even less if part of that software solution actually uses IE specifically.
You'd be surprised about hospitals. At a hospital with modern software, a lot of the browser based stuff they use actually runs through Citrix or something similar, so they're using IE9/10 or Chrome for the most part.
That's one helluva qualifier when talking about hospitals. Our company creates web-based software for hospitals, and we have yet to talk to a customer who doesn't need IE7 support. (We draw the line at IE6.)
Interesting. We do software for larger hospitals that has some web-based elements and require IE 9+ or Chrome. I guess we're targeting different audiences.
I think it's great. No one is forcing anyone to upgrade, jQuery 1.9 is stable and you can use it forever even with new browsers. So what if it's not supported after some unknown date in the future. It's solid and will keep on working. No one is forcing developers to switch, but in my case I don't want my users using older versions of IE. We develop apps for in-house use, and breaking old insecure browsers is a good thing, it promotes user upgrades. A smaller jQuery is great, as it will reduce load times a bit. I couldn't be happier with the decision.
If the only issue is IE 6, 7 and 8 marketshare, then the question becomes: how long will IE8 have a sizable portion of the market. Here's a graph of the browser market over the last 3 years (typical disclaimer about lies, damn lies and statistics, and measure your own traffic, etc.)
Assuming the above graph is relatively close to the truth, IE8 is around 10% of the worldwide marketshare.
So, the question is: when does a library like jQuery drop support? 10% marketshare, 5%, 2%, 1%? At what point is the overhead outweigh the benefits?
Obviously there are some developers who need to support IE7 (for example), regardless of the overall market. I personally don't think that should be the approach for tools like jQuery: time is valuable, and they should target the largest possible market possible.
I don't think that's true. There were a handful of competing libraries (Prototype.js, Mootools, etc) and jQuery won out because people seemed to prefer its API.
I can only speak for myself, but IMO jQuery won because of their docs. I seem to remember having a hell of a time trying to get MooTools to work in the summer of '06, and finding docs to be of no help.
People underestimate just how important jQuery's documentation has been to its success. Even jQuery themselves seem to underestimate it, because the documentation for jQuery UI and jQuery Mobile really are not as good as the core docs (though still far better than the average). I probably would not have started using jQuery for my projects nearly as soon or as often had it not been for the excellent documentation.
IE7 is almost dead, falling below 1% almost everywhere, and IE8 is dying a quick death. Google dropped support for IE < 9 on all it's webapps in November 2012.
This is a welcome change. Considering the market share of IE 6, 7 and 8 is pretty minuscule and Google dropping support for IE8 back in November 2012 should be cause enough to drop it from jQuery too. It's great to hear they'll be supporting the older 1.9 branch for users who need to support older versions of IE as not everyone has the luxury of being able to ditch older versions of IE like that. There's no cause for concern here, the jQuery team covered their bases well and lets face it, there aren't many open source projects out there that drop support for older versions of something like a browser and then commit to continue to support an older branch for a lengthy amount of time.
Statcounter[1] puts IE8 at ~10%, 12% for the US[2]. In some markets it's even lower[3]. This matches what I see from non-tech client websites. For anything related to software, IE as a whole is close to zero.
StatCounter tracks 3 million websites vs 40k for NetMarketShare.
As best I can see on the site you linked, IE8 is 23.23%. That also disagrees significantly with this source: http://caniuse.com/usage_table.php where IE8 is 8.89%
Well one of the websites I'm working on is a fairly big one in germany and only about 4% of all visitors are using IE8 or below. Guess what! We now only support IE9+.
You combined all aforementioned versions of IE together to yield that result: http://www.netmarketshare.com/browser-market-share.aspx?qpri... — even combined the market share is still in my opinion minuscule. The only browser with a substantial market share is IE 8 which according to the site has a market share of 23%, it's not even worth adding in those other percentages on-top to try and make it seem as though a lot of people still use those browsers.
31% is not justification enough to maintain legacy code in a library that has become a little bloated over the years because of the backwards compatibility with older browsers. If you want to support that 31%, use the 1.9 branch it's better than the alternative being no support whatsoever.
Edit: Why all of the down-votes, is my response offensive?
Then shouldn't my original comment be the one that gets down-voted which is where I originally said IE's market share is minuscule, not my response to someone else's comment? I standby what I said. Considering Google does not support versions of IE below 9, Google too deems 1/3 of the Internet to be a minuscule proportion of users if they're fine dropping support.
So I find that the majority of people are missing a very LARGE improvement that I value far beyond any of the stated benefits by the jQuery team:
-One of the most popular libraries is dropping support for IE 6,7, and 8. Thus, yet another cornerstone of the web is going to push users forward and increase the chance that those miserable browsers will disappear.
The most disturbing thing I find is that there are developers that are DEFENDING existence for those older browsers. Are you masochists? Do you enjoy the headaches of fucking around with those??
"Oh but so many clients are still using them, and it writes off potential users!"
How can we ever expect for them to upgrade their damn browser unless the builders the web (developers, not just browsers) quit allowing them to rot in complacency????
Of course, there is a thing as going "too leading edge" and expecting "too much" from the user...but when the cornerstones (libs, browsers, etc) start pushing them forward - then we should embrace this change. Coding for the multi-browser/platform/device/version web is hard enough.
I don't get this line of thinking. Do you know there are programs written on system/36 machines from the early eighties still in production today on ibm iSeries machines? And even older software/systems in place that are older then that. Business requirements don't change hourly/weekly/monthly. If the business requirement that existed at that point in time, that the software solution put in place at that time met those requirements why would a business be compelled to change if those requirements have not changed and the solution met those needs? I've been a developer a really long time, 25+ years professionally. Businesses demand stability, this absolutely absurd idea that software that is only a few years old must be thrown out and some new flashy unproven shit put in its place is mind boggling. The last job I put a bid on, one of the requirements was that the software in initial form be supported for a minimum of 10 years. And in my experience that is a short life span.
Not defending, but if you cannot degrade your functionality to make it work in old IE then you doing something wrong. Please, give me a use-case that is not too niche but absolutely requires the latest generation of browsers.
I've read through the 100+ comments that preceded me, and I must be missing something stupidly obvious. Thanks in advance to anyone who can enlighten me.
Can't you just host your own copy of JQuery? If your web app needs version x.y.whatever, is there some reason why you can't just host your own copy of the library on the same servers the provide the rest of your web content?
I understand the convenience of using some CDN's copy of JQuery, but I'm unsure why it's anything other than a convenience. Maybe it's about money: "It'll cost us an extra $X per month in bandwidth fees to host our own version of JQuery." Maybe it's about user experience: "By hosting JQuery on our own site we add 100ms to page load times."
To the people who seem most unhappy about the version bump, can you describe how hosting your own version of JQuery would complicate your lives? Just so there is no ambiguity, I'm asking from a point of ignorance, not snark. I would genuinely like to read the answers.
There is zero problem with hosting your own copy. Lots of people do.
The main advantage to using a CDN is that a single copy can be cached across multiple websites, meaning that the first time someone visits your site, there's a good chance your version of jQuery already sits on their computer. Plus, the Google CDN will often serve content faster than your own site. And, since jQuery is now so "integral" to websites, it almost seems silly to have to maintain a copy of it yourself.
But the main downside to using a CDN is that, CDN's have gone down before, and that means your site will stop working. Obviously, it doesn't happen often, but it happened once to a widely used site of a friend of mine, and he swore, never again will he reference jQuery on a CDN. I personally prefer to host myself too. (But not out of bandwidth savings, that just winds up being trivial.)
I would be wary of that -- I assume it's likely that a CDN would often time out in case of error, which means you might be looking at 30 or 60 seconds until JavaScript works on your page.
Y'know, I hadn't even considered that your browser might already have a cached copy of JQuery because of a previous visit to some other site. Like the friend you mentioned, the idea of third-party hosting for a critical piece of infrastructure is a non-starter for me. If my site depends on X, I prefer (the illusion of) control over X.
It's not about being able to access 1.x in the long term from a CDN. The problem is whether it will still be supported. If there are bugs in 1.x, will they be fixed? Will 1.x support Chrome v40 and IE 15?
Backporting bugfixes has a cost. Requiring 1.x to support IE15 pushes that cost onto the jQuery developers instead of where it rightfully belongs: migrating your app to a recent version.
Thanks for the clarification. Although the JQuery team didn't announce any end date for support of 1.x, I appreciate the ticking clock implicit in the major version bump.
I suspect that a comment made by user Zangrief is right on the money - enterprise users will increasingly take over maintenance of the 1.x branch out of necessity.
The addition of the ability to just use querySelectorAll as the selector engine and not ship Sizzle is a pretty big deal, and not something I remember being included in earlier discussions about jQuery 2. qSA still includes a pretty broad set of selectors, and the ability to get the build down to 10k minified and gzipped puts it squarely in Zepto's territory, size-wise, eliminating the need for that particular wheel reinvention.
If you use really simple class and id selectors, the qSA-based selector engine may be fine. However, I think a lot of devs would be surprised about how much Sizzle is doing for them.
qSA does a lot more than class and id selectors; those have been trivial since long before qSA came along. You can also do selection on element attributes, parent-child selections (include strict child selection with ">"), and a few other higher-order selector combinations.
Still, I don't mean to slight Sizzle, and certainly won't stop using it. It's just nice to see jQuery compete with Zepto, since apparently there's a demand for a build that small, and jQuery is better-tested and less brittle.
I didn't mean to say that's _all_ you can do, but people often expect more than qSA can deliver, especially if they've been using jQuery/Sizzle for a while. Sizzle also works around bugs in qSA implementations when they exist.
qSA's design shortcomings have been well documented, John Resig did a blog long ago about them [1].
The list of what you lose if you remove Sizzle is in the native selector file [2].
> Asking jQuery to support those browsers longer than Microsoft itself is willing do seems a bit harsh.
While I agree with jQuery's decision here, this isn't really fair right? Windows XP and most old stand-alone software they have installed will continue to work after MS drops support.
When we're talking about the web, a reasonable effort should be made to support those legacy users. Of course, you can only do so much, but according to the general consensus in these comments, that's around 10% of visitors. Whether or not dropping them is worth saving the 12% in code size, is a different question.
I cannot believe IE8 is now considered 'old'. It is the second most used browser+version on our site, and has about 80% as much usage as the leader, IE9. Can't see IE8 support being droppable for many years yet.
It all depends on your end goals and your audience. I don't have #'s off the top of my head, but let's say IE8 accounted for 40% of browser usage across your visitors. But IE8 is old. Are you willing to say to 40% of your potentially paying customers "Sorry, but your browser sucks. We're not supporting you."?
If you are, great. No coddling necessary. But for other people, they may not be comfortable with the percentages yet, and I think that's perfectly understandable.
You wouldn't say it like that, I hope. You would say, “Here's a link to a browser upgrade that will allow you to enjoy the best product we can offer you. It's completely free, and takes only a few minutes to install!” Also, IE8 accounts for less than 10% of browser usage worldwide now, so the odds of a company having it be 40% are rather slim, unless they specifically target enterprise in which case they dug their own grave and I have no sympathy for them.
Oh no, of course not. I'm just trying to make the point that some companies may not be comfortable with whatever IE8 is at right now. I think you can substitute "IE8" for any browser, and "40%" for whatever that browser's current market share is.
Coincidentally, I work in the multi-family housing industry, and one of the industry titans requires IE to use their product--which everyone uses--so we have ~82% IE share on our own product (which is supplementary to the titan). Of that, IE8 stands at ~31% of our total site traffic, which is compelling enough for our company to need to support it. (IE9 is only ~39%, with IE6/7/10 making up the remaining 12%.)
So until that industry titan changes their way, we're stuck in an IE rut.
This is exactly right for multi-family housing. I can't see any sort of startup or disruption coming in anytime soon without taking years of hard work to reach 50% feature parity to meet what the industry expects are standard features. (Or maybe I've been working here too long to get past that notion.)
What exactly is shitty about it? Old browsers can still display text, images and hyperlinks. There are millions of use-cases perfectly covered by them.
For starters, users expect modern-looking websites. That includes users on old browsers, thanks to the amount of bending over backwards done in the web industry to provide those users with as much of the modern browsing experience as possible. If you serve up a page looking like the c2.com wiki to a non-technical user, they're not going to be too happy about it.
Far more so than that, though, what's shitty about having to support IE 6-8 is the complete lack of consistency. Even if you aren't doing anything fancy, you have to spend a hell of a lot of dev time if you want things to look the same across browsers when they're included. Hours and hours of wasted time is pretty shitty, especially when the work involved is so aggravating and, from a creative point of view, utterly pointless.
In effect, your question is like asking what would be shitty about developing apps for a 10-year-old Palm Pilot. There are millions of use-cases perfectly covered by those too, but that doesn't mean an iPhone app developer is going to want to spend time porting his apps to one.
Even if the users expect "modern-looking" websites - it is not something that cannot be done with IE6.
Secondly, you don't have to design 1:1 pixel-perfect copy of your website that looks the same on all browsers.
The main thing - if your developers cannot degrade the website functionality - they are seriously doing something wrong - get more experienced
You can as well design Flash site and call it "progress" and tell the rest of our users to go somewhere else. Now, how is it different from other "modern" technologies? Its W3C support?
"but that doesn't mean an iPhone app developer is going to want to spend time porting his apps to one."
If your customers still use Palm Pilot, then why would you design your site ONLY FOR IPHONE??????
The developers always can degrade the functionality; whether they can is not the point. The point is how long it takes them to, and how much they could be doing for other users with that time. Getting more experienced at making products that work on broken platforms is not a good thing. That is not good experience. That is a symptom of a broken industry and it makes your developers worse, not better. It's like people who say PHP isn't that bad, you just have to learn all of its quirks. Learning its quirks doesn't make you a better programmer, it makes you a programmer who is able to use a specific poorly-designed tool. That experience and knowledge is not portable and is not valuable outside of a specific arena, and is not the kind of experience and knowledge that developers should be working on.
If your customers still use Palm Pilot, you've chosen the wrong market segment. Yes, make something people want, but you're allowed to be selective about who those people are. If you're a hacker, it's very likely because you enjoy creating and working on interesting and fun things. Making websites work in IE6 is not a fun thing. There is enough value waiting to be created that we don't have to waste our talents and energy on this kind of nonsense.
By not supporting old browsers with all of their inconsistencies, a team can save a significant amount of development time. That development time can then go directly towards new features, bug fixes, etc. It's not so much that the latest browsers can do so many new things (though in some cases it's that as well), it's that you can actually develop for them efficiently without diving into a rabbit hole of IE compatibility issues every time you add a feature to the site.
Of course, it is easier to support only 1 mature platform , 1 database, 1 application server, 1 library of whatever. However we don't have this luxury even on the backend, and you cannot seriously expect it to be different for browsers.
And if you don't develop cross-platform because of lack of time this is fine. Please, don't cover it with insults about dumb CEOs and ignorant lame users - bad excuse for bad programming habits (not personal, just generalisation).
Again, there is no technical reason not to give workable version of the website to all major browser users. It doesn't have to be a pixel-perfect copy. It just has to work.
I'm not asking to support one platform or one browser or one anything. I'm asking to support the standards. Industries have standards for a reason.
I didn't insult anyone, CEOs or users, so your generalization is a very poor one.
The technical reason for not giving a workable version to IE6 is that it can take as long to make a workable version for IE6 as for all other browsers combined. IE8 is not that bad, but it's similar in principle. If I have to spend 50% of my time on 10% of my users, I'm better off doing twice as much for the other 90%.
That all changes if your client uses browsers that are more then 2-3 years old, and you are financially dependent on your client being served properly.
You can tell your client to use a new browser. It's all in how you phrase it. Everyone in this thread seems so damn scared of their clients. You have a way to improve their experience of using the internet and using your product. That's an opportunity to embrace, not something to run away from.
Naturally that depends on your target audience. I haven't checked the version, but we're stuck on an older IE at work. Possibly 9, but I think it's 8. No choice in the matter.
Does someone have a gun the CEO's head stopping him? He could tell everyone to install latest Chrome or Firefox and have everyone upgraded in 10 minutes.
These decisions typically have much wider reaching ramifications, like an existing tech stack which relies on some quirk of IE6, or activeX. Yes, it's simple to upgrade a browser, but the potential impact must be evaluated, and this takes time (more than 10 mins to install a new browser).
I think this really depends on your target market. Big corps such as banks are typically slow to move and I know of at least one which is only just moving from IE6 now.
How much money can my business afford to lose on a point of principle that no-one else in the company would ascribe any value to whatsoever? Not much. The decision obviously takes into account time spent catering for older browsers, but jQuery eases the problem - at the moment. As a very rough guide, it seems sensible to cater for any browser version representing at least 1% of traffic; IE8 currently represents over 20% for us, so it's nowhere near getting dropped, unfortunately.
1%? That seems like an unreasonably low threshold. If 1% of your traffic requires even 5% of your development time, you're getting negative value from that time. I probably wouldn't drop it at 20% either, but I would long before 1%.
I cannot believe IE8 is now considered 'new'. It is the least used browser+version on our ecommerce site. Can't see IE8 support being a priority for many years.
We presume the IT staff of our clients know what they are doing (and if they don't, why waste our time and theirs?).
We did drop IE6 support late last year once usage dropped well below 1%, and now that IE7 users have just dropped below 1%, we are warning that we will be dropping IE7 support.
We try not to presume to tell our clients how to run their businesses, and we try to make it effortless for them to use our service... that is the point of browser based services.
> If you want, you can serve 2.0 to newer browsers and 1.9 to older ones using our conditional comment trick
I'm really surprised they would suggest doing this. The two APIs are quite different since many functions from the 1.x branch have been removed in the 2.x or sometime behave differently (for instance `$("some <strong>bold</strong> text")` will be parsed as HTML in 1.x but considered a CSS selector in 2.x).
Basically, I really wonder what could be the benefit of using this kind of conditional comment trick.
The point of separation is simpler jQuery development and reduced file-size for the >= 2.x versions. You will serve two files. You serve 1.9.x to IE 6/7/8 users, and 2.x to everyone else. You save bandwidth. You save money.
Features will be the same. It's OSS folks. It's not like it's ran by a closed-source team at Google who may suddenly pull the plug if it deems the project unpopular. My guess is folks who work in enterprise (where older IE still plagues) will be the big maintainers of 1.9.x.
Serious question. Please hit me with a clue stick.
Regarding 1.9, how can "old-IE compatibility often causes problems of its own" and "simplest way to support older browsers is to use jQuery 1.x on your site, since it works for all browsers." both be true at one and the same time?
This is one of the biggest projects on the web leading the way in throwing shitty old IE under the bus to help push the modern web forward.
They're going to keep big-fixing 1.X so people stuck with IE6/7/8 can keep supporting it, but moving forward with 2.x for modern browsers makes their lives easier in the long run, and provides yet another coffin nail in Microsoft's attempt decade-old attempt to break the web.
They're not so much throwing IE under the bus as throwing developers under the bus that have fortune-500 clients that can only use IE. Some nerd (me) whining about their browser choice is really not going to make their IT director change policies.
Make that Fortune 500s which when jQuery 2.0 is released next year needs to be running a OS which is EOLed by Microsoft with no support or security patches to be affected.
IOW: Cry me a river.
People made these exact arguments that people "require XP and MSIE8" and that they "can't upgrade" years ago, when Vista was released, then when Windows 7 was released and now with Windows 8's release.
Here's news for you: You've had 2 or 3 advance warnings from Microsoft that your IT platform will be obsoleted and unsupported and 2 non-ordinary support-extensions. You've had more than half a decade to plan and execute the migration.
If you haven't completed that migration yet and are still whining, you are incompetent as an IT manager. There is no other way to describe this. If you are still running XP, that is because of incompetence. No excuses.
XP is older than the very first release of Ubuntu. Microsoft has supported XP for longer than Ubuntu's entire existance. As a basis for comparison any version of Ubuntu is supported for 2 years and that's it. XP has been around for 12 years now, and will be supported for yet another year before support is finally dropped. Sometimes enough is enough.
This is a good move by jQuery to streamline their code-base. Sometimes you need to do the spring-cleaning if you want your code to be manageable and have any chance of effectively improving your product, and this is just that spring-cleaning.
Whining about browser choice is never going to accomplish anything. You're speaking the wrong language. Speaking the right language would go something like: “I can increase revenues while decreasing long-term maintenance costs, and I can do it at the current expense level. The only way I can do this for you is if we use this technology.” The person you're pitching couldn't possibly care less about IE/Chrome/Firefox, but they certainly care very much about business metrics.
I think it will. Especially when you can say, "If we can drop IE 6/7/8 support, development costs will go down significantly." Remember, it's not just JS compatibility, think about all the CSS hacks you need to do to get your design just so. HTML 5 is another issue (I'm talking tag support). Requiring flash versions of your custom skinned player. There are so many factors we need to attach to old browsers, that it just makes sense to move forward. Maybe not right this second, but soon. And I think this is a great place to start.
Third parties have been trying to throw shitty old IE under the bus for a long, long time and haven't had much success in doing so. I fear jQuery 2.0 will see very low take-up on mainstream sites, and the resulting fork will be tricky to manage.
>Third parties have been trying to throw shitty old IE under the bus for a long, long time and haven't had much success in doing so.
On the contrary. Lots of big volume mainstream websites (including even Google properties) have stopped supporting IE6 and some even IE7 for years. For IE6 it has been at least 4 years since most sites stopped caring about it.
(Heck, even Microsoft created a site to convince people to drop IE6 it last year).
Mainstream websites will move much faster off of IE8. It's enterprise shops and people making software or websites targeted at them that will take the longest.
True, but it took a LONG time - IEs 6 and 7 were released in 2001 and 2006 respectively, so assuming your '4 years ago' stat is correct, that's still 3 years of waiting for a sweet spot of upgrades, by which time IE6 was 8 YEARS old. IE7 still gives me enough traffic (~5%) to require support, so that's a total of 4 active versions I need to cater for. I really hope adoption of latest IE speeds up, but I've been hoping that for a while now, and I just don't see it. Given that XP introduces a cut-off on IE8, I doubt we'll see the situation changing for a while.
1) Opportunity cost. Supporting them takes time and makes your code more bloated and less able to use cool new stuff without hacks and workarounds (and that cool new stuff can give you a competitive advantage to the other 95%).
2) This 5% is only gonna go down.
3) 5% is too small anyway.
4) There might be 5% of traffic, but how much is quality traffic? Depending on the site, a guy with the latest laptop, OS, browser and everything might be more likely to spend money, compared to some XP using guy that might have gotten there accidentally. This needs more search into your user data to tell.
5) Even if you want to still cater to IE6, you don't have to support it per se. You can just make it generally sure that its user can click around and see the pages, even if they lose a lot of formatting and cool options. I mean, don't even go for "progressive enhancement" stuff. Just let them be able to at least see the page, even if it looks like crap without the necessary css etc support.
IE7 is old enough that I would point users at all of Microsoft's “please upgrade” pages — if you deal with financial or personal information, it's worth doing just for the security benefits.
I still can't wrap my head around this concept that 5% requires support. Tim Ferriss isn't right about everything, but his bit about firing your worst customers is dead on. The Pareto principle suggests that 20% of your customers cause 80% of your workload, and the sensible thing to do is drop those customers. If it's only 5% instead of 20%, it seems like a no-brainer to me.
It really depends what kind of business you're building. If you rely on the network effect, for example, 5% of your user base helps to lock in the rest of your users, and so losing it may have a greater overall impact than just 5%.
Keeping old-IE compatibility prevents some optimizations and makes the code have to do extra checks, but using one file that supports it is simpler than using two files?
Ok, so the problems it causes are pain points for the jQuery devs and not for website devs? Also, the underlying code is more complex and lacks optimizations? Until old drops off the radar completely we'll have to use 1.9 solely or do a conditional check and serve the suitable version - serving 1.9 seems simpler ^^, call me lazy, many have,
Depends what you're doing. If you're building a mobile app (particularly one meant to be distributed via PhoneGap), or a Chrome extension, maybe you don't care about IE support.
Its also a pain for every website serving jQuery because of increased data for every single page load. Cutting out the support for old IE should also help with performance.
old-IE compatibility causes problems with the other non-browser platforms they list, e.g. Windows 8 apps, Firefox OS apps, Chrome OS apps, PhoneGap apps, BB10 apps, node.js, etc. For example Win8 apps using jQuery used to log an error on startup every time, probably because of some oldIE compatibility check which didn't work in the not-quite-a-browser environment.
There's a difference between working as a web page in all browsers and working in all HTML-rendering environments such as the ones listed in the bullet points in the blog. For example, Windows 8 apps or Chrome add-ons have additional security restrictions on .innerHTML.
I'm annoyed XP doesn't have IE 9 or DirectX 10+, but I guess that's Microsoft's way of getting people to upgrade to newer versions of Windows.
Based on current stats, I'd say IE 8 hasn't got long till you can ignore it but it really depends on how much market share you care about. Do people STILL target IE 6? IE 8 is on ~10%[1] and at the current rate it's dropping at should be at 5% by October - Just in time for IE 11?
As for blaming XP, I'm not sure you can completely. IE 8 is the default browser of Windows 7 and XP has more than double the market share of IE 6/7/8 combined. Most IE users seem to be schools and companies that haven't upgraded. Although IE 6 will definitely be gone by April 2014, we could very well be stuck with IE 8 for a very long time.
For the record, IE 6 and 7 should be ignored completely. Combined they have a market share of less than 1%.
For a rule of thumb, I commonly drop support once a browser crosses 5%. Might seem high but usually once it's at that level, it's only going to keep falling.
Something to look forward to, my estimates[2] put Firefox 3.6, Safari 5/5.1 and IE 6/7/9 to all be gone by the start of 2014. Of course, linear estimations should always be taken with a grain of salt.
AFAIK DX10+, D2D, DWrite etc was designed for the new driver model introduced with Vista and if XP display drivers are used they either don't work or fallback to software rendering. And yes IE9+ depends on D20/DWrite for its rendering, particularly for canvas etc.
Well done jQuery team, nice work. Wether I can use it production before April 8, 2014 is going to be debatable. I dearly would love to delete the XP VM running IE8 however.
I don't understand why the smaller file size is such a big deal. The file is going to be cached, and with the use of CDNs, is more than likely already cached before the client ever visits my website.
So if the Query team is still going to support these browsers in 1.9, why even make the 2.0 version?
The "How 2.0 Changed" section only lists dropping support for IE 6/7/8 and reduced file size (from dropping the IE support?). Are there any other note worthy/major changes or just minor bug fixes and the like?
it would be nice to see a 2.0 vs 1.9 bench on FF/Chrome/IE9+, much more interested in that than a non-noticeable 11k size reduction for the end user (maybe only slightly noticeable on very slow mobile).
Yeah, I was also scratching my head as to the 'performance' gains. Even if jQuery 2.0 has computational benchmark gains they also are likely insignificant in proper context.
Anyone know if the jQuery 2.0 fixes/enhancements will also be applied to the 1.x branch, particular the 1.9 series. Based on what I've read they are running in parallel with the IE stuff removed. I can't seem to find anything that mentions that 1.x stuff has been updated and released.
It would be nice if jQuery made builds for every browser, so savvier developers who can write server-side code can actually spit out only the relevant jQuery to the relevant browser. I mean, it's not like caching files at the ISP level is the limiting factor here, so each browser can cache its own file.
If the JQuery team is committed to keep supporting 1.9/1.x, entirely API-compatible with 2.0 -- what is the benefit to JQuery of the 1.x/2.x fork? You get a cleaner easier to maintain codebase in 2.x -- but you've got to keep maintaining 1.x anyway. If there was a feature you didn't want to add to 1.x because it was too hard -- you still can't add it to 2.x and not 1.x, because you committed to supporting 1.x as API-compatible, no?
Is the idea that 2.x will provide better performance on capable browsers than 1.x? So, yeah, the development burden is no less, but the results are better.
I guess I understand why people are doubting whether they will really follow through -- because if they do follow through, it makes it somewhat unclear what the benefit of the 2.x refactor was in the first place.
The stop gap solution of 1.9 as being parallel to 2.0 but with compatibility, is understandable, but will probably promote distrust in developers who just need a stable cross-platform solution. I think the immediate concern with 1.9, is how long it will continue in parallel with 2.x before being dropped