Infrequently Noted

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

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:

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