Infrequently Noted

So from time to time I'd wondered what all the brilliant DHTML hackers that Google had hired were up to. Obviously, building products. Sure. But I knew these guys. They do infrastructure, not just kludges and one-off's. You don't build a product like Gmail and have no significant UI infrastructure to show for it.

Today they flung the doors open on Closure and it's supporting compiler. These tools evolved together, and it shows. Closure code eschews many of the space-saving shortcuts that Dojo code employs because the compiler is so sophisticated that it can shorten nearly all variables, eliminate dead code, and even do type inference (based on JSDoc comments and static analysis).

There's a ton of great code in Closure, so go give the docs a look and, if you're into that kind of thing, read the official blog post for a sense of what makes Closure so awesome.

It's interesting to me how much it feels like a more advanced version of Dojo in many ways. There's a familiar package system, the widgets are significantly more mature, and Julie and Ojan's Editor component rocks. The APIs will feel familiar (if verbose) to Dojo users, the class hierarchies seem natural, and Closure even uses Acme, the Dojo CSS selector engine. It's impressive work and congrats are in order for Arv, Dan, Emil, Attila, Nick, Julie, Ojan, and everyone else who worked so hard to build such an impressive system and fight to get it Open Source'd.

PPK posted some great new compat tables for various flavors of WebKit-based browsers the other day, editorializing that:

...Acid 3 scores range from a complete fail to 100 out of 100.

This is not consistency; it’s thinly veiled chaos.

But I'm not convinced that the situation is nearly that bad.

The data doesn't reflect how fast the mobile market changes. The traditional difference between mobile and desktop, after all, has been that mobile is moving at all. If you figure a conservative 24 month average replacement cycle for smartphones, then the entire market for browsers turns over every two years. And that's the historical view. An increasing percentage of smartphone owners now receive regular software updates that provide new browsers even faster. What matters then is how old the WebKit version in a particular firmware is and how prevalant that firmware is in the real world. As usual, distribution and market share are what matters in determining real-world compatibility, and if that's a constantly changing secnario, the data should at least reflect how things are changing.

So what if we add a column to represent the vintage of the tested WebKit versions? Here's a slightly re-formatted version of PPK's summary data, separated by desktop/mobile and including rough WebKit vintages (corrections and new data much appreciated if you happen to know!):

Desktop

Mobile

PPKs data is missing some other columns too, namely a rough estimate of the percent of mobile handsets running a particular version, rates of change in that landscape over the past 18 months, and whether or not these browsers are on the whole better than the deployed fleet of desktop browsers. Considering that web devs today still can't target everything in Acid2, knowing how the mobile world compares to desktops will provide some much-needed context for these valuable tables. Perhaps those are things that we as a community can chip in to help provide.

Even without all of that, just adding the rough vintages adds an arc to the story; one that's not nearly so glum and dreary. What we can see is that newer versions of WebKit are much more capable and compatible, even at the edges. None of PPK's data yet tests where the baseline is, so remember that the numbers presented mostly describe new-ish features on the platform. We also see clearly that the constraints of the mobile environment force some compromises vs. desktop browsers of the same lineage. This is all in line with what I'd expect from a world where:

• WebKit is becoming the dominant smartphone rendering engine, finding its way into myriad devices due to its performance, compatibility with web content, clean C++ codebase, and straightforward API
• Vendors upgrade the version of WebKit they ship when they release new OS versions. Very few mobile devices enjoy long-term OTA updates (yet).
• Deployed smartphone stock turns over every 2 years

The important takeaway for web developers in all of this is that WebKit is winning and that that is a good thing. The dynamics of the marketplace have thus far ensured that we don't get "stuck" the way we did on the desktop. That is real progress.

Where do we go from here? Given that the mobile marketplace is changing at a rate that's nearly unheard of on the desktop, I think that when new charts and comparisons are made, we'll need to couch them in terms of "how does this affect the difference in capabilities across the deployed base", rather than simply looking at instantaneous features. Mobile users are at once more likely tied to their OSes choice of browser and more likely to get a better browser sooner. That combination defies how we think about desktop browsers, so we'll need to add more context to get a reasonable view of the mobile world.

• Dynamic languages can't be fast relative to static languages
• Any language with a working lambda can be saved from itself, given a fast enough runtime. But you can't save the other folks who use that language
• You agree with me
• RDFa is smart technology, and can be cleanly integrated into HTML
• It was all invented in the 70's
• Java-style static typing prevents me from doing dumb things in the small. This makes it awesome.
• You slow down as you get older, but it's a learned response. You get there because you find caution useful. You stay there because you find caution comfortable
• Java-style classes prevent me from doing smart things in the large, or at least makes smart things harder to communicate. This makes it terrible.
• Dynamic languages can be more than fast enough.
• Your language is probably better than my language
• C++ made it all possible years ago, but nobody noticed because their compiler didn't support it yet
• RDFa is doomed to inevitable, painful failure
• Making it common is more important than making it to start with
• Forging agreement is hard, sometimes impossible
• You violently disagree with most things I say
• The more things change, the more they change

Somehow I got out of sync with everyone else in the local distcc cluster at work. How? Weirdly, the XCode settings showed that while there were plenty of peers around to build with, they were all slightly off (har) in their OS version number, and therefore returned the dreaded "Incompatible Service".

Some googling revealed that Apple shipped two 10.5.8's!. A regular software-update won't trigger the required update, either. Luckily, re-applying the stand-alone updater got me up to 9l31a, and I can once again abuse my co-worker's CPUs instead of my own. Phew!

I've been so busy with with work and such that I totally forgot to mention that tomorrow, Sept 10th there will be a Dojo Developer Day in Mountain View, generously hosted by AOL.

Come for the whole day, drop by for a bit, or just join us for dinner/drinks afterward. In the ramp up to 1.4, there's some great engineering happening in nearly every area of the toolkit, including some great new visual improvements that I expect to see and hear a lot about tomorrow.

As usual, folks will be on IRC throughout the day should you not be able to join us in person, and in a first, we'll have a live feed of the event going.

Hope you can join us!