Here’s the presentation I gave for the first edition of LyonJS. Firefox or Chrome are required to view those slides, sorry to the others, I’ll try to fix that next time.
I’d like to reorient my conclusion slightly, after the discussion we had at the end of my talk.
As it has been pointed out, offline webapps are not the only use-case for appcache. It can also be used for all webpages that get their content from third party webservices, through ajax APIs. This is the case for ParisJS.org, LyonJS.org and a growing number of websites that are pure mashups of other webservices.
You forgot to say please
In this case, the benefits are better performances. But my point is that, if appcache needs some improvements (and I think it does!), the goal shouldn’t be to make it the webperf hammer of every website. There is one unique reason for that: the browser should be the one in charge of deciding what deserves to be cached, and what should be evicted from it. We can’t let every website store 200K-1M of resources on a device without asking for permission and providing a simple UI to free memory.
I actually believe that “asking for permission” is not the best option we can come up with, as users shouldn’t have to manage websites like installed app (if they’re not meant to work offline), this would feel backward. I’d like to see an “evictable” flag being added to the spec (just like the one proposed for indexedDB) that would let the browser know that it’s safe to remove a cache group when needed. With such a flag, user’s consent wouldn’t be required to let websites use appcache. For offline webapp, users would have to grant permissions and they would be the one in charge of “uninstalling” the webapp.
Would that be an acceptable behavior for you?