Infrequently Noted

A lot of smart folks keep asking me why AppCache isn't a good enough solution for "offline" and why it was necessary to invent Service Workers. It's a great question!

Motivated by the regrettably uneven browser support landscape for Service Workers, there's a real incentive to "just make something work offline" on iOS or old-IE. This phrasing obscures the primary experience difference between native apps and web content: native apps always "boot" when you tap on them. The legacy web, however, can take as long as the TCP timeout (2 minutes in many devices) to end in failure. That's a looooong time to be looking at a white screen.

But doesn't AppCache let you cache documents you might want offline? Sort of. Kinda. Ish. Turns out this only works in trivial cases. The issue is that the AppCache design only allows you to do "routing" using the FALLBACK section, and to trigger the FALLBACK URL (which can boot up, inspect it's environment, and do something custom) the request needs to have actually failed. To handle the general case -- a site with an unbounded set of URLs -- that means users are waiting on a flaky, slow network for minutes (if they're patient) before the the router page starts, which might then forward them on to content or a custom offline experience.

"But wait!", you say, "doesn't AppCache also allow you to put documents in the cache directly, bypassing all of that?". Yes, it does, but because of AppCache's atomic update system and practical limits to storage space, this means that the set of URLs in this list needs to be low and change infrequently. You see this play out, for example, in the AppCache manifests that major Google services like Google Docs generate. These services wind up with major complexity related to creating manifests on a per-user basis and managing the entries in them. Those entries are carefully curated from amongst the entire set of possible URLs to ensure high performance for the entries users are likely to visit offline, but this still leaves everything else at the mercy of network flakiness.

It's hard to stress enough how much better reliable performance is. Think of it this way: the first load of a native app sucks. It's gated by an app store and a huge download, but once you get to a point where the app is installed, that up-front cost is amortized across all app starts and none of those starts have a variable delay. Each application start is as fast as the last, no variance. What native apps deliver is reliable performance.

Until Service Workers arrived, it simply wasn't possible to achieve this and that's why I designed Chrome's Add-to-Homescreen prompting behavior to require a Service Worker that responds quickly for the URL listed in the Manifest's start_url. The heuristic is designed to only promote experiences that are "app-like"; recognizing that a key differentiator between the "old web" and native apps is reliable performance.

Remy Sharp blogged about the experience and expectation differences that we've worked hard to bake into Progressive Web Apps. Reliable performance is the most important of these and the reason Progressive Web Apps require Service Workers. It isn't that "offline" support doesn't matter -- it does -- but apps that work well offline are a subset of things that are apps, experiences you can trust to start any time, anywhere, on any connection.

I'll be speaking more about this at Google I/O in a few weeks, and I'm hugely excited about the ways that the web is going to get better this year; starting with experiences that always work.

What follows is roughly the text of a talk I gave last week at the Extensible Web Summit in Melbourne.

The Point of Extensibility

Mark, apparently, "volunteered" me to give a lightning talk last night over a dinner that I wasn't at, so apologies in advance if I run short or long.

Something that comes up frequently in our work on the TAG is the relationship between extensibility as a principle and how it relates to specific features we want in the web platform. To get anywhere in these debates, I think it's worth zooming out a bit.

The web has a strange origin story: we didn't build our way up from assembler and C, and the notion of moving words around memory is so far from the level of abstraction that HTML, JavaScript, and CSS provide that you can barely see them from there. Even VBScript, perhaps the most relevant contemporary, had a story for how that layering worked. The web, for decades, managed to do without.

Extensibility, then, has been an effective tool in the modern era for trying to understand the hidden linkages between the strange fauna and flora of this alien world. We can almost always get somewhere by asking dumb questions like "so, how does this thing relate to that other thing over there?". We nearly always turn up some missing primitive that we can catalog and reuse on our shared exploration.

But I'd submit that Extensibility is a tool in the same sense as Standards: it's possible to drive yourself mad with them if you lose track of the goal. Despite our setting today, this isn't academic. We're doing it all for a reason, and that reason needs to be a goal we share.

I can't set goals for you, but I can tell you what mine are and ask you to join me in them. My specific goal, then, is to improve the rate of progress on the web for the benefit of users and developers, in that order.

Put another way, I want to ensure the web is the platform developers invest in first and most, and that they do so because it's the easiest, best way to deliver great experiences.

With that in mind, it's easier to be kind to proposals that come to the TAG for high-level features, particularly if they're forging new ground or opening up new fundamental capabilities that the web didn't have but that will enrich user's experiences by improving developer's options.

Extensibility and Standards are incredibly useful tools but they make crummy religions.

There will be new features that aren't extensible by default. That's OK. Not ideal, but OK and, sometimes, unavoidable. What is avoidable is leaving the web's features sealed shut, never asking the questions about how things relate; never connecting the dots.

That would be a damned shame. I'm grateful the TAG has joined some of us insurrectionists in asking these questions, but we've got a long way to go. And my hope as we go there together is that we don't mistake the means for the goals.

Thanks.