Infrequently Noted

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

IE 8 is the new IE 6

Again: IE 8 is the new IE 6, following in the grand tradition of boat-anchor browsers. Who remembers NN 4.x's endless death dirge? This isn't about one browser or one version of one browser; it's about rate of progress.

I keep talking about the structural, economic causes that keep the web the way it is, and folks keep misunderestimating me -- some seemingly willfully.

Why, for a decade of experience, can we not seem to see the IE 8 zombie coming? It's not like it's going to be some big surprise that unless we do something different, we'll still be supporting it in 2015. That's right: in 2015, you'll still be thinking about a browser that doesn't support <canvas> or <video> and doesn't even have a JITing JS engine.

Yes, things will get marginally better when we can drop IE 6 & 7 support, but think about the new features that will be in Chrome, Safari, Firefox and IE 9+ for the years that it takes to retire Windows XP. Remember, IE 9+ won't be available on XP. Those features -- more importantly, the rate they're being introduced at -- are going to continue to make IE 8 look as plodding as IE 6 does to modern eyes. So why don't we see it coming? Why isn't this the topic of ALA and Ajaxian articles? Why isn't this the burning question at web conferences? Every MSFT rep and booth person should be asked the question: what are they doing about IE 8?

More to the point, as a web developer, what are you doing about IE 8?

Me, I'm developing for the future exclusively and asking users of legacy browsers to adopt a modern browser or install Chrome Frame. It's an uphill battle from here, but nobody is going to bend this curve but us.

Web 2.0 Expo NYC 2010

I've been in NY for the last 2 days, having a great time at the Web 2.0 Expo. Lots of folks have asked me for the slides and the lab zipfile, so there you are.

The browser panel was a lot of fun, thanks again to Ben and Dion's ability to get the right folks and ask the inconvenient questions.

I'm sad that I'll have to miss most of the conference, but it looks like HTML5/CSS3 has legs this year. Can't wait to see what happens.

"But IE 9 Is Just Around The Corner..."

The single most frustrating thing for me as a web developer is the incredible disconnect between day-to-day development and the shiny, shiny stuff showing up in HTML5 and modern browsers. It's made all the more frustrating by bold pronouncements from any (every?) vendor about how much more awesome the web will be thanks to the shiny stuff their upcoming release. The reality for web developers is that those features won't matter on a relevant time-scale. Not your next project. Not your next 5 projects. No, the lag today between new features and when you can use them might as well be measured in geologic time.

How bad is it? The next time you read some tech journalist write about how some new browser version is just around the corner and how it'll make everything better, remember that:

The goal here isn't to drive you to drink, but to call out the dichotomy between when users get features and when developers can address features. For users, things tend to get better as soon as you pick up a new browser. Developers have to wait until every user makes that sort of choice. Said differently, users can benefit from the bleeding edge but developers are beholden to the late adopters.

We should cut tech journalists and users a little slack, though; in a world without adoption friction, the launch of a new feature would translate directly into the sort of "now you can build sites and apps with awesome thing X". The instinct to believe that's how it should be is spot on. But that's observably not how the world works. Don't believe the hype. New browsers alone haven't fixed the problem so far, so what makes us think they will in future? No vendor wants to talk about their last version, but for web developers stuck in the trenches, that all there is to talk about. That's where the pain is, after all, and counting on browser upgrades to fix the problem quickly isn't working well enough. Chrome's aggressive auto-update feature is changing the way things will work in future, but for now we're still stuck in the slow-upgrade dynamic.

We need a Plan B.

Chrome Frame Now Stable!

Exactly a year from the original announcement, we've just launched a stable, ready-for-prime-time version of Chrome Frame (with MSI packages). In addition to heroic work by the whole team on improving GCF stability in the face of poorly written extensions, the biggest change in the Stable release is an astounding improvement in cold start performance (greater than 3x faster in many cases). Faster startups mean that your users wait less to experience a better web and that GCF is appropriate for a wide range of applications that can benefit from HTML5 features. Faster starts also mean that JavaScript heavy sites benefit even more from V8 since the engine can start running your code faster, sooner.

Like Chrome, GCF is on the 6 week release cycle, so expect features like per-user install and even faster starts that are arriving in the Dev Channel to become available quickly.

So what are you waiting for? Say no to legacy baggage and start saying yes to HTML5 and the future by adding the GCF header/tag to your sites and apps. It's nearly zero effort. When you're comfortable, you can add a prompt and free yourself to build sites and apps against only the modern web. When you do, you'll see how fast and productive web development can really be. I promise you won't want to go back. Thanks to GCF, you won't have to.

Wait, What?

People are writing open letters to me? Weird.

I will answer the question, though: started the collaboration of competing toolkits that led to the creation of Dojo. How did you do it!?!?

We did it by pointing out to folks who were working on their own things that the personal effort radius exists (i.e., we'd each pioneered some aspect of the complete toolkit but could never drive it to completion on our own) and that we can get further together than apart. From there, experience took over. This is a notable contrast to what happened after and in different circles where developers maybe didn't have as many KLOC of JS under their belts. With fewer sleepless nights of debugging, optimizing, and porting it's harder to see what's ahead and apply the discipline necessary to avoid it. Part of that accommodation for the future is compromise. And why would anyone want to compromise and work with other people when they don't feel like they really need to? It's fun being the smartest person in the room, and if you don't let other people in as equals, you always are. Swallowing that pride is the big transition. Isn't it always?

I guess what it comes down to is that I didn't try to organize people who didn't see the value in organization: instead, I tried to organize folks whose experience was valuable in terms of personal maturity and not just facility with code. We picked a hard technical problem and an easier social problem knowing that the social aspects were more critical. Did we succeed? Yes, but only in the ways we set out to succeed. Dojo continues and is outstanding for the problems it was designed to solve, but the JS market has strong winner-take-all dynamics and the high-end toolkits like Dojo all compete for a highly-knowledgeable, experienced set of developers who understand not only the problem they have today but also the problems they're going to have in a month or two. We built Dojo with folks like that, for folks like that. I should have known then what I see clearly now, though: the fact that there are relatively few experienced, disciplined developers in the world means that when you build things for them, relatively few people will understand what you've done.

Welcome to the club, Justin.

Older Posts

Newer Posts