Chrome Arrives: and It's Really About JavaScript

Google shipped a browser last week. It announced it (a detail that will delight historians) via a thirty-eight-page comic book drawn by Scott McCloud, explaining process isolation and garbage collection in speech bubbles. Chrome arrived September 2 as a Windows beta.

The immediate commentary has fixated on market-share horse racing. Can anyone dent Internet Explorer? Is this aimed at Firefox? Why compete with the browsers Google funds and befriends? Reasonable questions, wrong story. The story is in the benchmark charts, and it is spelled V8.

What Google actually built

Chrome’s rendering comes from WebKit, the same open-source engine behind Safari, desktop and iPhone. Sites that render correctly there render correctly here. Our launch-week verification pass across client builds found precisely the nothing that standards work is supposed to find. The testing matrix grows by a column. The remediation list does not. We will take that trade every release.

The novel engineering sits elsewhere. First, architecture: each tab runs as its own operating-system process, isolated from the others. One crashing page takes down its tab, not your afternoon, and the memory of a closed tab actually returns to the system. This ‘many small programs’ model treats web pages the way operating systems treat applications, which is a tell about the whole design philosophy.

Second, and consequentially: V8, a JavaScript engine built from scratch by a team in Denmark. It compiles JavaScript to native machine code rather than interpreting it, and it posts benchmark results several multiples beyond anything currently shipping. Independent testing has largely confirmed the order of magnitude. JavaScript just got dramatically faster in one browser. That is the language of every interface behavior, every AJAX call, and every web application. Publicly, measurably.

Why a search company ships a browser

Follow the incentives and the product explains itself. Google’s revenue is web usage. Its ambitions keep pressing against the ceiling of what browsers can execute. Mail, documents, spreadsheets: applications in the browser. Gmail is a JavaScript application of real heft. Docs more so. Everything Google wants to build next, more still.

When your applications are constrained by the runtime, and the runtime vendors’ priorities are not yours, you build the runtime. Critically, you publish it open-source so the ideas spread even if the browser itself never wins a share war. Chrome is best understood not as a Firefox competitor but as a demonstration with an install base: proof that the web can be an application platform, shipped as a product.

The competitive dynamics we described in June now gain a participant with infinite patience and a direct business interest in browser quality. Mozilla’s own engine work, the TraceMonkey project, was already pushing JavaScript speed. WebKit’s team has its answer in development. Even the IE roadmap will eventually have to speak to performance. The race Chrome starts is the point of Chrome.

What faster JavaScript changes for the people we build for

Concretely, over the next couple of years, as fast engines spread: the interface patterns we deploy carefully today get headroom. The program finders, dashboards, and filtering tools we have built with jQuery and restraint. Interactions that currently demand performance budgeting become routine. Application-grade experiences that currently belong in native software become plausible in the browser your visitors already have.

The ‘is this page a document or an application?’ question we keep posing does not change. But the application answer gets cheaper and smoother to execute. For institutional clients, think richer admissions tools, live data visualization, and working applications where PDFs currently sit.

The discipline that does not change: progressive enhancement, exactly as we have practiced it since the AJAX piece two years ago. Fast engines are spreading, not universal. IE’s enormous installed base runs yesterday’s JavaScript speed and will for years. So the architecture remains layered: content and core function everywhere, enrichment where the runtime affords it. Happily, that is the architecture we would want anyway.

What the benchmarks mean for the code we already ship

A translation layer for anyone whose site runs the patterns we recommend. Your jQuery-built enhancements run several times faster in Chrome today, with no changes. The validation, the reveal-and-collapse interfaces, the in-place updates: all of it. The library’s work is exactly the churn V8 accelerates.

That is pleasant and mostly invisible. Interfaces that were already responsive get imperceptibly more so. The visible difference arrives at the ambitious end. The interactions we have historically trimmed for performance are precisely what fast engines make newly practical. Live filtering across hundreds of items. Drag-heavy interfaces. Anything that made the fans spin in testing.

Our own performance budgets for enhancement work were calibrated against the slowest common engine, and they still must be. IE’s share guarantees it for years. But the ceiling and the floor are now different browsers, and the gap will keep widening until the floor moves. Design for the floor. Delight on the ceiling. Measure both.

One prediction. Chrome’s share a year out will be modest, single digits, early-adopter shaped. Its influence will be anything but, because every vendor’s next release now has a benchmark to answer. We would rather be wrong about the first number than the second.

Practical notes for this quarter

Should you switch browsers? Not the question that matters here. Your visitors will decide over years. Should you test in Chrome? Yes. It is a column in the matrix now, cheap to add given WebKit’s presence there already.

Watch your analytics for its share, keep your support tiers honest, and expect the beta label to matter. This is a 1.0 in fact if not in name, Windows-only today, with the rough edges betas have. The measured take, as usual: nothing about your site needs to change this month, and the ground under every site is shifting in a direction worth understanding.

The signal worth filing

Two years ago Google made measurement free, and we wondered what else it would commoditize. Now it is shipping runtime performance as an open-source gift with a comic book attached.

The pattern is consistent. Google keeps spending money to make the web platform more capable, because a more capable web is where its business lives. Whatever Chrome’s share in a year, the ceiling just moved. In this industry, when the ceiling moves, everything eventually gets taller. Plan for taller.

Read the comic, too, if you have not. Thirty-eight pages of engineers explaining their design decisions in plain pictures is the best technical communication of the year, and a standing rebuke to every whitepaper in your inbox. An industry that explained itself this clearly more often would need fewer consultants. We say this as consultants.