Technology Lab —

Can Microsoft really build a better browser?

Internet Explorer 9 is looking promising. But it's up against stiff …

At last year's PDC, held in November, Microsoft showed a graph showing scores of a variety of Web browsers in the SunSpider JavaScript benchmark, to show off the progress that the company was making with Internet Explorer 9. Another such graph was shown off at the recent MIX event. What was most interesting about the graph was not IE9's progress, but Opera's.

Opera 10.10, released at about the same time as Microsoft held its PDC event, fared pretty badly. Faster than IE8, but slower than everything else, including the (private) PDC IE9 build. Opera 10.50, released a few weeks ago? It's the fastest browser on the chart. It's faster even than prerelease versions of Firefox and Chrome, not to mention faster than the public IE9 Platform Preview build. SunSpider isn't the be-all/end-all of JavaScript performance, and it fails to represent real-world scenarios in a number of ways. However, it's clear that Opera's JavaScript performance has improved substantially over the period of about six months.

And most significantly, these improvements are now in people's hands. 10.50 isn't some preview release. It's a released, stable version of the browser.

This isn't the first time this has happened, either. Redmond promoted the JavaScript performance of IE8 in the run-up to its release, too. The result? By the time IE8 was released, or shortly after, competing browsers had once again overtaken it, with stable, shipping versions outpacing Microsoft's efforts.

By taking the approach of infrequent, but substantial releases, Internet Explorer users are being denied timely access to much of the progress that Microsoft is making, and hence denied the ability to take advantage of IE9's greater standards compliance.

We see similar situations, albeit with fewer easy-to-use graphs, when we look at how well other browsers implement SVG, or CSS, or HTML5. The current stable releases of Safari, Chrome, Firefox, and Opera are all streets ahead of the current stable version of IE. Make no mistake: these other browsers do not provide complete, systematic, exhaustive implementations of these specifications (though Opera's SVG support is not far off). But they are already providing extensive capabilities, not to mention impressive performance, to Web developers. And they're doing so today.

But Microsoft? IE9 is going to provide thorough, complete implementations of many of these specifications. This is certainly a good thing. It's what all browsers should strive to be doing. But Microsoft isn't going to release these features piecemeal. The current IE9 engine is already a huge improvement over IE8, but its preview status makes it irrelevant. We don't know when IE9 will be finished—2011 seems the earliest possibility, and there's an outside chance that it won't be until 2012 that IE9 ships.

In the meantime, we get nothing from Redmond.

This approach sets Microsoft apart from the other browser vendors. Firefox, Chrome, and Opera all get regular updates. I don't just mean security fixes, though they get those too—they get regular feature updates that improve their performance, improve their standards compliance, and improve their user interfaces. Firefox, for example, had release 3.0 in July 2008, 3.5 in June 2009, and 3.6 in January 2010. Opera 9.5 was released in September 2007, with 10.0 in September 2009, 10.10 in November 2009, and 10.50 in March 2010.

Over a similar time frame, Internet Explorer 7 was released in October 2006, IE8 in March 2009. And now nothing further is likely until 2011.

There's a similar discrepancy when it comes to support. Firefox 3.0 is going to receive its last-ever patch at the end of the month—a total supported lifetime of a little under two years. Internet Explorer 6, released in 2001, is still supported by Microsoft. It's old, its use is thoroughly discouraged, but it's also a part of Windows XP, and since Windows XP is supported, so is IE6.

Avoiding moving targets

Microsoft's approach is that it wants to build stable, consistent platforms. It is important to Microsoft that IE8 is, for example, a known target that developers can aim for, without there being a series of 8.1, 8.2, 8.3... point releases that might improve features, but also create more targets for developers, and not the stable, consistent platform that Microsoft wants to provide. It would also incur substantial support overheads.

The attitude is one that makes sense for Windows or Office. There are platforms that push out updates more regularly (Ubuntu, for example, has a regular six-month release cycle), but both of the two major desktop operating systems (Windows and Mac OS X) have lengthier release cycles. But the difference with these platforms is that in a sense they're more arbitrary. Microsoft and Apple get to pick the direction of their future OSes, and each new release introduces a raft of new—proprietary—features. There's no real benefit to releasing piecemeal updates in the same way.

But that's not the case for Web browsers. We have a fairly good idea what the target is, because the target isn't defined by the vendor. It's defined by W3C. Regular updates, making progress towards the various Web standards, are, in my view, a lot more useful. Microsoft's desire to have exhaustively tested, complete implementations of each part of each spec is laudable, and that should certainly be the ultimate goal, but fundamentally, partial implementations are still useful. By taking the approach of infrequent but substantial releases, Internet Explorer users are being denied timely access to much of the progress that Microsoft is making, and hence denied the ability to take advantage of IE9's greater standards compliance.

We've written before that Microsoft's approach to browser development does not engage Web developers as thoroughly as it could. To an extent, the decision with IE9 to produce this platform preview, and to update it every eight weeks, goes some way towards addressing this. Microsoft says that the eight-week cycle is the one that will make feedback manageable and allow the most effective involvement with the process. Sure, it'd be nice if we could see the progress more regularly (something like Chrome's dev channel would seem an ideal compromise), but the platform preview nonetheless represents progress on Microsoft's part.

Getting developers involved is only part of the story, though. Getting features into end users' hands is valuable, and perhaps the most important thing that a browser vendor can do. Having a fast, standards compliant browser engine is only useful if it's shipping and available, and making Web users wait two or three years between releases just isn't good enough. To get people energised and actually in favor of IE, Microsoft needs to retake the position it once had: the best, most compliant, most stable, fastest browser around. During the browser war era it held this position. But those days are long gone.

112 Reader Comments

I think the point made in the first sentence is persuasive. I'm not sure how much of a connection there is between that and what follows. I can see factors such as "its scripting engine is slow" and "it's inexplicably slow at basic operations like starting up and creating new tabs" would matter to end-users, and, if they tried something else they might stick with it on that account. But I wonder how many users are concerned by IE's lack of support for "things like SVG, Canvas, and HTML5 video". These things matter to web-developers, who are an important constituency, of course. (If they weren't Bill Gate's wouldn't have been making personal promises to WaSP and Molly Holzschlag.) These technologies are important for the future of the web, but I doubt they're driving shifts in browser choice. There's probably an effect whereby IE's lack of support for such standards (and errant CSS support) gives it a bad name among people who must write for it and hack around it and that bad reputation so to speak "leaks down" to non-technical users. But as for how important that effect is ...

I don't think these things matter to end-users as such (though the slow elimination of these users from sites like YouTube certainly does matter).

But it matters in the sense that it's Firefox or Chrome that people are championing. When they ask their knowledgeable friend on help setting up a computer, keeping it secure, etc., or to fix it when it's "slowed down"... that's when these things matter.

It wasn't always like this; during the days of the Browser Wars, people advocated ditching slow, unstable Netscape Navigator 4 in favour of IE 4, 5, 6. But these days, even though some security researchers are saying that IE8 is the most secure browser available (which is probably true, at least tied with Chrome), it's still not a browser anyone advocates.

I think becoming a first-rate browser (both in terms of standards compliance and performance, whilst retaining the vastly improved security track record) would be a big help.

I have to say this is a much better and more balanced article. While it shows what the author's preference is (more frequent releases), it goes to some length to explain the other side (platform releases) objectively. Well done!

Where is the mention of the corporate/enterprise consumer who wants to write apps targeting a browser platform and not be worried about perpetual upgrade cycles breaking their apps on a semi-annual basis?

This is your answer:

Quote:

The mantra at MIX last week was very much "the same markup everywhere"

Corporations might want to target a browser platform, but they really shouldn't. The standard should be what W3C says it is, not what a particular browser at any given point in time says it might be. And that same W3C standard is what everyone should be targeting, leaving the browser developers to aim for the same thing web developers are aiming for.

MS's stance on this is very much based in their monopoly and is for that reason alone simply not sustainable in the long run.

I would go even a bit further and say Mozilla and Chrome benefit from having Microsoft in the room. Microsoft's goal is developing something once, the standards the author mentions are currently (still) moving targets. HTML5 is a draft. CSS3 is a draft. Pushing Microsoft to target drafts (which by definition may change), invites the madness that you have now: web developers would have to target different versions of their site to different browsers. The author's suggestions here enhance the problems.

Sadly, this kind of logical, sensible thinking is going to fly clean over the heads of the professional miserablists that rail against Microsoft for not implementing standards fast enough.

It doesn't help that there are people involved with the standards bodies (like Håkon Wium Lie) that have built a professional career out of trying to stabotage Microsoft and/or take market share from them. If Microsoft were to ship IE9 with support for draft portions of the HTML5 & CSS3 specifications, these people would find ways to argue that the standard needs to be changed before it's ratified. They'd get their wish, too, because the ideas would probably make sense.

Then they could keep on railing against Microsoft for "embracing and extending" HTML5, CSS3 and trying to force their own preferred behaviour on the indsutry.

I understand the "but corporate intranets need a platform" sentiment, but isn't the writing already on the wall here? IE6 won't be around forever. If your intranet application depends on IE6, you'll have to update it in the not-too-distant future.

If Microsoft continues aiming for standards compliance, subsequent transitions should be much less painful. If your app works in IE8, it'll likely work in IE9, too, since they both aim to be compliant. Going from 6 to 8 will be painful, but it's also sort of inevitable.

Not to nitpick, but complete does not mean what the linked article says. MS said they're not going to worry if they fail Acid3 and focus on the stuff that most websites actually use. Which in practice may be a good idea, but it means that they are not aiming for complete support of web standards in IE9. Passing Acid3 does not prove you have complete support, but failing does prove your support is incomplete.

If you can point to any browser which has full support of all existing web standards, then you have a point. Since you cannot, you have no point; all you're doing is quibbling over which subset of standards should be preferred - and this makes you no different than MS.

I think Peter completely misses the fact that Microsoft's biggest customers for IE are corporate IT departments, which require Internet Explorer to be their "platform" for intranet-based web applications, and their needs are non-trivial. It's one thing to rapidly roll-out patches for bug fixes and security issues - it's another to do so for new functionality, especially with backward compatibility considerations. More than a few intranet applications treat IE4 (!) as their minimum web browser - these applications need to work on both IE4 and IE9 for IE9 to be viable.

= = = = =

Have you ever seen those intranet applications or worked in IT for a corporation?

99% of those don't do anything special --some reports, a workflow engine, some lame ass CRM, some CMS etc--, nor are they easy to break with a change in rendering engines. Actually, most of them don't even use Javascript. The worst offenders are those based on ActiveX, but that is not a web standard.

Anyway, MS could easily include a *frozen* IE6 engine for legacy corporate use and start shipping a modern, frequently updatable browser like the rest of the world.

Corporations might want to target a browser platform, but they really shouldn't. The standard should be what W3C says it is, not what a particular browser at any given point in time says it might be. And that same W3C standard is what everyone should be targeting, leaving the browser developers to aim for the same thing web developers are aiming for.

MS's stance on this is very much based in their monopoly and is for that reason alone simply not sustainable in the long run.

I work at The Big Company (not in IT) where our intranet is _very much_ still ie6 based. I can't help but wonder how our new intranet stuff is getting written today.

Even if MS halves its supported lifetimes it's still going to be substantially ahead of Firefox or Ubuntu, or any of Apple's offerings.

Firefox or Apple yes, Ubuntu no.

LTS versions of Ubuntu are supported for five years... which, admittedly, is right at half of MS's support cycle, but hey.

Besides, I think a lot of the reason that other vendors can get away with shorter support cycles is that they're less likely to push out new versions that are near-universally reviled (WinME, Vista, etc) and then leave them floating around out there for three to five years. Taking Ubuntu as an example, the release cycles are generally a LOT more gentle in terms of what is or isn't broken - as painful as the introduction of PulseAudio was, it didn't break NEARLY as much, IMO, as the introduction of UAC and the new driver model in Vista did - and when something gets pushed out that everybody hates, there is a lot more (justified) expectation that the hated thing will get fixed soon.

Where is the mention of the corporate/enterprise consumer who wants to write apps targeting a browser platform and not be worried about perpetual upgrade cycles breaking their apps on a semi-annual basis?

This is your answer:

Quote:

The mantra at MIX last week was very much "the same markup everywhere"

Corporations might want to target a browser platform, but they really shouldn't. The standard should be what W3C says it is, not what a particular browser at any given point in time says it might be. And that same W3C standard is what everyone should be targeting, leaving the browser developers to aim for the same thing web developers are aiming for. MS's stance on this is very much based in their monopoly and is for that reason alone simply not sustainable in the long run.

This seems to me like a statement of opinion, not fact. Just because you or others think that corporations should use technology X in way Y does not mean they are somehow bound to do that. I'm not even saying I disagree with your opinion, but unfortunately Microsoft is bound to its customers desires to a far greater extent than just about any other browser manufacturer. IE is really considered part of the "Microsoft SDK", so changing IE necessitates making sure it works the way people expect, even if their expectations are bad or come from buggy/poor behavior in previous versions that they have come to rely on (within reason).

It annoys me how many people dismiss the Enterprise/Corporate environment as lazy/inertia/idiocy. That environment has a lot of unique sensitivities, one of which is COST. You need to demonstrate clear productivity gains to any business manager to make wholesale changes to an environment. For a web browser, it is VERY hard to demonstrate that during this life cycle, it makes sense to upgrade to a version that breaks intranet apps that will have to be replcaed themselves on some other timeline. A browser upgrade for most companies is pure cascading cost, with no tangible benefit to offset that cost. (IE6 is pretty close, because of vulnerability and patching cycle costs, but that is a well understood entity now, 9 years later, so not compelling for most.) Once IE8 gets major penetration, the argument becomes even less compelling.

Where is the mention of the corporate/enterprise consumer who wants to write apps targeting a browser platform and not be worried about perpetual upgrade cycles breaking their apps on a semi-annual basis?

This is your answer:

Quote:

The mantra at MIX last week was very much "the same markup everywhere"

Corporations might want to target a browser platform, but they really shouldn't. The standard should be what W3C says it is, not what a particular browser at any given point in time says it might be. And that same W3C standard is what everyone should be targeting, leaving the browser developers to aim for the same thing web developers are aiming for. MS's stance on this is very much based in their monopoly and is for that reason alone simply not sustainable in the long run.

This seems to me like a statement of opinion, not fact. Just because you or others think that corporations should use technology X in way Y does not mean they are somehow bound to do that. I'm not even saying I disagree with your opinion, but unfortunately Microsoft is bound to its customers desires to a far greater extent than just about any other browser manufacturer. IE is really considered part of the "Microsoft SDK", so changing IE necessitates making sure it works the way people expect, even if their expectations are bad or come from buggy/poor behavior in previous versions that they have come to rely on (within reason).

It simply makes more sense to develop for web standards. Your site won't break years from now, and it can be viewed fine on different platforms. Why would you want to tie an application to ONE version of an OS or piece of software if you have the option not to? It makes better technical and financial sense to develop for something that's longer lasting, in this case W3C standards.

Its all the same ALL OVER AGAIN. What Microsoft ist really good at is rallying their products. And we always keep talking about potential. I bet once you get it running you will see. It will still be not good in comparison. But only somehow better in comparison to ie8 ...

I think IE9 will be much better than IE8, of course the other browsers will one-up MS by release or shortly after, but I don't think that makes MS' effort bad, all the things in IE9 will benefit end users a lot so why diss it like it slapped you around as a kid?

Where is the mention of the corporate/enterprise consumer who wants to write apps targeting a browser platform and not be worried about perpetual upgrade cycles breaking their apps on a semi-annual basis?

This is your answer:

Quote:

The mantra at MIX last week was very much "the same markup everywhere"

Corporations might want to target a browser platform, but they really shouldn't. The standard should be what W3C says it is, not what a particular browser at any given point in time says it might be. And that same W3C standard is what everyone should be targeting, leaving the browser developers to aim for the same thing web developers are aiming for. MS's stance on this is very much based in their monopoly and is for that reason alone simply not sustainable in the long run.

This seems to me like a statement of opinion, not fact. Just because you or others think that corporations should use technology X in way Y does not mean they are somehow bound to do that. I'm not even saying I disagree with your opinion, but unfortunately Microsoft is bound to its customers desires to a far greater extent than just about any other browser manufacturer. IE is really considered part of the "Microsoft SDK", so changing IE necessitates making sure it works the way people expect, even if their expectations are bad or come from buggy/poor behavior in previous versions that they have come to rely on (within reason).

It simply makes more sense to develop for web standards. Your site won't break years from now, and it can be viewed fine on different platforms. Why would you want to tie an application to ONE version of an OS or piece of software if you have the option not to? It makes better technical and financial sense to develop for something that's longer lasting, in this case W3C standards.

W3C standards like html5, that aren't finished and will probably change? Yea great idea..either way the situation is not good, I just dispute that it's MS' fault and MS' alone. Why can't they ratify these standards in a timely fashion, for one?

For a web browser, it is VERY hard to demonstrate that during this life cycle, it makes sense to upgrade to a version that breaks intranet apps that will have to be replcaed themselves on some other timeline.

The point is that if your browser upgrade breaks something, its a shitty browser, or a really shitty app.

What is a legitimate reason for an upgrade breaking something? If the spec wasn't finalized and it changed is the only one I can think of (which is why Microsoft shouldn't include draft things in their browser, but should issue minor updates with recommendations like DOM Level 2). If there is a mistake in the implementation developers shouldn't use it, but more importantly a .x update should be pushed out fixing it.

I don't know what IE7 wasn't mentioned in the article, because it is the perfect example of the problem. Even if you have an IE7 specific app (why you would, I don't know), IE8 has been out over a year and has Comparability Mode! It's almost guaranteed not break! Instead, with these 3-4 year releases, Microsoft is fostering a culture of "Why should I upgrade? I haven't for 4 years and its working fine".

It annoys me how many people dismiss the Enterprise/Corporate environment as lazy/inertia/idiocy. That environment has a lot of unique sensitivities, one of which is COST. You need to demonstrate clear productivity gains to any business manager to make wholesale changes to an environment. For a web browser, it is VERY hard to demonstrate that during this life cycle, it makes sense to upgrade to a version that breaks intranet apps that will have to be replcaed themselves on some other timeline. A browser upgrade for most companies is pure cascading cost, with no tangible benefit to offset that cost. (IE6 is pretty close, because of vulnerability and patching cycle costs, but that is a well understood entity now, 9 years later, so not compelling for most.) Once IE8 gets major penetration, the argument becomes even less compelling.

In summation: It's the money, stupid.

To some extent, you do have a point... if your sticking point is internally developed apps that rely on IE6 and requires developer project hours to upgrade, yup it's going to cost you, and probably not just a little. The question is do you eat the cost now or later, because it's going to need to be done at some point, and the longer you wait, the bigger pain it tends to be.

If your sticking point is project time, 3rd party software upgrades, etc... then the budget is a much smaller point, and tends to get used as an excuse. Most big ticket software is licensed as a maintenance contract which covers upgrades. The admin's are paid to patch and maintain the software, and their time is a fixed cost & it's a matter of just finding project time (which can be a major issue in and of itself). And frankly, if you don't have internally built legacy IE6 stuff... yell at your vendors for the latest version, quit whining and just get it done.

The bigger picture though, is that every environment is different... my statements are generalizations from working as an admin in a half dozen corporate environments and dealing with budgets and bureaucracies there - everyone's got their own unique situation though. Sure, budgets are a concern, but if people actually want to get the job done, it's rarely as big of an issue as people make it out to be... and in this case, a browser upgrade isn't *that* difficult, can easily be done in stages, and barring internally developed software, it only costs support time.

I wonder if Microsoft has ever considered a 'plug-in' system that would allow launching selected addresses in IE X, where X is 6 or 7 (8 in the future) - legacy versions. I use the IE Tab (now Coral IE Tab) add-on for Firefox, though I find less use for it as time passes, and it could behave in similar fashion. Such a beast might be a bear to develop initially, but would then allow them to move ahead more quickly with newer versions, and might ultimately be less burdensome than the never ending 'compatibility' modes that muck with rendering and/or translations. Let the legacy engine render it, but in the same UI framework as the latest and greatest, installed version. Of course, it would require coexistence of multiple versions of IE on a given machine, but that seems manageable (in my mind, at least). Wouldn't that answer some of their critics, and/or address some of the legacy support issues that are, obviously, a major problem here?

Have you ever seen those intranet applications or worked in IT for a corporation?

99% of those don't do anything special --some reports, a workflow engine, some lame ass CRM, some CMS etc--, nor are they easy to break with a change in rendering engines. Actually, most of them don't even use Javascript. The worst offenders are those based on ActiveX, but that is not a web standard.

Anyway, MS could easily include a *frozen* IE6 engine for legacy corporate use and start shipping a modern, frequently updatable browser like the rest of the world.

I work as a consultant, so I've seen more than a few IT departments and Intranet apps, so the answer to your question is Yes.

I don't doubt that many of the web applications in question aren't particularly complex, but quite a few are (the ones that tend to be developed by outside vendors, for example). And while a change in rendering engines *probably* won't break anything, when you're talking about production applications (or even worse, mission critical ones) you have to be absolutely certain before you upgrade. I've been in situations where Microsoft patches (for IE6 in the instance I refer to) broke mission critical functionality - it wasn't pretty.

Because of this risk, each new browser release that is deployed requires extensive testing prior to roll-out, and as you can imagine, that gets very expensive in terms of man hours - as a result, most IT departments don't want to do frequent roll-outs of anything. Why do you think so many companies are still running IE6?

It simply makes more sense to develop for web standards. Your site won't break years from now, and it can be viewed fine on different platforms. Why would you want to tie an application to ONE version of an OS or piece of software if you have the option not to? It makes better technical and financial sense to develop for something that's longer lasting, in this case W3C standards.

W3C standards like html5, that aren't finished and will probably change? Yea great idea..either way the situation is not good, I just dispute that it's MS' fault and MS' alone. Why can't they ratify these standards in a timely fashion, for one?

I didn't say HTML5. Try HTML 4 or XHTML 1, which most every decent developer codes for NOW. Do those instead of ActiveX, proprietary IE-only bullshit and you're set. Sites I made in 2005 still worked great in everything but IE7. IE6 looks fine because I built it with an LTE-IE6 stylesheet at the time. IE7 broke some things that I had to go back and fix. IE8 finally adhered to basic CSS2.x standards so I was set there.

The next IE9 Platform Preview should include hardware accelerated HTML5 video (the current one doesn't, but the version demonstrated at MIX last week did, so we know it's coming). Current browsers (with stable support for HTML5 video) don't have hardware acceleration. But, on Windows at least, they can add it. And they probably will add it, and will almost certainly beat IE9 to market.

===

Firefox and Chrome will not get hardware accelerated HTML5 videos, unless they took a leaf from Safari's playbook and use operating system supplied codecs.

It simply makes more sense to develop for web standards. Your site won't break years from now, and it can be viewed fine on different platforms. Why would you want to tie an application to ONE version of an OS or piece of software if you have the option not to? It makes better technical and financial sense to develop for something that's longer lasting, in this case W3C standards.

The problem is that web standards have been and are now woefully underequipped to truly qualify as standards. They leave many behaviors up to the implementors, etc. I have seen "standards compliant" code do three different things in three different browsers. So people elect to do "dumb" things like mandate that all internal apps are tested on browser X and everyone will use browser X. This is the fault of the standards, not the folks using tools which happen to try to implement them.

So yeah, it's a big deal when browser X is updating semi-annually, retiring support (if any existed) after a year for v.previous, etc, and it just happens to break one of your critical apps (which, incidentally, were written by consultants, not in house, and so are not trivial to upgrade). What do you do now, when "standards compliant" code/markup is now generating errors?

Also, "standards compliance" requires standards that are not moving targets. Neither HTML5 nor CSS3 meet that benchmark in their current form. You could trivially find examples of "standards compliant" HTML5 for 12-18 months ago that are absolutely broken now because of changes. Telling corporations (who frankly do not care about HTML5) that they need to hire somebody in-house and keep up with the stuff so it will some day work across all browsers and they can eventually get rid of that guy is not going to get you anywhere. They didn't want to hire the guy or deal with the mess in the first place. That's why they bought into a stable platform with at least marginal gaurantees about backwards compatibility.

Also, "standards compliance" requires standards that are not moving targets. Neither HTML5 nor CSS3 meet that benchmark in their current form. You could trivially find examples of "standards compliant" HTML5 for 12-18 months ago that are absolutely broken now because of changes

Which is why, reasonably, MS is sticking to those standards that are fairly advanced in their development process; ones that are unlikely to undergo any substantial alteration.

<quote>Where is the mention of the corporate/enterprise consumer who wants to write apps targeting a browser platform and not be worried about perpetual upgrade cycles breaking their apps on a semi-annual basis?</quote>

Corporations that are relying on 10 year old systems to manage their business processes are going to die. These information systems are their crown jewels, and they are letting them wither away and die from neglect. More agile businesses with the foresight to take care of the technology that keeps then going will eat their lunch.

There is going to be a new gold rush once big businesses realize that these systems can now be secure, hosted services based on web standards. See the recent Google Apps announcement. There are also going to be a lot of people out of a job as these crappy in-house systems and the people who support them start to get thrown out.

We finished switching to Vista, and thus IE7 company wide almost three years ago. We cannot deploy IE8 or Windows 7 because the version of Oracle E1 that we are currently using does not support IE8. Does it work in IE8? Yup, we haven't found anything that breaks it in all our testing. But if we upgrade to it we get no support from Oracle and the business will not accept that risk for the companies ERP system. Only way we can get IE8 support is to upgrade off a currently supported version of E1 that we have deployed to a newer platform, which according to finance group will take ~3-4 months of effort and resources aren't available for another 12 months to do that.

More often that not I've noticed at work and with other collegues in IT it isn't laziness or even poorly designed corporate intranets that are typically prevents IT departments from upgrading, but the third party products that don't support the newer browsers and the business cannot risk being in an supported state that prevents it. OA non-browser example is one of our other business units ERP's still haven't certified SQL 2005 SP3 so we have to leave that server with SP2, which is now unsupported by MIcrosoft, but being unsupported from the non-MS vendor is the worse situation according to the business so we can't update it.

It sucks, but it's far more common than people realize. We're in a better spot being on IE7 rather than IE6, but it will be 6-12 months I bet before we see traction on IE8 at the earliest, yet alone IE9 when it comes out.

Also, "standards compliance" requires standards that are not moving targets. Neither HTML5 nor CSS3 meet that benchmark in their current form. You could trivially find examples of "standards compliant" HTML5 for 12-18 months ago that are absolutely broken now because of changes. Telling corporations (who frankly do not care about HTML5) that they need to hire somebody in-house and keep up with the stuff so it will some day work across all browsers and they can eventually get rid of that guy is not going to get you anywhere. They didn't want to hire the guy or deal with the mess in the first place. That's why they bought into a stable platform with at least marginal gaurantees about backwards compatibility.

As a consumer auto-update is fantastic. No more ma and pa issues, things Just Work. Probably that'll be just dandy also for most businesses. Except, you know, those that have web-based mission critical applications.

What MORON at a large corporation would recommend to their CTO/CIO/CEO their business should be at risk due to an unstable production environment?

Chrome is a pain-in-the-butt because it happily breaks Windows installation guidelines and installs itself in user-directory land (not system control \Program Files). This is wonderful for google, increases uptake, except when it causes confusion in user-land because it's not IE. Think a Citrix environment where all of a sudden everyone can see a Chrome icon, but can't run it because it's installed in x:\user\ somewhere.

To Mr Bright, you're right on many points, but you're wrong about more frequent releases. Business don't give a poop about latest technology, we just want to make money with the least possible cost -- upgrading our systems For No Gain except for giving the IT dept's geek horn a quick tug is dumb.

Another point, Ars Technica is naturally a tech-savy environment and its readership reflect this. But before making statements about the Real World, writers like Mr Bright should take a second to think about Jo and Jane Average who just don't care and want to do their job today like they did it yesterday.

It simply makes more sense to develop for web standards. Your site won't break years from now, and it can be viewed fine on different platforms. Why would you want to tie an application to ONE version of an OS or piece of software if you have the option not to? It makes better technical and financial sense to develop for something that's longer lasting, in this case W3C standards.

The problem is that web standards have been and are now woefully underequipped to truly qualify as standards. They leave many behaviors up to the implementors, etc. I have seen "standards compliant" code do three different things in three different browsers. So people elect to do "dumb" things like mandate that all internal apps are tested on browser X and everyone will use browser X. This is the fault of the standards, not the folks using tools which happen to try to implement them.

So yeah, it's a big deal when browser X is updating semi-annually, retiring support (if any existed) after a year for v.previous, etc, and it just happens to break one of your critical apps (which, incidentally, were written by consultants, not in house, and so are not trivial to upgrade). What do you do now, when "standards compliant" code/markup is now generating errors?

Also, "standards compliance" requires standards that are not moving targets. Neither HTML5 nor CSS3 meet that benchmark in their current form. You could trivially find examples of "standards compliant" HTML5 for 12-18 months ago that are absolutely broken now because of changes. Telling corporations (who frankly do not care about HTML5) that they need to hire somebody in-house and keep up with the stuff so it will some day work across all browsers and they can eventually get rid of that guy is not going to get you anywhere. They didn't want to hire the guy or deal with the mess in the first place. That's why they bought into a stable platform with at least marginal gaurantees about backwards compatibility.

Read several posts up. I said developers are coding now for HTML 4 and XHTML 1, which are not drafts anymore, and should continue to do so vs. ActiveX or any other proprietary, vendor-locked method (esp intranet developers). That's my argument. Please provide a clear argument of why modern developers should code for a single browser now that will be outdated in 5 years, unsupported in 10. It will be history repeating itself.

If you stick to something like Google's Blueprint CSS framework, Yahoo/Meyer's Reset, and/or a ZEN 3-column layout, etc... paired with a nice JS framework there's a really good chance you won't run into the issue IT staff has now of sticking to a 9 year old browser because their horribly crippled internal app uses non-compliant code that breaks in modern browsers. And in the distant future if there's a layout issue just hire a competent firm to do some touch ups. 2-3 hours of work and it's running like new again.

I see your argument but like I said before, I've built things 5 years ago using standards compliant code at the time that currently works in all modern major browsers.

In my experience I bet that in 80% of these IE6-only cases corporations outsourced their intranet work to some company that farmed THAT out to shops in India. This process is very rampant with shops both big and small. It works, and hey, it was uber cheap. But it will end up causing headaches in the long run due to all the horribly written code.

As a consumer auto-update is fantastic. No more ma and pa issues, things Just Work. Probably that'll be just dandy also for most businesses. Except, you know, those that have web-based mission critical applications.

Only if those applications target specific versions of specific browsers.

Which isn't the best way to develop such applications, and isn't the best way to support such applications. Businesses should be demanding applications that'll work in a range of browsers so that they're not trapped on obsolescent software.

IE6 is less secure than IE8. Windows XP is less secure than Windows 7. Windows 7 has a range of business friendly features, especially for mobile users (better VPNing and BitLocker, for example). It seems entirely plausible that switching to 7 would reduce cost of ownership. Businesses letting themselves get trapped on IE6 are doing themselves a huge disservice.

But even then, they should be using MED-V to redirect those lame, broken web apps to use IE6 in a VM, and use something modern for everything else. I think the tools are there. Perhaps they weren't a few years ago, but they are today. There's no reason to retard your entire desktop infrastructure just because you're stuck on IE6.

Really, it amazes me. Getting locked in to IE6 is a huge problem, and so what to businesses want to do instead? Lock themselves into IE7 or IE8. How does that represent progress or smart decision-making? You might argue that they didn't know what they were doing back in the IE6 days, but they sure as hell do now. They know that this kind of lock-in ties their hands. They know it means that they suffer with products dropping out of mainstream support. Sometimes even dropping out of extended support. Sometimes even forcing the use of known-exploitable software.

This stuff is obviously bad for businesses. Demanding support for modern standards, and demanding that applications use those standards isn't just good for consumers: it's good for businesses too.

And like I said before, if MS starts keeping pace with Firefox, Opera, and Chrome, it's not like businesses can defect to some other vendor offering long-lasting stable browsers. Apple's not an option either. The development from IE 3, to 4, to 5, to 5.5, to 6 was pretty rapid; businesses had to like it or lump it. The web may be more important now than it was then, but that's all the more reason to avoid being locked in to legacy anachronisms.

We finished switching to Vista, and thus IE7 company wide almost three years ago. We cannot deploy IE8 or Windows 7 because the version of Oracle E1 that we are currently using does not support IE8. Does it work in IE8? Yup, we haven't found anything that breaks it in all our testing. But if we upgrade to it we get no support from Oracle and the business will not accept that risk for the companies ERP system. Only way we can get IE8 support is to upgrade off a currently supported version of E1 that we have deployed to a newer platform, which according to finance group will take ~3-4 months of effort and resources aren't available for another 12 months to do that.

Excellent point. Those of you claiming that businesses are lazy should re and then re-read this.

Yes, the vendors who impose these sorts of compatibility barriers are businesses too, and yes it would be nice if they would get in tune with current browsers sooner rather than later. (Really nice, are you listening Oracle?)

But the underlying issue is that these changes cost time and money. Somebody somewhere is paying for all your browser upgrades, and it's not always the likely suspects (browser makers). And they are passing those increased costs on to their customers.

I'm getting tired of this whole "big IT" argument about big corporations needing their web applications to work with IE6 and how they can't handle fast upgrades. IE7 came out 4 years ago, they've had plenty of time to update their systems. It's their own fault for being either too greedy, or too lazy, or too ignorant to update.As for worrying about frequent updates breaking stuff. If the applications are written properly with standards in mind, and if MS executes the updates properly then nothing is going to break, that's the whole point of standards. And in the very worst case there will graceful degradation.

Fact is, that argument is just an excuse for companies to avoid the costs of a system wide upgrade. Well you know what? Suck it up! Progress costs money, but without it we'd still be riding horses and dreaming of flying machines.

I think a lot of it has to do with how IE releases were tied with Windows releases. IE 6 was tied with XP, IE 7 was tied with Vista, IE 8 was tied with Windows 7. In fact, MS announced in 2003 that future versions of IE would not be available for previous versions of Windows. MS made good on that promise next year with IE 6 in XP SP2 with it's enhancements and new features, then later in the same year Firefox 1.0 was released, and then next year MS was forced to back off on that and release IE 7 for XP SP2 as well as shipping it with Vista. After shipping IE 8 with Windows 7 and released it for Vista as well as XP, now MS is announcing that IE9 will only support Vista and later and not XP.

We finished switching to Vista, and thus IE7 company wide almost three years ago. We cannot deploy IE8 or Windows 7 because the version of Oracle E1 that we are currently using does not support IE8. Does it work in IE8? Yup, we haven't found anything that breaks it in all our testing. But if we upgrade to it we get no support from Oracle and the business will not accept that risk for the companies ERP system. Only way we can get IE8 support is to upgrade off a currently supported version of E1 that we have deployed to a newer platform, which according to finance group will take ~3-4 months of effort and resources aren't available for another 12 months to do that.

Excellent point. Those of you claiming that businesses are lazy should re and then re-read this.

Yes, the vendors who impose these sorts of compatibility barriers are businesses too, and yes it would be nice if they would get in tune with current browsers sooner rather than later. (Really nice, are you listening Oracle?)

But the underlying issue is that these changes cost time and money. Somebody somewhere is paying for all your browser upgrades, and it's not always the likely suspects (browser makers). And they are passing those increased costs on to their customers.

Those are good points and in this case I can't blame the company of course. However, those problems have been created exactly because of MS's way of handling browser updates in the first place. By releasing major upgrades every 3-4 years and supporting older browsers for another 3-4 years they've created this kind of situation where everybody is worried that switching versions would break everything and nobody is willing to take the risk. On the other hand if they had more frequent smaller upgrades, with more "organic" progression of features, and bug fixes then corporations would adjust their upgrade practices accordingly and would naturally follow IE with maybe a few months delay. It's always easier (and less scary) to make frequent but small changes, than large infrequent ones.

So now of course what's done is done and we're in this situation, but somebody has to break the cycle and of course it has to be Microsoft. Companies however have to also be prepared to make bold moves. Take the above one for example. I obviously don't know the whole story but given the information at hand it seems that the company will always be 4-5 years behind the curve as it were. Because if they wait the 12 months then take another 4 months to switch to IE8, by the time they do IE9 will be out and the web in general will be even further ahead. Add to that the fact that the longer things stay the same the harder it is to change them, and the company is running a real risk of basically falling further and further behind every year. Maybe not for this, but for other similar companies it may also mean loosing profits as customers switch to more modern systems. In the long run it may very well cost them more to delay upgrading their systems than what it would cost them to switch up the schedule and speed up said upgrade. (and again, the specific case maybe different, but many companies find themselves in situations like what I described)