Ten Reasons Why IE6 Development is Significantly Better in 2010 than 2001 (But Still Painful)

This post mentions IE6 everywhere, but it’s not about IE6 at all. In my standard rant on the three ages of web development, a standard sub-rant is our improved ability to develop on IE6:

Although it was created back in 2001, we could do far more with it in 2004 (e.g. Google Maps) than we could in 2001, and we can do far more with it in 2010 than we could in 2004.

I cite the 3,286 day old application as an example because it’s the one browser that’s still around and still must be targeted by a significant number of developers (despite the best intentions of even MS employees to “drive a stake into IE6s heart”, and thankfully, the number is starting to dwindle). It’s the 120-year old who’s witnessed the transition from horse-and-cart transportation, to men on the moon, and is still here today to speculate on the eagerly awaited ChatRoulette relaunch. We could ask how effective Netscape Navigator development is in 2010, but since no-one actually does that, any answers would be hypothetical. IE6 is something many people worked with pre Ajax era and something some people still work with post Ajax, so it’s a specimen that can be used to show how Ajax changed the world.

(You could do this kind of analysis for any platform, e.g. the design pattern phenomenon means that you would approach a C++ app very differently today than you would have in 1987, even with the same language and compiler.)

In the Ajax era, we made like engineers and got smart about how to do the best we could with the laws of physics our universe imposed on us. (Versus the new HTML5 era, where we build a better universe.) I decided to make this post to be a bit more explicit about why IE6 development is significantly better today than when IE6 came out. And by “better”, I mean faster and more powerful, if still a slow, frustrating, and not-very-powerful development cycle compared to the modern browsers.

With no further adieu, IE6 development is better today than in 2001 because …

10. Libraries If only we had jQuery in 2001. If only …

9. Knowledge JavaScript was allegedly the world’s most misunderstood language in 2001. Now it’s well-understood, good parts and bad. And so is the DOM. An abundance of blogs, forums, books, and conferences.

8. Patterns We not only know how Javascript and the DOM work, we have idioms, patterns, and best practices for putting it into action.

7. Performance IE6 is orders of magnitudes slower than today’s browsers, so managing performance is certainly important, and these days, we know much more about how to make web apps run faster, thanks to the efforts of Steve Souders et al.

6. Tools Tools from MS and others have come along over the years to improve the development experience. Firebug or Webkit Devtools they are not, but at least IE6 debugging is more than just alert boxes these days.

5. Developers, Developers, Developers Finding savvy web developers these days is vastly easier than it was pre-Ajax, when front-end development was a black art.

4. Show Me the Source We now have plenty of examples to learn from, both online, where View Source is your friend, and in the open source code repositories of the world.

3. Browser Mechanics We understand the quirks of each browser much better now, and that certainly includes the many well-documented quirks of IE6 and how to deal with them.

2. Attitude Those examples also overcome the psychological barrier, a key impediment to IE6 development. In the absence of any decent examples, it was easier for developers to shrug their shoulders and say it’s all too hard. If that sounds too mystical, see 4 minute mile. “Ajax” is more than a set of technologies, it’s also the recognition that these kinds of apps are possible.

1. Development is Just Easier These Days. No matter what kind of development you’re doing, development is just easier in 2010. Blogs, Forums, Twitter, Code Repositories, etc are improved, so this will impact on IE6 development or any other form of development, though there’s a law of diminishing returns here.

IE6 development is still a tough effort and thankfully becoming less of a requirement as people shift to modern browsers, or at least IE8. You know a browser is on its way out when “because employees are less likely to use Facebook” is one of its most compelling advantages. The Ajax era had a profound effect on the way we develop and what we know to be possible, but that era is mostly over, and that law of diminishing returns is kicking in hard. Hence, we make a new, better, platform to keep progressing what’s possible.

Will the rush of HTML5 work make IE6 development in 2020 even more doubleplusgood than in 2010? Not really. There will be a few odd improvements, but overall, HTML5 is about improving the platform, which means developers will increasingly be focused on doing things IE6 will thankfully never even try to do. The HTML5 world subsumes the Ajax world, so you get the double benefit – all of these ten Ajax benefits multiplied by all of the new features of the platform.

3 thoughts on Ten Reasons Why IE6 Development is Significantly Better in 2010 than 2001 (But Still Painful)

  1. Pingback: Ten Reasons Why IE6 Development is Significantly Better in 2010 than 2001 (But Still Painful)

  2. I admire your attempt at putting lipstick on a big, but sheesh what a load of hooey. Your entire list boils down to, “there’s a bigger/better community of developers suffering alongside you,” which hardly qualifies as “significant” improvement.

    Significant improvement would be something that offered tangible change in the core development experience – service pack releases to add much-needed standards support, a major version release of the never-improved script debugger, something – but that never happened. A project that wants to support IE6 today will still spend at least half their resources getting IE6 to work, just like they had to 10 years ago. All that’s changed is that IE6 is 2% of the market instead of 60%, so it’s easier to convince the boss to drop support for it.

    In fact, a more believable list would be why it’s harder, not easier, to develop for IE6:

    • Expectations have risen. A site that would have wow’ed users and executives in 2001 is boring and unsatisfactory today.

    • Standards have evolved. The widening gap between what IE6 can do, and what standards bodies are (de facto) demanding of browsers is growing every year. And there’s only so much that library developers can accomplish. (e.g. canvas support). SVG, WebGL, CSS3, HTML5… these will eventually be what puts the stake in IE6’s heart.

    • Development cycles are shorter. 10 year ago, a 6-12 month release cycle was common place. Now, companies expect developers to build and release sites in weeks, not months. But it still takes a painfully long time to test and debug IE6. Even if it’s improved in some absolute sense, in relation to the project cycle, it’s gotten worse, not better.

    • Diminishing community. The counterpoint to what is essentially the underpinning of all your arguments: fewer and fewer library developers are willing to crucify themselves on the IE6 cross for the sake of checking the “supports IE6” box. As support in 3rd party libs tapers off, it’s just going to get harder and harder.

    I could probably come up with another 6 points, all based on the “diminishing community” premise, to match the 10 in your list, but I’m sure you get the point.

    Nice try, but you didn’t really pull this one off I’m afraid.

  3. Your entire list boils down to, “there’s a bigger/better community of developers suffering alongside you,”

    How are libraries, knowledge, patterns, performance, tools, and most of the rest of the list equivalent to the community.

    “Expectations have risen.” is not really the point, because I’m talking about delivering the same app in 2010 as you did in 2001. To which you’ll say, “but no-one wants the same app”, to which I agree, but this is not a post about IE6, it’s a post about evolution in web development.

    Nice try, but you didn’t really pull this one off I’m afraid.

    Thanks, but what didn’t I pull off exactly? Lipstick on a pig? That was never the point.

Leave a Reply