Hacker News new | comments | show | ask | jobs | submit login

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.

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.

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.

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.

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.

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.

>> And IE8 was the default browser on Windows 7.

Hasn't Microsoft decided to auto-update IE? In that case, most people who don't know what a browser is will already be using IE9 on Windows 7 by 2013 or is there reason to believe otherwise?

Yes. IE9 was an optional update.

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.

>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.

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.

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.

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.

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.

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.

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.

Sure, but why not Sauce Labs Scout + OnDemand? That was the whole reason we built it. I don't like running VM's on my machine, I prefer them to be perfectly maintained and run in the cloud.

Is there anywhere it fails to meet your teams needs? Genuinely curious if it's a product fail or a marketing problem.

Disclaimer: Used to work at Sauce Labs, not anymore.

Deploying VMs to an external cloud provider for the simple task of testing a browser is very heavy handed.

My point was that Virtualbox with the free images is still vastly cheaper than VmWare Fusion + a bunch of Windows 7 licenses.

(And your internal network is all wifi? Seriously? With designers shuffling big files around? Then you have bigger problems)

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.

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.

1) I don't get it. Completely dropping support would not break the brand experience, but allowing use via a simpler experience would?

2) The hardware issue was addressed in 3. Also, I don't follow, what do you mean by "the costs of supporting Chrome/Firefox are very incremental?"

3) That's a fallacy, actually. You're both proposing and confirming that "No one likes running VMs on their boxes because it still crawls". I, for one, run Windows XP VMs on my 4GB Core i3 iMac with no burden on the host OS at all. Some people might suffer with it? Yes, but some people could try tuning their setup for their needs.

4) Agreed.

Anyhow, we both know that the kernel of your argument is the first topic. I could convince you that the benefits outweigh the costs in 2, 3 and 4. But if your mindset is focused on giving the very same experience to every agent that can reach your app, or giving no experience at all; this argument is already over.

Also, saying that Apple does X or Y means absolutely nothing. Even if your company were almost exactly the same as Apple in every competitive aspect, nothing can assure that copying its culture would also lead you to a successful path. Actually, I believe history tells us the opposite.

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+

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.

This. We would ask our users why they use IE and if they would switch to using Chrome/Firefox or CF. Many of them in public education or state government offices are in a situation where the conversation is a no-starter.

ahh that's a real shame. I guess the best you can hope for is a change of policy when xp is EOLed. Even if it's just an upgrade to ie8 that would make your life more bearable.

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.

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.

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.

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.

> Like supporting old browsers is that hard/expensive.

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.

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).

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.

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.

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.

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?

>JQuery has just set a time limit on proper web access for an entire OS.

doesnt chrome work on xp?

Every browser vendor still supports Windows XP. The only exception is Microsoft. IE9 only works on Vista and Win7. IE10 will only work on Win7 and Win8.


Because we live in the real world, where complaining to Microsoft doesn't make up for lost revenue.

Firefox aswell

> 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.

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.

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?

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact