Not sure how I got there, but I just stumbled over this bit of dark humor at Joel Spolsky’s expense, and in reading it I was reminded of a discussion last Friday where I voiced my frustration that as much as IE 8 looks to be a good point release, we know next to nothing about it’s intentions with regards to ship dates or auto-update deployment. I’m not talking exact dates or firm plans here, just “within the next N months” or “we’ll wait N (plus or minus 3) months to put it on Windows Update”. Knowing those things fill in the missing bits of making any plans around IE. No plan is complete without a “who”, a “how”, and a “when”. Right now we’ve got the first two bits (ish), but the third is a mystery….which means we don’t have a collective plan.
By the transitive property of IE being the monopoly market-share browser, we can clearly state that we have no idea when the Open Web will be revved. This is based solely on the IE team’s lack of commitments. This is a terrible result, and one which I think the frenzy over IE 8’s features has obscured.
Joel’s article and some of Mark’s commenters make it obvious that there’s now a gap in the expectations of some devs about what it means to be a web developer versus what it meant 4 or 5 years ago. Back then we all assumed that browsers would get better, or at least different. There was bitter complaining about how incompatible everything was and how horrid it was to have to update everything…but underlying that discontent was the assumption that the web would keep changing. Web developers have to a great extent lost this assumption and I see a lot of the acrimonious discussions about new browser features in this light. There is great fear on the part of the web development community that progress will cost something, and they’re right. So long as we’re only talking about one revision, the cost looks new and surprising, but if we were to start talking about how we’d keep revving the web, those costs could be assumed by all parties again. It’s for this reason that I posit that the most important thing about IE 8 won’t be any of its features…it’ll be that it ships soon-ish and goes out to auto-update (if that is indeed the plan, which we don’t know).
The analogies that Joel brings up about standardization are perhaps valid if you take a snapshot in time of features vs. conformance. What happens in the browser world, though, is that things where were only marginally possible with old features become the norm via new features. New tags or CSS rules get added which make what was hard simple, if less flexible. In that process, we find that we need strong agreement on the behavior of those “mainline” things, while it’s perfectly OK for browser vendors to disagree about the fringes. Those fringes, after all, are were new things should be getting developed and introduced for market testing. It’s only when new things don’t get introduced and that broad agreement isn’t forged and “full” standards conformance comes into the fore. We need 100% standards conformance for all the nit-picky corner cases when those are all we’ve got in the way of “new” platform capabilities. Joel’s view of the world doesn’t take into account healthy evolution and improvement based on real competition. Competition makes suppliers responsive to customers and gives a real path for evolution. Standards make suppliers responsive to proxy bodies who are easily distracted.
IE and all browsers are as much a platforms as applications, but browser vendors get themselves into strange positions with regards to the platform bits of their products. Since browsers are positively differentiated by their chrome and not their engines, you can think of renderers and script engines and all the things that webdevs care about as costs of doing business for a browser-producing organization. Insofar as they make money, they do it on chrome, not rendering. Of course, getting into the good graces of web developers is great for a browser maker, but getting in front of users is the only real metric of browser success and to get there one only needs a renderer that’s on par with the others. You can’t positively differentiate a browser by making it more standards compliant or even by introducing new and awesome non-standard features. Those things can have strategic value, but they can never stand on their own.
Which brings us back to IE being a platform. The bits that webdevs care about must change in order for the web to get better, and today webdevs are platform customers without a commitment from their biggest supplier to ship another version beyond the one they’re working on now. If this were any other sort of platform, this would never ever fly. Code-in-escrow would be demanded along with a roadmap, or at a minimum a commitment to an N+1 version in a reasonable time frame. But webdevs don’t have that leverage by virtue of the disintermediation that browser economics now demand.
So as webdevs, we must be canny enough to find a way to “better” which doesn’t put all of our eggs in any particular basket. Every browser that we depend on either needs an open development process or it needs to have a public plan for N+1. The goal is to ensure that the market knows that there is momentum and a vehicle+timeline for progress. When that’s not possible or available, it becomes incumbent on us to support alternate schemes to rev the web faster. Google Gears is our best hope for this right now, and at the same time as we’re encouraging browser venders to do the right thing, we should also be championing the small, brave Open Source team that is bringing us a viable Plan B. Every webdev should be building Gear-specific features into their app today, not because Gears is the only way to get something in an app, but because in lieu of a real roadmap from Microsoft, Gears is our best chance at getting great things into the fabric of the web faster. If the IE team doesn’t produce a roadmap, we’ll be staring down a long flush-out cycle to replace it with other browsers. The genius of Gears is that it can augment existing browsers instead of replacing them wholesale. Gears targets the platform/product split and gives us a platform story even when we’re neglected by the browser vendors.
Gears has an open product development process, an auto-upgrade plan, and a plan for N+1.
At this point in the webs evolution, I’m glad to see browser vendors competing and I still feel like that’s our best long-term hope. But we’ve been left at the altar before, and the IE team isn’t giving us lots of reasons to trust them as platform vendors (not as product vendors). For once, we have an open, viable Plan B.
Gears is real, bankable progress.
