Infrequently Noted

Today we launched our first Beta release of Google Chrome Frame (aka "GCF").

In some ways it's a strange product; it's working best when you notice it least. As a developer, you shouldn't have to think much about it other than to include the header or meta tag or and optionally add a couple of lines of script to prompt users to install the plugin -- a process which notably doesn't require a restart and doesn't take users off of your site. There's no new tool to learn, no new language you have to wrap your head around...in fact, the hardest part might just be putting down all the habits we've collected for catering to legacy browsers. The new features in Chrome Frame are all the existing features you haven't been able to exercise yet.

As I've begun to build exclusively to modern browsers, the experience of concerted un-learning of hacks and the ability to write directly to the platform again, sans toolkit, has been eye opening. Yes, there's still a lot that can be improved in DOM, CSS, and HTML, but things are moving, and the tools we need now aren't the tools we have today. Better yet, there's every indication that things are progressing fast enough that instead of building tools to bring up the rear, we'll be building them to shield ourselves from the ferocious pace of improvement should we need them at all.

If you're starting a new project today, I encourage you to prototype to HTML5 and modern features and then think hard about what you're building and for whom. Do these apps really need to run on legacy browsers? Why not just use GCF to make that pain and expense go away. Once you've experienced how good modern web development can be -- how rich and fast the apps you can deliver are -- I'm convinced that you'll find it hard to go back. The rich, open, interoperable web is the platform of the future, and I couldn't be happier that GCF is going to help deliver that future.

I had the pleasure and honor of speaking on Google Chrome Frame (slides) at JSConf this past weekend. The conference was small enough that meeting some large percent of the awesome people there was feasible yet large enough that it drew many of the folks doing some of the most interesting work in the JavaScript community today. Frameworks were well represented, as was server-side JS. If you can only go to one conference a year, I can recommend JSConf without reservation. As a speaker, Chris and the organizers treated us better than anyone could hope for, and as an attendee the quality of the content and the hallway conversations left me constantly with the feeling that I was lucky to be where I was but sad that I was probably also missing something else that was awesome.

For some reason Chris — fearless pirate leader that he is — thought it hilarious to have me follow not only Billy Hoffman's outstanding security talk, but also Brendan Eich's never-fail wit and delivery. Funny in that "watching people walk the plank...good times" sort of way. I was also between a bunch of people who (apparently) know how to drink and a truly awesome Google-sponsored party. No pressure. None at all.

Somewhat counter-intuitively my talk focused not on what JavaScript can do, but why we'll be using less of it in the near future; at least for the things we're currently burning bandwidth and CPU. HTML5, CSS 3, and developers who are liberated to take advantage of them are going to kill off a lot of code. Take, for example, the slides for my talk. The only JS library that's included is for prompting users to install Google Chrome Frame. GCF will accelerate the transition to new standards and new ways of building apps. We'll build faster apps not by employing ever-more exotic ways of mangling JavaScript or by giving up the simplicity and directness of HTML and CSS, but rather by simplifying what we write and what we send over the wire.

I'll be talking more about this at Google I/O next month, so if you missed JSConf, hopefully I'll see you there.

When I hear the following words or phrases I now have to stop and think about what is really being said since these words and phrases have been so heavily diluted and co-opted that their positive connotations can no longer be assumed:

"Innovation"

Is a given innovation socially beneficial? I.e., does it improve the lots of any, many, or just a few? Innovation, it turns out, is a vector. It has both magnitude and direction, and that direction can be negative.

"Social Change"

What sort of change? Change is often good. Also, bad. Look closely.

"Open API"

The word "open" is so loaded that when combined with "API", it's nearly a sociopolitical phenomena of its own right. If you think of nothing else when you hear this phrase, think privacy in public. Who owns what happens on the other side of the API?

What am I missing?

All the Chromium news that I care about is now being aggregated at Planet Chromium, joining the similarly awesome Planet Webkit.

One of the points I made during last Saturday's panel was that the further down the path we go with JavaScript, the more pressure there is to use it in ways that defeat view-source. Brendan called me out for seemingly not being aware of beautifiers which can help correct the imballance, but I think that response (while useful) is orthogonal to the thrust of my argument.

Indeed, I hadn't personally used the excellent jsbeautifier.org, instead using my own hacked-up copy of Rhino to beautify when I need to, but neither tool sufficiently reverses the sorts of optimizations being employed by GWT and the even more aggressive Closure Compiler. Far from the mere obsfucation of ShrinkSafe and its brethren, these new compilers apply multi-pass AST-based transforms on an entire body of code, performing per-browser optimizations, type inference and annotation based optimizations, loop invariant hoisting, function inlining, dead-code removal, and global code motion optimizations that produce code different not only in style but in flow of control. The results are nothing short of stunning. The Closure Compiler can deliver code that's much, much smaller than I can wring out by hand and that performs better to boot. It's also totally unrecognizable. De-obsfucators have no hope in this strange land -- brand new tools akin to symbol servers and WinDbg-style debuggers are needed to work with the output in a meaningful way. I argued in the panel and in the comments of my last post on the topic that when we get to this place with JavaScript the product is functionally indistinguishable from a bytecode format like SWF or Java and the effects on the learning-lab nature of the open web are the same: less ability to easily share techniques, a smaller group of more professional users, and a heavier reliance on tooling for generating content.

If we assume that the furthest down the code-centric path we'll go are the Dojo and JQuery style augmentations of existing content, then a simple de-obsfucator is sufficient. But I'm afraid the current generation of high-end sites and apps points in a different direction, one that is less hopeful, and one that implies to a greater extent that the browsers must lead the way out of the wilderness by creating new tags and CSS properties to help re-democratize the process of creating applications. We've already seen the alternatives, and while they may be elegant, they lack leverage and the second-order beneficial effects that have made the web as successful as it is today.

If HTML is just another bytecode container and rendering runtime, we'll have lost part of what made the web special, and I'm afraid HTML will lose to other formats by willingly giving up its differentiators and playing on their turf. Who knows, it might turn out well, but it's not a vision of the web that holds my interest.