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

I have a bad neck from nodding along to https://github.com/w3c/manifest/issues/774#issuecomment-515257608.


TL;DR: folks wanting to reanimate the corpse of appcache need stronger justification 😀

The "offline page" pattern still leaves you with the most frustrating experience, staring at a white screen while your device spends minutes figuring out it doesn't really have a connection at all. Of course, someone will suggest "let's add a timeout option!", but is that timeout based on first byte? What if the first byte arrives and then it hangs? "Let's add an option for that too!" What if the connection failed, not because of "offline", but because of some other fetch failure such as SSL, or an invalid redirect? "We'll add options for that as well!" But what if you want different offline pages for different parts of the app? "MOAR OPTIONS!" etc etc and welcome to appcache.

You can't put a `debugger` statement in a JSON file. Once you go beyond the very simplest of cases, figuring out the rule-order and quirks of your DSL becomes much harder than imperative code.

As @mgiuca points out, even if we ignore the option complexity, this solution is a dead-end. It leads you to a bare minimum, not-great offline experience, and it isn't a stepping stone to something better.

The [declarative router proposal](https://jakearchibald.com/2019/service-worker-declarative-router/) was about trying to meet somewhere in the middle. The routes are declared with JS, so you can write logic to express the conditions and order. But still, you'd need to make up for the lack of `debugger;`. You'd need to add strong devtools to show the routes in play, and which route was used for a particular request. It also allows you to specify different routes for different paths, and doesn't restrict you to 'offline' pages.

-- 
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-515924211

Received on Monday, 29 July 2019 09:47:10 UTC