Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Story Time!

Web developers tell each other stories about browsers that just aren't true. Consider the following archetypal argments:

It's not hard to support IE because I have [ progressive enhancement | javascript libraries | css tricks ]
Everyone using IE 6 should upgrade. Sheeesh! Anyone running an old browser is doing it all wrong, and how hard can it really be?
Nice theory about not developing for old browsers, buddy, but I can't afford to stop supporting bad browsers and neither can anyone else. This is life on the web, suck it up.

These are the fables we tell each other to help explain a complicated world in self-affirming narrative form. The first boils down to "I can do it!" while the second is "I don't have to do it". The third is an argument about platform reach and the compromises you need to make to get your content everywhere. All are too simple, and all are insidious.

The first argument -- "I can do it!" -- is a coping mechanism gone too far. Should we always be building semantic markup that degrades well, works in down-rev browsers to the extent it can, and trying to fill in the potholes in the road with progressive enhancement? You bet. But lets be clear: the sorts of features that it's going to take to keep the web a competitive platform require new semantics. We need the browser to expose new underlying stuff that can't be faked.

For example, tools like excanvas, dojox.gfx, and Raphaël let us draw vector graphics everywhere.

Do not mistake a little for a lot.

These tools, possibility expanding as they are, can't give us the order of magnitude improvements we will get out of GPU accelerated 2D and 3D contexts. If you build with the constraints of the old browsers in mind using tools designed for them, you won't be building the same sorts of things you would be if you could assume otherwise. Consider the costs: Instead of writing a little bit of script to deal with a <canvas> element directly, you now assume a sizable JavaScript library that adds overhead to each call, not to mention the overhead in latency to download that script. That's to say nothing of the sorts of things you won't even attempt because your wrapper doesn't support or because you can't do enough operations per second on legacy browsers.

The next argument -- "I don't have to do it" -- ignores upgrade costs. I've written about this at eye watering length. This perspective has two common sources: looking at a small sliver of the browser market (e.g., mobile), and incomplete accounting of the costs involved in upgrades. Looking at only one part of the market is actually sane in the short run. Building for only one part of the market makes sense, so long as you can take out insurance (e.g., standards) that will help guarantee full market coverage over time. This is the most hopeful story in the whole HTML5 debate to me. You can focus (variously) on mobile, tablet, or Chrome Web Store and never leave the HTML5 bubble. And it gets bigger every day: IE 9 soon, new versions of every other browser even sooner, GCF, etc. As for the folks who can't understand why IT departments might not jump at the chance to throw out something that's working and/or might not be keen on user re-training...I've got nothing. Things that are costly will happen less. That's life. Also, please don't assume that by flagging these costs, I'm "excusing" organizations that are running IE6. It's a needlessly adversarial connotation. We need instead to explain reality as it is and find ways to move toward "better" from there. That's why I work on Chrome Frame. You might not agree with the approach, but the economic problem is real and we need a solution.

Lastly, the jaded realist. This is a perspective I know well. I wake up many mornings feeling this way, and who wouldn't after most of a decade spent trying to make browsers do things they were never designed to? What this story writes out, though, is any discussion of how we might improve the situation. It's easy to do. Focusing on the next month, or even the next year, you might get the sense that the browser landscape is more-or-less fixed. Hell, browser stats move in terms of less than a percent a month. But we'd be wrong to assume that slow is zero and that because things are slow now that they must be in the future. So to all you hard-bitten realists out there: I get it. I know what you mean. You don't have to believe that help is on the way. I only ask that when it arrives, you take just as much ferocious advantage of the new reality as you do of the current one.

The web is moving again -- finally -- and if we can find clear ways of thinking about the future, we can find easier paths to getting there. Focusing on the economics of browser adoption gives us a way to integrate all of these fables into our theory of the world, explaining them and showing their strengths and faults. It's for that reason I'm hopeful: approaches such as focusing on mobile and tools like Chrome Frame address the root causes of our mire, and that's something new under the sun.

Hoisted From Other People's Comments

Humorous quote over at the hacker news thread on the previous post:

by seldo:

This complaint is as old as the hills. You may as well slap an obnoxious "Designed for HTML5" button on your site. The cost of having the world's largest addressable audience of any development platform is that web developers have to deal with the fact that it varies a lot. Them's the breaks.

Edit: because I hate comments that are purely negative, my suggestion for getting users to the latest technologies is to use libraries (like YUI and jQuery) which do the hard work of implementing newer features in backwards compatible ways, but use the modern feature if it's available...

Wish I'd thought of it earlier.

Older Posts

Newer Posts