Infrequently Noted

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

Progress Is N+1

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

Updates and Dojo 1.1

SitePen Launches Dojo Support Service

SitePen has been building an amazing team and today we're bringing a little of that team to a lot more of the Dojo world.

As part of the relaunch of, we've unveiled our new support offerings (the available packages are here). For some time now SitePen has been offering consulting to firms using Dojo, and we've recognized that many of our clients aren't prepared to engage us for a consulting engagement but need more than an intensive training session for their teams. In this middle area lies the need for a support product which can help capable teams get un-stuck quickly when the going gets tough. Other customers have expressed a strong desire for professional support due to their enterprise's nascent experience with Open Source, and for them we've built "lightweight consulting" into the Enterprise plan to help get architectural issues addressed in addition to handling pressing fixes.

SitePen is adding this support product to our already successful application development and Dojo/DWR training businesses. Since we're also building apps, we know how important it is to have the right person an email or phone call away. Support is a logical progression for us as a company and for Dojo as a project, and we're committed to doing it right. Everyone we've assembled to provide support to our clients are committers on the projects we support (sharp tacks, all) and as we described recently at DDD the plan for SitePen's support business is designed to help us improve the toolkit at every opportunity. Right there on the page describing the packages you can see our commitment to keeping Dojo a healthy Open Source project:

When you find an issue with Dojo, DWR, or Cometd, we...provide you with emergency bug fixes. We also commit these patches back to the relevant open source project as appropriate.

SitePen has also recently been working to help ensure that Dojo's API documentation tool is top-notch and that the introductory material for getting started with Dojo are solid, all of which we'll be releasing in the coming weeks alongside the release of Dojo 1.1. In all of the support team discussions, it's been clear to me that everyone involved gets it: not only are we here to support our customers, we're here to make Dojo and DWR better for everyone in the process. It's the kind of positive feedback loop that only happens when you have the right people on the bus and when the whole business understands the real value of Open Source both to customers and to the community.

Speaking of making things better, we're convinced that the last thing you need when working with our support team is a headache. The support UI has to be as easy-to-use as it is good looking, so we’ve built a custom support interface that lets customer submit tickets, check the progress of ongoing ones, and use completed tickets for reference. Check it out:


I just landed in Vegas where i'll be for the next several days at Mix '08. I'm looking forward to hearing more about what the IE team has in store for IE 8. I've got a whole stack of questions and they've promised a frank discussion without any pre-conditions or NDAs. This oughtta be good. If nothing else, it will tell us how far retracted the IE Cone Of Silence (TM) is. I've got hope, but I've been teased before and despite an impending Beta, there's precious little to go on about what IE 8 really will and won't be (or even when).

I'm not a gambler, and generally don't like Vegas, which makes me all the more excited to be going to SxSW directly from MIX. I haven't been in a couple of years, but Dylan has been keeping the annual Dojo Salt Lick field trip alive, and I'm excited to be able to be able to join the rest of my (mostly Silicon Valley) compatriots in stumbling around Austin under the influence of Shiner and BBQ. If you're also going to be in Austin (at SxSW or not) and want to join us in our trip to BBQ Mecca, just RSVP and let us know how many you intend to bring and whether or not you can drive others.

Oh, and there will be an auspicious panel wherein authors of successful JavaScript libraries will all thank John for doing the work of proposing a panel and therefore ensuring that we all have an excuse to come to Austin to drink Shiner and eat BBQ. The last time I went to SxSW I hosted a panel with some of the smartest people I know and it went over like a lead brick, convincing me once and for all that SxSW is the Jerry Springer Show of technical conferences and that the point of panel discussions there is to stir shit up. It doesn't even matter what it is...everyone else there is nursing the same mild, Shiner-induced hang-over and if they really cared about technical content...well, they would have gone to ETech.

If you're going to either MIX or SxSW, let me know! Conferences are always more fun when you know the Hallway Track is going to rock.

Update: there's much to say about MIX now that it's over and IE 8 is in our hands, but apparently we've communicated about the Salt Lick thing very poorly. While we'd love it if you'd RSVP to rsvp at dojotoolkit dot org if you're joining us, what you really need to know is when and where. Namely:

8pm, Sunday March 9th
The Salt Lick
18001 FM 1826
Driftwood, Texas 78619

Remember, it's BYOB and if you RSVP we can help coordinate rides and such. Looking forward to seeing you there!

Keeping Up

The Dojo community is going at a clip that I can barely follow these days. Notably:

That and a whole lot more comes over the transom via Planet Dojo. Big props to Peter for keeping on top of things an adding new feeds to the Planet as they emerge.

Update: One more for the pile! Tony Issakov's Dojo Findings blog is worth a read/add, particularly as he's digging into Dojo+Jaxer

Older Posts

Newer Posts