Look Jake, your entire argument is premised on the abstract notion that “cached data is often fine”. Allow me to respond with an equally unquantifiable “EXCEPT WHEN IT BLOODY ISN’T”.
I’ve been cutting code for over 30 years and am very familiar with scenarios where cached data is appropriate and if history is any guide it tells us that server-level caching is the most effective (especially with sophistication levels as high as Oracle’s cluster-wide Cache-Fusion). The Fat-Client pattern came and went 20 years ago as far as I’m concerned but if you, and others at W3C, are happy to breathe new life into the IBM 3270  architecture by re-implementing it on the Web, then more power to you. Those like myself who have gotten used to features such a server-hosted character-by-character predictive-text, real-time banking, and trading, are loathed to take such an enormous step backwards. You appear to have a marvelous solution, but I and many others are not experiencing your perceived problem(s). The very real problem we are experiencing is the disproportionate resource and funding allocation from browser vendors toward infrastructure and functionality targeted at social-media. Not everything is Twitter and Email for Pete’s sake or, for that matter, an RSS aggregation of this morning’s newspapers. Give us background GPS, give us some sort of broadcast/multi-cast Push API capability without 1:1 notifications, just give us the tools to compete with native apps and we’ll do the rest! Anyway, if the decorum police will agree to stay their truncheons for a moment longer and indulge my use of satire, parody, and metaphor, in making an extremely valid technical point, I’d like to introduce to you the latest Web-App offering from HTML5 Horse-First Laboratories ™ : - *The Bud Fox Day-Trader App* The true beauty of this Web App is that it doesn’t matter one iota what time-zone you’re in as you can always buy and sell at a price that suits your cache$  Wall Street may be closed, you could be going through the Channel Tunnel, or you could simply be on the dark side of the moon, but BF Day-Trader will let you buy or sell virtually straight from your stock portfolio! *“But what if the current stock price is different to what I’m seeing and trading in?” * This is where Day-Trader shines above all the Native Apps that have to submit to the laws of physics as well as the governance of the Securities and Exchange Commission. Your trades don’t happen in real-time either! A background-sync job will get around to transmitting your trade to the Stock Exchange as soon as your network usage limits allow. By then the stock price could well be what you bid for in the first place anyway. How good is that! In the words of our Systems Architect  “Close enough is good enough!”.  http://images.clipartpanda.com/amish-clipart-68145_134_w11-14_s_lg.gif  https://en.wikipedia.org/wiki/IBM_3270  http://farm8.static.flickr.com/7278/7852694410_b2d8aa034c.jpg * Cache$ (Uselessness is relative concept)* Cache$1 - This is the red-hot highly volatile repository for stocks that you traded in the last week. Memory consumption is critical so less than 100 stocks are resident here and refresh rates can be almost hourly depending on network availability. Cache$2 – Overflow from Cache$1 into perpetuity. IndexDB – At installation time every stock on the planet and last bid is copied to your phone. Most DBAs will tell you that the best way to replicate data is “not at all” but tell that to Thurston Howell III. You just never know when you’ll have to trade from a deserted island. On Tue, Mar 15, 2016 at 10:20 PM, Jake Archibald <jaffathec...@gmail.com> wrote: > On Tue, 15 Mar 2016 at 12:14 Richard Maher <mahe...@googlemail.com> wrote: > >> Your willingness, nay preference, to serve up stale, outdated data, is an >> exercise in self-flagellation that only a fellow sicko could understand >> > This is not the intent in the pattern you quote ( > https://jakearchibald.com/2014/offline-cookbook/#cache-then-network). > > The goal is to get cached data on screen then update it. This is because > cached data is often fine as a first pass. > > If I'm going to my messaging app to remind me where I agreed to meet > someone, cached data is fine. If I'm going to my fitness app to find out > how long it took me to run two miles last week, cached data is fine. If I'm > looking up the day for my flight, cached data is fine. > > But it doesn't stop there. The network is used, if available, to update > both the content on the screen (in some non-disruptive way) and in the > cache. > > The benefit of having data locally on the device is you don't need an > internet connection to get it, if you refuse to show it until a network > request as settled or timed out, you're throwing away the benefit. > > The offline-first pattern not only improves things for offline users, it > improves things for everyone whose connection to the internet is slower > than their device's storage. > >