Re: HTML5's Offline-first Council of Trent

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
[2] 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 ™ [1]: -



*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$ [4]



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 [3] “Close enough is good enough!”.



[1] http://images.clipartpanda.com/amish-clipart-68145_134_w11-14_s_lg.gif

[2] https://en.wikipedia.org/wiki/IBM_3270

[3] http://farm8.static.flickr.com/7278/7852694410_b2d8aa034c.jpg

[4]* 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 <jaffathecake@gmail.com>
wrote:

> On Tue, 15 Mar 2016 at 12:14 Richard Maher <maherrj@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.
>
>