Re: [w3c/manifest] Add offline_url option (#774)

I had an offline chat about this today with some folks in Sydney. It's very complicated so I'll try to explain my thoughts here.

Firstly we've kind of got two parallel ideas going now:

1. A declarative mechanism for handling all the caching logic and serving it.
2. Just a declarative mechanism for _pointing at_ the offline page, but the caching is still handled by the service worker.

Re Idea 2:

@Snugug :
> As it sounds like a lot of the disagreement is around having the manifest now being in charge of caching something. What if instead of assuming that offline_page will do some sort of caching, it's rather closer to how start_url works where it doesn't own caching but rather tells what should be used.

You're right that this new proposal separates concerns correctly, with the manifest in charge of the high-level layout of the app and the SW in charge of the network / caching. But if we did it this way, I don't really see what problems it solves. You'd still have to write a SW with a fetch handler that does caching, exposing your site to the performance and breakage concerns mentioned above. The only thing this `offline_page` option in the manifest would save you from doing is the last line of Marcos's service worker code ("`just return the index if all goes bad`"). I don't see the benefit of doing Idea 2 if the SW is still responsible for caching.

So turning back to Idea 1 (a declarative mechanism responsible for the caching logic):

I've been convinced that there _is_ an underlying need here that isn't really met by Service Workers: specifically that if you have a large business-critical website that's working just fine as it is, adding a fetch handler in front of all your requests is a pretty huge deal. Firstly because it may result in a performance regression due to the extra IPCs and JavaScript code running on every request, and secondly because it has the potential to break everything if there's a bug in the fetch handler (e.g., it could accidentally get stuck serving the main page from cache forever, making it impossible to push out an update). So it's a pretty scary thing to ask a large website to add, even if it is just about a dozen lines of code as @marcoscaceres wrote above.

If adding a manifest and an offline page is all a site needs to do to get their app to run as a PWA, they might do it, but if they need to put their site at risk, they might decide not to take the risk. So providing this "easy-path" offline page might be the thing that convinces many large web properties to become PWAs, and that could be a significant boon to the ecosystem. So this is something to consider.

Essentially we wouldn't be adding any capability that you can't already do with a SW, but we'd be making it much easier and safer to do it, and that alone could be worth it if it convinces people to adopt our tech.

Now, turning to what I said above (the "PWA spectrum" and pushing people further along). While I still think that would be good to not have sites simply stop at Step 2, I acknowledge that going past Step 2 requires a significant re-architecture of an existing site, something which big existing sites might never get around to (or at least, not until they do a full rewrite). Even though it's not the best experience to have an "app" that just shows a blank page while it's loading, and a generic error when it's offline, it's still better for our users to be able to choose to use such an app, rather than not have it at all (or, only be able to access it through a web browser). Overall, if the app's primary functionality requires network access, it doesn't really matter what the offline / poor network experience is.

So I think I'm convinced that if we can provide an easier/safer way to let websites get over the hurdle into Step 2, we should look into it.

**Having said all that**, I'm still not convinced that the manifest is the right place to do this. It definitely seems like it should be part of the service worker ecosystem (even if it isn't done with a fetch handler). The manifest is how we define the metadata for the app; the SW is how we define its interactions with the network.

As @glennhartmann pointed out, this would require some way to specify what all of the resources (like images) are needed by the offline page, and get them cached and served correctly too. That makes it non-trivial for a site to support this; you can't just throw a single "offline_page" line into your manifest, you also need to wire into your build system a way to generate the list of resources used by the offline page in order to cache them. So I don't think this is a "quick and easy" fix for lazy sites that just want to be a PWA without doing engineering work to integrate this properly.

Rather than doing this in the manifest, I think it would be best to introduce a declarative mechanism into the Service Worker itself. If sites are too scared to add a fetch handler, maybe you can still add a SW but set up the offline caching and serving by calling setup functions in the install event handler:

```js
self.addEventListener('install', () => {
  self.addOfflineHandler("/offlinepage.html",
     {resources: ["/assets/heading.png", "/assets/style.css"]});
});
```

(Just a strawman proposal.) Basically a way of having service workers deal with this, since it really doesn't belong in the manifest.

The "addOfflineHandler" would tell the browser to automatically serve that page if any network request (or fetch handler) fails.

Now that we're talking about declarative routing in service workers, let's have a look at @jakearchibald 's [declarative router](https://jakearchibald.com/2019/service-worker-declarative-router/) proposal. I haven't had time to dig into this so I'm not sure if it solves the problem or not, but I'd be much more comfortable pushing this proposal into existing work being done by the Service Worker folks, rather than trying to come up with a run-around solution in the app manifest.

Those are my thoughts on this for now. Sorry this has been a very long essay; I have to run and [don't have time to make it any shorter](https://quoteinvestigator.com/2012/04/28/shorter-letter/)!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/774#issuecomment-515873875