It seems entirely rational to be skeptical about governments doing things well. My personal life as a migrant to the UK is mediated by heaving bureaucracies, lawyer-greased wheels, and stupefyingly arbitrary rules. Which is to say nothing of the plights of my friends and co-workers — Google engineers, mostly — whose migration stories to the US are horrifying in their idiocy. Both the US and UK seem beholden to big-stupid: instead of trying to attract and keep the best engineers, both countries seem hell-bent to keep them out. Heaven forbid they make things of value here (and pay taxes, contribute to society, etc.)! It takes no imagination whatsoever for me to conjure the banality and cruelty that are the predictable outcomes of inflexible, anachronistic, badly-formulated policy.

You see it perhaps most clearly when this banality is translated to purely transactional mediums. PDFs that you must fax — only to have a human re-type the results on the other end. Crazy use of phones (of course, only during business hours). Physical mail — the slowest and worst thing for a migrant like myself — might be the most humane form of the existing bureaucracy in the US. Your expectations are set at “paper”, and physical checks and “processing periods” measured in weeks feel somehow of a piece. It has always “worked” thus.

It’s befuddling then to have been a near witness to nothing short of the wholesale re-building of government services here in the UK to be easiest to navigate by these here newfangled computrons. And also just flat-out easy. The mantra is “digital by default”, and they seem to be actually pulling it off. Let me count the ways:

1. High-level policy support for the effort
2. Working in the open. Does your government do its development on github?
3. Designing services for the humans that use them, not the ones who run them
4. Making many processes that were either only-physical or damn infuriating near-trivial to do online
5. Making key information understandable. Give the UK “limited corporation” page a view. Now compare to the California version. Day, meet night.
6. Saving both government and citizens massive amounts of money in the process

They even have a progress bar for how many of the ministries have been transformed in this way.

Over the same timeframe I’ve known a few of the good folks who have put themselves in the position of trying to effect changes like this at Code for America. It’s anathema in the valley to say anything less than effusive about CFA — anything but how they’re doing such good, important work. How CFA has the potential to truly transform the way citizens and government interact. Etc, etc. And it’s all true. But while CFA has helped many in the US understand the idea that things could be better, the UK’s Government Digital Service has gone out and done it.

So what separates them?

First, the sizes of the challenges need to be compared. The US has 5x the population, an economy that’s 6x larger, and a federalist structure that makes fixing many problems more daunting than most UK citizens can possibly imagine. Next, it should be noted that London is a better place to try to hire the Right People (TM). Yes, it’s much more expensive to live here, but software salaries are also much lower (both in relative and absolute terms). There wasn’t as much tech going on here as in the valley to start with, and the gold-rush to produce shiny but less competent versions of existing websites for world+dog (aka: “the app ruse”) hasn’t created the engineering hiring frenzy here that it has stateside. There’s also a general distrust in the American psyche about the core proposition of the government doing good things. Public-spiritedness seems to so many of my generation a sort of dusty nostalgia that went the way of hemp and tie-dye. Close encounters with modern American government do little to repair the image.

But all of those seem surmountable. The US has more of everything, including the Right People (TM). Indeed, the UK is managing an entire first-world’s set of services on a smaller GDP. Why then do US public services, to be blunt, largely still suck?

The largest differences I’ve observed are about model. Instead of having a mandate to change things from the inside, the organizational clout to do it, and enough budget to make a big dent out of the gates (e.g. gov.uk) CFA is in the painful position of needing to be invited while at the same time trying to convince talented and civic-minded engineers and designers to work for well below industry pay for a limited time on projects that don’t exist yet.

Put yourselves in the shoes of a CFA Fellow: and your compatriots are meant to help change something important in the lives of citizens of a municipality that has “invited” you but which is under no real pressure to change, has likely moved no laws or contracts out of the way to prepare for your arrival, and they know you’re short-timers. Short-timers that someone else is taking all the risk on and paying for? What lasting change will you try to effect when you know that you’ve got a year (tops) and that whatever you deliver must be politically palatable to entrenched interests? And what about next year’s Fellows? What will they be handed to build on? What lasting bit of high-leverage infrastructure and service-design will they be contributing to?

The contrast between that and the uncomfortably-named “civil servants” of the GDS could not be more stark. I don’t get the sense that any of them think their job is a lifetime assignment — most assume they’ll be back at agencies any day now, and some of the early crop have already moved on in the way nerds tend to do — but at the pub they talk in terms of building for a generation, doing work that will last, and changing the entire ethos of the way services are produced and consumed. Doing more human work. And then they wake up the next morning and have the authority and responsibility to go do it.

I don’t want to be down on CFA. Indeed, it feels very much like the outside-government precursor to the GDS: mySociety. mySociety was put together by many of the same public-spirited folks who initially built the Alpha of what would a year later become gov.uk and the GDS. Like CFA, mySociety spent years pleading from the outside, making wins where it could — and in the process refining ideas of what needed to change and how. But it was only once the model changed and they grabbed real leverage that they were able to make lasting change for the better. I fear CFA and the good, smart, hard-working people who are pouring their lives into it aren’t missing anything but leverage — and won’t make the sort of lasting change they want without it. CFA as an organization doesn’t seem to understand that’s the missing ingredient. America desperately needs for its public services to make the same sort of quantum leap that the UK’s are making now. It is such an important project, in fact, that it cannot be left to soft-golved, rose-tinted idealism. People’s lives are being made worse by mis-placed public spending, badly executed projects, and government services that seem to treat service as an afterthought. CFA could be changing this, and we owe it to ourselves and our friends there to ask clearly why that change hasn’t been forthcoming yet.

The CFA Fellows model has no large wins under its belt, no leverage, and no outward signs of introspection regarding its ability to deliver vs. the GDS model. Lets hope something larger is afoot beneath that placid surface.

Update: I failed to mention in the first version of this post that the one of the largest philosophical differences between the two countries is the respective comfort levels with technocratic competence. There exists a strain of fatalism about government in the US that suggests that because government doesn’t often do things well, it shouldn’t try. It’s a distillation of the stunted worldviews of the libertarian and liberal-tarian elite and it pervades the valley. Of course governments that nobody expects anything of will deliver crappy service; how could it be otherwise?

What one witnesses here in the UK is the belief that regardless of what some theory says, it’s a problem when government does its job badly. To a lesser degree than I sense in years past, but still markedly moreso than in the US, the debate here isn’t about can the government get good at something, but why isn’t it better at the things the people have given it responsibility for?

As a result, the question quickly turns how one can expect a government to manage procurement of technical, intricate products for which it’s the only buyer (or supplier) without the competence to evaluate those products — let alone manage operations of them. Outsourcing’s proponents had their go here and enormous, open-ended, multi-year contracts yielded boondoggle after boondoggle. By putting contractors in a position of power over complexity, and starving the in-house experts of staffing and resources to match, the government forfeited it’s ability to change its own services to meet the needs of citizens. What changed with gov.uk was that the government decided that it had to get good at the nuts and bolts of delivering the services, outsourcing bits and pieces of small work, but owning the whole and managing it in-house. Having the Right People (TM) working on your team matters. If they’re at a contractor, they have a different responsibility and fiduciary duty. When the ownership of the product is mostly in-house, ambiguities borne of incomplete contract theory are settled in favor of the citizen (or worst case, government) interest, not the profit motive.

The gov.uk folks say “government should only do what only government can do”, but my observation has been that that’s not the end of the discussion: doing it well and doing it badly are still differentiable quantities. And doing better by citizens is good. Clearing space to do good is the essential challenge.

…I don’t really share his vision. I think JS is an important part of the Web, but I don’t see it as any more core to the Web than CSS, HTML, the DOM APIs, HTTP, etc. Most of the proposals I’ve seen to take JS and build a platform on it tend to fall down on #3, #4, and #5. In particular, I think fundamentally #3 and #4 basically force the platform to have a declarative part (the declarative XAML part of .NET is how it managed to address #4, for instance, and the declarative design of XHTML2 and RDF are how they manage to address #3). That doesn’t have to mean that the code part is a secondary part, though. I think the Web has reached a point where you can think of the DOM as the core, with JS and the HTML syntax layered atop that (much like how in .NET there’s objects that can be represented in XAML or generated from C#), which puts the JS part on par with the HTML part in terms of importance to the platform.

This is either me not articulating my “vision” clearly, Hixie mis-understanding my point(s), or some combination thereof. So I’ll try again in 4 paragraphs:

I make no claims about the relative importance of HTML, CSS, JS, DOM or any of the rest. It honestly feels silly to talk about the platform that way. I argue something very, very different: HTML, DOM, and (to a lesser extent) CSS should all conceptually bottom out at JS. I’m not saying “go write a browser in JS”…that’s also non-sequitur. JS must, of course, appeal in turn to C/C++ so a “browser written in JS” would need privileged APIs provided by C/C++ or something lower level.

What I’m saying is something very direct: there’s no other ubiquitous programming language for the web. JS is the only game in town. As a result, when we describe imperative behavior in prose (as the HTML5 spec does) that behavior could, in theory, be implemented in JS (or some sub/super-set). Since HTML, DOM, and CSS aren’t Turing-complete, they naturally belong at a “higher level” in the web platform stack.

Now, all of this sounds dangerously academic and perhaps nuts…but consider that we have to expose APIs for nearly all of this stuff. Whenever we add something to HTML, CSS, etc., it always comes with some sort of API. Now, that could be a good API, or it could be an obtuse turn around the parser after some terrible string concatenation.

I’m claiming that you get better APIs when you design your imperative explanation of the declarative stuff — which you MUST do for specs to be sane — in JS. This means designing new APIs to help you accomplish the task at hand as you go. Doing it that way ends you up with the types, APIs, and security boundaries you’re going to need in the end anyway. Doing it the other way, patching crap onto the side later without explaining how the declarative stuff “works”, just leads to the pain and constant need for case-by-case revision that we see in today’s web APIs.

That’s the whole argument in 4 ‘grafs. It’s subtle, but I hope not terribly controversial. Importantly, nothing about it demands giving up on any of Hixie’s 5 arguments. He can keep ‘em all and still get a well-layered platform. We’ve got enough examples of doing it wrong under our belt to see how painful the badly-layered web is today. We can end this insanity — not by claiming that any part of the platform is “more important” — by explaining the platform in layers, higher levels in terms of the lower levels.

Anyhow, as a result of that ever-growing design/analysis/writing hairball, I haven’t blogged when I might have. Notably, videos of some of my recent talks are now up, including my Fronteers closing talk:

Alex Russell | The Web Platform & the Process of Progress | Fronteers 2012 from Fronteers on Vimeo.

Special thanks to Peter and the Fronteers volunteers for managing to find a pink boozy cake (a culinary revelation!), simultaneously meeting my only (joke) demand as a speaker and trolling me in person. WELL PLAYED.

Also, give the rest of the excellent talks a gander over on Vimeo . Personal favorites of mine include the ever-brillaint Phil Hawksworth, Marcin Wichary’s stunning Doodles talk, Lea Verou, and Rebecca Murphey….actually, there were too many to list. Seriously, go check it out.

I also recently spoke at the London Ajax User’s Group, and video is also available (but not embeddable). Apologies for both videos including a lot of me rambling. I need to get better at this whole “public speaking” thing.

On a related note, FFJS was once again brilliant. Best one day conference going this side of the world, hands down. Congrats to Julie and Remy on a stonkingly good day.

1. MSFT Moves To More Aggressive IE Updates: Automatic updates work, and in conjunction with shorter development cycles they enable the process of progress to move faster. Kudos to MSFT and the IE team for taking a concrete step in the right direction.
2. Jeff Jaffe got the message and, while continuing to say tone-deaf things like “the W3C is a volunteer organization”, thereby ignoring the cause of the prefix squatter’s discontent from the perspective of standards — that there is a good faith way to act and that Apple has run afoul of it by not plumping specs for their features, and that those shipping common code have been burned by unwittingly shipping features which have been found to undermine the good faith of the process — at least he has said that speeding up the process is a key item for action this year at the W3C. It’s not much, but it deserves to be noted as a refreshing bit of honest self assesment.

The reason it’s offensive to the JS hacker for WebIDL to disallow new against DOM types — any of them — is that it means that it’s no longer specifying how you’d describe these types in the primitive we use over here in JS for this sort of thing: functions. This might sound nuts to folks who come from C++ or who spend their time in spec-ese, but there’s no difference between a plain-old function, a “constructor”, and a “partial” or “mixin” in JS semantics. We use functions for all of them. You can say new function(){ ... } and create an instance of an anonymous “class” in JS. You can take the same function and invoke it as a “regular function” — (function(){ ... })(); — and you can use that sort of function as a mixin or partial interface too: new function(){ (function(){ ... }).call(this); ... }. The exact same function object can even act in all of these capacities (although it’s rare). People use them as they need to, but they all boil down to functions.

What, then, does it mean for something to disallow new against some type for which you can in some otherwise get an instance in JS? The same thing when you can’t .call() it: it’s alien. It’s not a class as we know it, which means that it’s not a function, and if it’s not a function…well, it doesn’t belong. Fundamentally, it’s smuggling static semantics into a language that has perfectly good dynamic semantics for the same thing. This strikes at the very heart of what WebIDL is supposed to be for: describing JS types for things implemented somewhere else. By not allowing new and .call() WebIDL is giving JS semantics the bird, asserting that the fact that these things aren’t JS types makes them better in some way…and that is a bug, either in the perspective of the spec authors or of the specs themselves.

Luckily, the fix is easy: all WebIDL types should de-sugar to functions. All of them. All the time. No questions asked. That you will be able to use new and .call() and all the rest isn’t a bug, and it’s not something to guard against. It’s just how JavaScript rolls…and how JavaScript’s largest, most important library should roll too.

More correctly — and apologies if this sounds like a Planet Money episode — vendors sell derivatives contracts (insurance) against the proprietary nature of technologies. I.e., as a hedge against winner-take-all dynamics of network effects and the potential for monopoly rent extraction. Adopters of that technology often refuse to buy it at all without the availability of a derivative to cover their risk of lock-in.

The nice bit about these contracts is that the results (price) are free to the public — ITU and other old-skool orgs are exceptions — meaning anyone who wants to implement can assess what it’ll cost, and if they can provide a solution at a lower to-end-user price, they can compete under the same terms. The public nature of the derivative contract can have the effect of lowering the price of the good itself in markets that clear and have many participants.

Standards organizations are correctly understood as middle-men or market-makers for these contracts.

Update: It may seem strange to some that derivatives contracts (insurance) can drive prices down, but it happens in many industries. E.g., satellite insurance has done wonders for the commercial launch vehicle industry. And who would fund the construction of new cargo ships if you couldn’t convince enough people to ship their precious goods? Insurance matters.

Spin-Off With Cross-licensing

Taking many of the W3C’s activities to a different organization might be traumatic for some members due to IPR concerns. If the members agree that this is the most important consideration, a pure split could be effected, leaving smaller, parallel organizations with identical legal arrangements and identical IPR policies in place. Member organizations would, in a transition period, decide to move their membership to the spin-off, stay with the W3C, or join both (perhaps at a discount?). A contract between the new organizations would allow perpetual cross-licensing of applicable patent rights.

The risk to this plan is that it may not be clear that one new organization would be appropriate — remember, we’re talking about many strange bedfellows under the current W3C umbrella — so perhaps this may only work for whatever center of gravity exists in the spun-off concerns. Smaller efforts (Java-centric APIs, etc.) may want to find other homes.

Merger

One or more of the sub-efforts on the block may wish to find a new home in an existing standards organization. For these efforts there is likely to be larger mismatch between processes, IPR policies, etc. than a spin-off would entail, but the benefits to both receivers and members are clear: a viable home for the long term is hard to build, but coming home to “your people” isn’t nearly as difficult. XML standards, for instance, have a long history at OASIS and it’s unlikely that many members who care primarily about XML at the W3C aren’t also active there. Transfer of IPR in this case is likely to be more fraught, so contracts which stipulate license from the W3C to these new organizations would also need to include clauses which cause the receiving orgs to exercise similar processes to the ones currently in place for the standards which they receive ownership of. The contract would also need to stipulate that RF never be endangered for new versions of divested specs. I haven’t thought hard about transfer of membership under this scenario, but pro-rated and discounted membership terms at all merging organizations — but only for divested activities — might work.

Whatever path a breakup takes, the W3C should listen to each of the non-web communities it’s spinning off and work to ensure that their needs are met in the process. There are lots of details I don’t have time to think through right now, but none of the ones I can identify seem like deal-breakers. The biggest missing piece is the political will to make something happen in the first place.

I’ve been arguing — mostly over beers — for the last year or so that the W3C needs to find a ways to re-focus on the needs of the constituencies that give it credibility; namely web developers and browser vendors. This tends to fall on frustrated W3C staffer ears as individuals might agree but the organization feels the effects of its failures not as a question about how to re-focus around a credible mission but as a short-run funding shortfall. I’m excited that the new Community Groups have the potential to help fix some of this by allowing a freer flow of ideas and a more representative expressions of demand, but there’s the lingering pay-for-play issue that I think is liable to drag the organization back to the status-quo as soon as the excitement and newness of Community Groups wear off.

Now, let me say clearly up front that I don’t think that standards bodies are charities, nor should they be. People join (in the case of the W3C, “people” == “companies”, an equivalence that works as US legal fiction but never in the real world) because they’re expressing their economic interests in agreement on thorny, market-focused issues. The W3C, as an organ, has grown out of an IETF alternative into a critical mediator in the flow of ideas and technology in the web ecosystem. When it fails, we’re starved of progress because nothing else can easily grow in its place. Bless Hixie and the WHATWG for trying, but the W3C sits on fertile spec and patent rich land. It’s tough growing in the rocky craigs, particularly without a patent policy.

So, in the spirit of reform, not revolution, I have a proposal, complete with Swiftian modesty:

At this year’s TPAC, it should be agreed that the W3C will divest itself of any and all Semantic Web, RDF, XML, Web Services, and Java related activities. SVG can be saved, but only if it re-charters to drop all XML dependencies in the next version.

Where should these specs and member organizations go to get their itches scratched? I’m not sure it matters, although it seems likely that OASIS wouldn’t mind being the go-to place for XML. And there’s always ECMA, or IETF, or ISO, or…you get the idea.

Why do such a drastic thing?

Well, it’s not that drastic, really. The SemWeb folks use the term “web” in a hopeful, forward looking way that nobody else does. Their technology is showing promise inside firewalls but their work has near zero relationship to the actual, messy web we swim in every day. The result is that their narrow constituency isn’t the one that animates whatever legitimacy the W3C might enjoy, and therefore their influence in the W3C is out of all proportion to their organizational and web-wide value. Sir Tim’s belief in their goal is noble, but to use the suffix “web” on it today is simply wishful thinking. And things that don’t have anything to do with the web probably don’t belong at the W3C. Besides, the W3C imprimatur doesn’t help these specs and groups as much as their advocates might think — standards bodies aren’t venues for creating the future after all, only for cleaning it up in response to the messy, explosive process of market-driven evolution. Anyway, being endlessly frustrated that the entire web hasn’t changed to accomodate some new model even though it has the phrase “web” in the name can’t be fun. Technologies need to find their success where they really do fit and distributed extensibility and semantics might be valuable…but it hasn’t been to the web yet. It needs to go.

As for XML, well, it won the enterprise and lost the web. That’s still success, but it’s not the web.

Rinse, repeat for RDF, Web Services, and Java.

What would that leave us with? CSS, DOM & JS APIs, HTML, a11y, i18n, and all the other stuff that has legs out on the public web. More to the point, it would have the beneficial effect of re-focusing the organization around getting HTML5 done, getting DOM APIs done that don’t suck for JavaScript on the altar of IDL “language neutrality”, etc.

Organizationally, it would leave the W3C in a much leaner, more focused place. It’s much easier to build a focused constituency and membership, and the lower cost structure would only help the organization weather hard times. I have high hopes that it can be brutally effective again…but to get there, it needs to focus, and focus is the process of ignoring things. The time has come for the W3C to grab the mantle of the web, shake off its self-doubt, and move to a place where doing good isn’t measured by numbers of specs and activities, but by impact for web developers.

Lets look at some possible ES.next code and walk through how it relates to today’s equivalent JS:

module widgets {
  // ...
 
  export class DropDownButton extends Widget {
    constructor(attributes) {
      super(attributes);
      this.buildUI();
    }
 
    buildUI() {
      this.domNode.onclick = (e) -> {
        // ...
      };
    }
  }
}

Ignoring the semantic improvements of Harmony modules over the module patterns we’re using today, we can see a pretty straight-up de-sugaring of that to today’s JS with an emphasis on the many and varied uses of the word function:

var widgets = (function(global) {
  // ...
 
  function DropDownButton(attributes) {
    Widget.call(this, attributes);
    this.buildUI();
  }
 
  DropDownButton.prototype = Object.create(Widget.prototype, {
    constructor: { value: DropDownButton },
    buildUI:     {
      value: function(e) {
        this.domNode.onclick = function(e) {
          // ...
        }
      }
    }
  });
})(this);

What you should take away from this isn’t that we’re turning JS into Java, it’s that we’re making it easier to read, AND THAT’S ALL. Once more for effect: what class means in ES6 is function. Or at least one of the things you currently do with function.

Better yet, we’re blessing a single pattern which you can use with old-style classes just as easily as you do today. I’ll leave it as an exercise for you to name all the different class patterns and systems that do nearly the same thing in slightly incompatible ways today. It’s a very long list.

If you like JS, and you like functions + prototypes (I do!), you have nothing to fear from the sugar we’re adding in ES6.

Update: A lunchtime conversation here at DojoConf today reminded me of perhaps the largest thing that this new system doesn’t do; ES.next aren’t tied to a Java-like type system. Many of the conjoined fears of Java come from the very real pain created by a strict, nominal type system, and nobody in the committee is proposing a mistake like that — least of all me.

As a part of that panel, Brendan, Lars, Arun, John, and I all agreed to post a list of links to demos and such that showed off what our latest browsers are doing. Belatedly, here goes:

The browser wars panel is designed to be a discussion, so we didn’t use any kind of presentation media. So here’s a list of demos and resources so that you can learn more about stuff we talk about. Pictures speak volumes about what gets us excited about the web, anyway.

HTML5, CSS, and JavaScript Demos

• The Web O’ Wonder Website works in browsers that support the latest web standards.

• The Beauty of the Web site showcases a bunch of different things with a bit of an IE9 slant.

• HTML5 Rocks showcases a lot of great demos, which work best in Firefox 4 and the latest Chrome (but the site uses feature detection, so much of it will work in IE9 and Safari.).

• FourSquare Playground has a strong IE9 bias, but showcases HTML5.

• IE Test Drive. Need I say more about bias? Showcases HTML5, with the promise of some demos that may work cross-browser.

• Here’s a presentation I gave, which may actually have a Firefox bias, given that I showcased technologies that were “Moz” prefixed (e.g. MozOrientation). Still, shows off some great demos in a variety of arena (Geolocation, etc.).

WebGL Demos

To get maximum mileage out of these, you’ll want a fast PC with the latest Chrome or Firefox.

• The CopperLicht Stuff from Ambiera blows my mind every time.

• Flight of the Navigator is a really compelling mix of different elements.

• Remixing Reality is really compelling demo of the use of models.

• The WebGL Demo Repository at Khronos contains demos that are classic GL ones (that 3D programmers are all well familiar with).

Resources

• Can I Use provides incredibly useful feature matrices to determine which browser supports what in the HTML5 and CSS arena.

• Quirksmode is the go-to place for compatibility tables.

• Hacks is Mozilla’s showcase for articles, demos, and API updates.

• HTML5 Rocks features great stuff about HTML5, and includes code snippets and documentation for developers.

• HTML5 Now is Tantek Celik’s book on the subject.

• HTML5 for Web Designers is Jeremy Keith’s book on the subject.

• Bruce Lawson and Remy Sharp’s HTML5 Lands

• Learning WebGL and the WebGL Cookbook are great sites to learn WebGL

Performance Innumeracy

I want to dive into concrete strategies for low-to-no false positive UA matching for use in caching feature detection results, but first I feel I need to walk back to some basics since I’ve clearly lost some people along the way. Here are some numbers every developer (of any type) should know, borrowed from Peter Norvig’s indispensable “Teach Yourself To Program In Ten Years”:

Approximate timing for various operations on a typical PC:

execute typical instruction	1/1,000,000,000 sec = 1 nanosec
fetch from L1 cache memory	0.5 nanosec
branch misprediction	5 nanosec
fetch from L2 cache memory	7 nanosec
Mutex lock/unlock	25 nanosec
fetch from main memory	100 nanosec
send 2K bytes over 1Gbps network	20,000 nanosec
read 1MB sequentially from memory	250,000 nanosec
fetch from new disk location (seek)	8,000,000 nanosec
read 1MB sequentially from disk	20,000,000 nanosec
send packet US to Europe and back	150 milliseconds = 150,000,000 nanosec

That data’s a bit old — 8ms is optimistic for a HD seek these days, and SSD changes things — but the orders of magnitude are relevant. For mobile, we also need to know:

The 60hz number is particularly important. To build UI that feels not just fast, but instantly responsive, we need to be yielding control back to our primary event loop in less than 16ms, all the time, every time. Otherwise the UI will drop frames and the act of clicking, tapping, and otherwise interacting with the app will seem “laggy” or “janky”. Framing this another way, anything your webapp blocks on for more than 16ms is the enemy of solid, responsive UI.

Why am I blithering on and on about this? Because some folks continue to mis-prioritize the impact of latency and performance on user satisfaction. Google (my employer, who does not endorse this blog or my private statements in any way) has shown that seemingly minor increases in latency directly impact user engagement and that major increases in latency (> 500ms) can reduce traffic and revenue significantly. Latency then, along with responsiveness (do you drop below 60hz?), is a key metric for measuring the quality of an web experience. It’s no accident that Google employs Steve Souders to help evangelize the cause of improving performance on the web, and has gone so far as to build products like Chrome & V8 who have as a core goal to the web faster. A faster web is a better web. Full stop.

That’s why I get so deeply frustrated when we get straw-man based, data-challenged advocacy from the maintainers of important bits of infrastructure:

This stuff is far from easy to understand; even just the basics of feature detection versus browser detection are quite confusing to some people. That’s why we make libraries for this stuff (and, use browser inference instead of UA sniffing). These are the kind of efforts that we need, to help move the web forward as a platform; what we don’t need is more encouragement for UA sniffing as a general technique, only to save a couple of milliseconds. Because I can assure you that the Web never quite suffered, technologically, from taking a fraction of a second longer to load.

What bollocks. Not only did I not encourage UA sniffing “as a general technique”, latency does in fact hurt sites and users — all the time, every day. And we’re potentially not talking about “a couple of milliseconds” here. Remember, in the context of mobile devices, the CPUs we’re on are single-core and clocked in the 500mhz-1ghz range, which directly impacts the performance of single-threaded tasks like layout and JavaScript execution — which by the way happen in the same thread. In my last post I said:

…if you’re a library author or maintainer, please please please consider the costs of feature tests, particularly the sort that mangle DOM and or read-back computed layout values

Why? Because many of these tests inadvertently force layout and style re-calculation. See for instance this snippet from has.js:

if(has.isHostType(input, "click")){
  input.type = "checkbox";
  input.style.display = "none";
  input.onclick = function(e){
    // ...
  };
  try{
    de.insertBefore(input, de.firstChild);
    input.click();
    de.removeChild(input);
  }catch(e){}
  // ...
}

Everything looks good. The element is display: none; so it shouldn’t be generating render boxes when inserted into the DOM. Should be cheap, right? Well, lets see what happens in WebKit. Debugging into a simple test page with equivalent code shows that part of the call stack looks like:

#0	0x0266267f in WebCore::Document::recalcStyle at Document.cpp:1575
#1	0x02662643 in WebCore::Document::updateStyleIfNeeded at Document.cpp:1652
#2	0x026a89fd in WebCore::MouseRelatedEvent::receivedTarget at MouseRelatedEvent.cpp:152
#3	0x0269df03 in WebCore::Event::setTarget at Event.cpp:282
#4	0x026af889 in WebCore::Node::dispatchEvent at Node.cpp:2604
#5	0x026adbcb in WebCore::Node::dispatchMouseEvent at Node.cpp:2885
#6	0x026ae231 in WebCore::Node::dispatchSimulatedMouseEvent at Node.cpp:2816
#7	0x026ae3f1 in WebCore::Node::dispatchSimulatedClick at Node.cpp:2837
#8	0x02055bb5 in WebCore::HTMLElement::click at HTMLElement.cpp:767
#9	0x022587e6 in WebCore::HTMLInputElementInternal::clickCallback at V8HTMLInputElement.cpp:707
...

Document::recalcStyle() can be very expensive, and unlike painting, it blocks input and other execution. And the cost is at page loading is likely to be much higher than other times as there will be significantly more new styles streamed in from the network to satisfy for each element in the document when this is called. This isn’t a full layout, but it’s most of the price of one. Now, you can argue that this is a WebKit bug and I’ll agree — synthetic clicks should probably skip this — but I’m just using this as an illustration to show that what browsers are doing on your behalf isn’t always obvious. Once this bug is fixed, this test may indeed be nearly free, but it’s not today. Not by a long shot.

Many layouts in very deep and “dirty” DOMs can take ten milliseconds or more, and if you’re doing it from script, you’re causing the system to do lots of work which it’s probably going to need to throw away later when the rest of your markup and styles show up. Your average, dinky test harness page likely under-counts the cost of these tests, so when someone tells me “oh, it’s only 30ms”, not only do my eyes bug out at the double-your-execution-budget-for-anything number, but also the knowledge that in the real world, it’s probably a LOT worse. Just imagine this happening in a deep DOM on a low-end ARM-powered device where memory pressure and a single core are conspiring against you.

False Positives

My last post concerned how you can build a cache to eliminate many of these problems if and only if you build UA tests that don’t have false positives. Some commenters can’t seem to grasp the subtlety that I’m not advocating for the same sort of lazy substring matching that has deservedly gotten such a bad rap.

So how would we build less naive UA tests that can have feature tests behind them as fallbacks? Lets look at some representative UA strings and see if we can’t construct some tests for them that give us sub-version flexibility but won’t pass on things that aren’t actually the browsers in question:

IE 6.0, Windows:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

FF 3.6, Windows:

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Firefox/3.6.13

Chrome 8.0, Linux:

Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Ubuntu/10.10 Chromium/8.0.552.237 Chrome/8.0.552.237 Safari/534.10

Safari 5.0, Windows:

Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4

Some features start to jump out at us. The “platform” clauses — that bit in the parens after the first chunk — contains a lot of important data and a lot of junk. But the important stuff always comes first. We’ll need to allow but ignore the junk. Next, stuff after platform clauses is good, has defined order, and can be used to tightly form a match for browsers like Safari and Chrome. With this in mind, we can create some regexes that don’t allow much in the way of variance but do allow sub-minor version to match so we don’t have to update these every month or two:

IE60 = /^Mozilla\/4\.0 \(compatible; MSIE 6\.0; Windows NT \d\.\d(.*)\)$/;
FF36 = /^Mozilla\/5\.0 \(Windows; U;(.*)rv\:1\.9\.2.(\d{1,2})\)( Gecko\/(\d{8}))? Firefox\/3\.6(\.\d{1,2})?( \(.+\))?$/;
CR80 = /^Mozilla\/5\.0 \((Windows|Macintosh|X11); U;.+\) AppleWebKit\/534\.10 \(KHTML\, like Gecko\) (.+)Chrome\/8\.0\.(\d{3})\.(\d{1,3}) Safari\/534\.10$/;

These look pretty wordy, and they are, because they’re designed NOT to let through things that we don’t really understand. This isn’t just substring matching on the word “WebKit” or “Chrome”, this is a tight fit against the structure of the entire string. If it doesn’t fit, we don’t match, and our cache doesn’t get pre-populated. Instead, we do feature detection. Remember, false positives here are the enemy, so we’re using “^” and “$” matches to ensure that the string has the right structure all the way through, not just at some random point in the middle, which UA’s that parade around as other browsers tend to do.

Here’s some sample code that incorporates the approach:

(function(global){
 
    // The map of available tests
    var featureTests = {
        "audio": function() {
            var audio = document.createElement("audio");
            return audio && audio.canPlayType;
        },
        "audio-ogg": function() { /*...*/ }
        // ...
    };
 
    // A read-through cache for test results.
    var testCache = {};
 
    // An (exported) function to run/cache tests
    global.ft = function(name) {
        return testCache[name] = (typeof testCache[name] == "undefined") ?
                                    featureTests[name]() :
                                    testCache[name];
    };
 
    // Tests for 90+% of current browser usage
 
    var ua = (global.navigator) ? global.navigator.userAgent : "";
 
    // IE 6.0/WinXP:
    var IE60 = /^Mozilla\/4\.0 \(compatible; MSIE 6\.0; Windows NT \d\.\d(.*)\)$/;
    if (ua.search(IE60) == 0) {
        testCache = { "audio": 1, "audio-ogg": 0 /* ... */ };
    }
 
    // IE 7.0
    // ...
    // IE 8.0
    // ...
 
    // IE 9.0 (updated with fix from John-David Dalton)
    var IE90 = /^Mozilla\/5\.0 \(compatible; MSIE 9\.0; Windows NT \d\.\d(.*)\)$/;
    if (ua.search(IE90) == 0) {
        testCache = { "audio": 1, "audio-ogg": 0 /* ... */ };
    }
 
    // Firefox 3.6/Windows
    var FF36 = /^Mozilla\/5\.0 \(Windows; U;(.*)rv\:1\.9\.2.(\d{1,2})\)( Gecko\/(\d{8}))? Firefox\/3\.6(\.\d{1,2})?( \(.+\))?$/;
    if (ua.search(FF36) == 0) {
        testCache = { "audio": 1, "audio-ogg": 1 /* ... */ };
    }
 
    // Chrome 8.0
    var CR80 = /^Mozilla\/5\.0 \((Windows|Macintosh|X11); U;.+\) AppleWebKit\/534\.10 \(KHTML\, like Gecko\) (.+)Chrome\/8\.0\.(\d{3})\.(\d{1,3}) Safari\/534\.10$/;
    if (ua.search(FF36) == 0) {
        testCache = { "audio": 1, "audio-ogg": 1 /* ... */ };
    }
 
    // Safari 5.0 (mobile)
    var S5MO = /^Mozilla\/5\.0 \(iPhone; U; CPU iPhone OS \w+ like Mac OS X; .+\) AppleWebKit\/(\d{3,})\.(\d+)\.(\d+) \(KHTML\, like Gecko\) Version\/5\.0(\.\d{1,})? Mobile\/(\w+) Safari\/(\d{3,})\.(\d+)\.(\d+)$/;
    if (ua.search(FF36) == 0) {
        testCache = { "audio": 1, "audio-ogg": 0 /* ... */ };
    }
 
    // ...
 
})(this);

New versions of browsers won’t match these tests, so we won’t break libraries in the face of new UAs — assuming the feature tests also don’t break, which is a big if in many cases — and we can go faster for the majority of users. Win.

Why I spent last summer rebooting Windows

or:

How to compress several months of research into 50 lines of code and unblock a product launch, for fun and profit. Home parlor entertainment edition. Fun for all ages. Warranty void if seal broken. Offer not available in some states.

Now that others have found the same technique that I used to drop Chrome and Chrome Frame cold start times by more than 2/3 last summer, I feel compelled to explain what’s going on. Particularly as there seems to be some confusion over in the Hacker News thread.

First, a couple of notes and caveats. SSDs are coming (see: ChromeOS, iOS, etc.), and in an SSD world, none of what follows will matter. Some of it could even hurt you. Other concerns — drive-internal parallelism, bus bandwidth/latency, and the amounts of crapware (that’s you, Sophos/Bit9/etc.) between your driver and your LoadLibrary call — are going to dominate. Also note that what I’m about to say is app specific. If you want your app to start faster, collect data on real-world systems and go from there. Cargo-cult hacks at your own peril.

Right then, spinning disks.

Good programs start fast, and that includes when you start them just after the OS has started. In this state, many of the caches the OS populates on your behalf are unlikely to be full of goodies that’ll help you start faster, so you pay full freight for all of your dependencies. This is called a “cold start”. When you start cold you have to go get everything you need from disk. Usually spinning disk. With > 10ms average latencies for random reads. Ouch.

For a sense of scale, consider that warm starts of Chrome (on Windows) take just ~200ms. That’s ~200ms for both the browser and renderer processes. 20 random reads from disk double that. Last summer, depending on OS version, disk speed, and amount of Prefetch/SuperFetch training cold starts ranged from 2000-3700ms. Fortunately, browsers are the sorts of things that users tend to keep open, and if they close, re-open later in the same session. Cold start hurts, but it’s not most user’s primary experience of a browser.

But that doesn’t hold for a plugin, particularly one that isn’t already ubiquitous. Yes, Flash loads quickly, but for most sites it starts fast because some other site had previously loaded it. Cold start matters even more for Chrome Frame. You’ve already started your browser, so why is this page taking so long to come in? It’s not enough that the network response is being buffered and the page will feel instant when the renderer finally starts…we need pixels on screen stat. Hence began my summer of rebooting. We couldn’t ship Chrome Frame to Stable until cold start was sub-second.

Using custom logging via ETW as a starting point, I quickly found that most of the time spent in Chrome startup wasn’t going to subprocess or thread creation, cache loading, profile reading, or any of the other obvious big-ticket items. Tremendous discipline has been enforced in the Chromium codebase, ensuring that things which might otherwise block startup tend to happen asynchronously, keeping your experience responsive.

What’s left? ETW, Sawbuck and XPerf eventually showed that we were thrashing disk for lots of little 16-64K reads into chrome.dll. Why not 4K, the size of single page? The Windows memory manager uses a read-ahead optimization when a hard fault occurs. That is to say, when your program tries to execute some bit of code from a library that isn’t yet in memory, the memory manager will go get the bits that correspond to the code in question, plus a little. Compilers optimize for code locality so you’re probably going to need the other pages too. Read-ahead (probably) saves you another expensive seek. If you don’t use those pages, no biggie. Windows is smart enough to prioritize caches. Lots of little 16-64K reads (aka: random I/O!) matched up with the hard page fault data…bingo. Even with SuperFetch doing its thing on modern Windows versions, we were seeing lots of slow (>10ms on 5400rpm disk) reads thanks to hard page faults.

Why were we getting these faults? To be entirely honest, we never quite figured this out. SuperFetch/PreFetch do their thing before your program ever hits it’s CRT main (the very first program-supplied entry point), meaning frequently used pages should already be available. Part of the reason they weren’t might be the different patterns of access between the Chrome Browser and Renderer processes. The same binary (chrome.exe) and main library (chrome.dll) are used for both, but the bits that each use are pretty radically different. There’s no access to WebKit code from the Browser process, e.g., but that’s most of what the Renderer uses. Other theories included some cap on the number of pages that SuperFetch will remember and log. Whatever the reason, fault location graphs showed a pretty violent thrashing toward the top end of chrome.dll.

Idea time: how can we pull all of the pages into the standby list — the bit of the Virtual Memory cache with the lowest priority — with a single seek, i.e. one big sequential read? What can we do to slurp the entire DLL into memory so that when the program needs some bit of the library, it gets it from memory, not from spinning (read “slow”) disk?

We tried loading the library and walking the pages sequentially. No joy…well, not much. Certainly not enough. More on that in a second. What about pulling the DLL into the disk cache? Hrmmm. A quick test showed that this worked great on Windows Vista. Just fread the sucker in and boom. ~750ms cold starts!

Except on XP. Balls.

Seemingly the memory manager bypasses the disk cache for faults on XP. Back to the bat-DLL-memory-walk approach, Batman! Yes, this works on XP, albiet with some caveats — namely that it’s slower than the other method. We still get stalls and slow seeks, but things improve to the 1300ms range. Average cold starts cut in half. We’ll take it. The final patch isn’t pretty, but it does something like what we want. See this file, look for PreReadImage which gets used in Chromium’s WinMain which does custom DLL loading here, and only on the first (parent, aka, browser) process that’s created. Voila! Really, really fast starts nearly everywhere.

So, is doing this a good idea?

It’s not a slam dunk. For users with SSDs, this is more data than they strictly need, possibly slowing starts marginally for them. We’ll probably have to revisit this at some point. Also, the Vista+ approach potentially pollutes the disk caches. Not great, but at least the pages in questions won’t cause unnecessary thrashing unless the system is already under memory pressure in which case, the impending startup operations (allocating enough heap for V8, renderer process startup, etc.) are going to hurt no matter what. Also, we’re not exactly sipping data here. As the size of chrome.dll grows, so will the time required to pull it across the bus, even if the reads are serial. On my most recent dev channel rev, that’s a 23MB DLL, so if we get 75-100MB/s across the bus (optimistic for these old drives), we’re looking at a couple of hundred milliseconds just spent reading. Beats a tons of random seeks, but it’s still not great. Ideally we’d be able to use PGO/WPO to scope down the amount we really need to read by clumping early-use stuff towards the front of the binary, but so far this hasn’t panned out thanks to the aforementioned multi-process/single-dll thing. Turns out binary re-writing on Windows isn’t trivial. Perhaps the biggest down-side is that the XP experience isn’t ideal yet, and users on XP are most likely to have neither SSDs nor particularly speedy spinning disks. They need the help most. We were able to do something for them thanks to some dark magic in the Windows XP Prefetch system, but that’s a tale for another day. Suffice to say I now have tremendous respect for the folks who built these systems. Some parts of Windows truly are beautiful.

All in all, this hack has panned out in the real world in a pretty compelling way. Our start time histograms show the improvement in the real world (thanks to all of you who turned on reporting!), and Chrome Frame was able to ship to Stable last fall after we were relatively certain that we weren’t degrading overall system performance for users.

If you’ve read all of this, I hope that for your sake it’s with a sense of historical bemusement. What? They didn’t all have SSDs/quantum-rent-an-exabytes? Pssh. How did they get by? Well, now you know. One slow reboot of Windows at a time.

Bootnote: I should mention that it wasn’t as straight line to suss out what actually happens in a cold start, pin down causality, understand the differences between XP and Vista+, and convince ourselves with real-world data that this was really our best option. It took a long time. Also, at some point, I stopped borrowing Amit’s copies of Windows Internals 4 and Windows Internals 5 and bought my own. You’ll need both if you still work with XP. Recommended.

Footnote to the Bootnote: Obvious Windows Hacker question: why not just do something like read in the DLL from the GCF BHO when you start up? Y’all get your BHO component loaded at IE launch, after all.

Good thought, Obvious Windows Hacker! Sadly, this is evil…or at least not very sporting. Even with low-priority I/O on Vista+, it’s sort of punitive to go do tons of I/O near when the user is probably starting to browse sites that might not make use of our BHO-based goodness, don’t you think? Besides, if we can get an honest startup win, why cheat? Honest wins pay off for both Chrome and Chrome Frame, which is doubly awesome.