Infrequently Noted

I was on holiday after I/O last week when Jeremy wrote up some of his thoughts on the current state of PWA UI treatment for URL access. We chatted on Twitter (apologies to Frances) and he followed up here.

A few things seem obscured by the debate so far:

• Most "opens" of PWAs happen in tabs through normal navigation. This has multiple causes, including an inability (which we'll resolve at some point) for Chrome to be able to open navigations to PWAs from external sources in non-browser mode.
• Very few sites were using display: "browser". This means that the change Jeremy objected to affects a minuscule number of sites (today). Now, obviously, Jeremy could go and evangelize all PWA developers to use display: "browser", but that sort of seems misguided because...
• It doesn't solve the problem of URL access or Sharing for sites that chose a different mode (e.g. fullscreen, standalone, or minimal-ui).

That last point is the high-order bit for me. Like Jeremy, I'm agitated over the lack of access to URLs for PWAs launched in a more immersive mode. That seems to be the thing to be frustrated about if you care about URLs and sharing and it's my concern too -- so much so that our team prioritized fixing it this quarter. New UI and gestures are hard to get right which is why I'm excited that Owen and Rebecca have been looking into how to make URLs accessible to PWA users no matter what display mode they're in. We'll have more to show on this front soon.

This matters because URL sharing is the proto-social behavior. It's what enabled the web to spread and prosper, and it's something we take for granted. In fact, if you look at any of my talks, you'll see that I call it out as the web's superpower.

We're going to do something about this imminently because web developers who are building PWAs tend to forget about sharing. It's been painful in our audits of partner apps to have to remind them to "build a share button" and then make sure it's available on-screen in the right modes. It sucks to implement and it's harder to use than a ubiquitous UI contract. At the same time, successful PWA developers are striving for UI consistency with the native platform their apps run on. They want their Web cake and the want to eat it like an App. The onus, then, is clearly on the browser to bring URL access back in ways that developers can't defeat and can't forget.

Which brings us to a final point that seems to have been lost: browsers can fix the real issue -- sharing of PWAs and access to URLs -- without anyone changing anything about their apps, and can do it out-of-band. Obviously, this is only true for browsers that support PWAs and have fast update cycles which, today, is all PWA-supporting browsers; namely Chrome, Opera, and Samsung Internet. The folks who work on these browsers -- including myself -- care as much as Jeremy does about the health and future of the web. I'm grateful to him for highlighting this issue and hope we can work together in the future to figure out ways to keep the best bits of the web healthy as PWAs become a common way to get back to sites users love.

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.