

The Offline Cookbook: caching and serving offline-first - jaffathecake
http://jakearchibald.com/2014/offline-cookbook/

======
pavel_lishin
I wonder if there's a support group for AppCache survivors. Someplace people
can meet, and talk about how AppCache has hurt them. Someplace with a nice,
strong cell signal, and complimentary wifi.

------
aboodman
I expect people will try different things with SW, but that the pattern for
offline will end up being basically what appcache implemented.

That's because there's really only one way to do it: you split your app into a
client/server model, where the client (the ui resources) are updated
transactionally in the background and swapped into place when they are ready,
and there's a local datastore that serves as a cache of the truth and a queue
of pending changes.

ServiceWorker is more flexible and powerful than appcache, and you can do
other (non-offline related) things with it. That's great. But the fundamental
model for building an offline-capable applications is well-understood and
unlikely to change. It's the model that all mobile applications frameworks
use, what desktop apps used before, and what appcache implemented.

~~~
jaffathecake
[http://jakearchibald.com/2014/offline-cookbook/#putting-
it-t...](http://jakearchibald.com/2014/offline-cookbook/#putting-it-together)
\- here I cover the techniques I used to create a very simple timeline-based
app, sort-of Twitter-like. AppCache can only do one of those patterns, the one
that handles static assets, and of course you open yourself up to appcache's
quirks such as master entries.

AppCache can just about handle static assets. Just about. That's not enough
for most apps. Look at the patterns in the article and their use-cases.

