Appcache & Beyond

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.

Appcache use-cases

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, 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.

“Evictable” appcache

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?

3 thoughts on “Appcache & Beyond

  1. Tobie Langel

    Whether we like it or not, AppCache is going to be used to improve performance of online websites. It simply has more to offer than HTTP cache does. Regarding the ability to evict AppCaches, that’s already part of the spec which reads:

    As a general rule, user agents should not expire application caches, except on request from the user, or after having been left unused for an extended period of time.

    Unlike indexedDB, AppCache is a cache (heh!) not a store, the data stored in there shouldn’t be critical or you’re really doing something wrong.

  2. louisremi Post author

    If you’re developing a webapp that is intended for offline use, the resources probably are critical. But the browser could certainly take the initiative to uninstall it after several months, if not a year.
    And I’m not the only one viewing it as an “(offline) application store” rather than a cache.

  3. Tobie Langel

    I guess it depends what you mean by critical. There’s a very big difference between needing to be online to use an app that you haven’t touched in a year or having lost the document you crafted back then and hadn’t sync’ed with the server.

    AppCache isn’t meant to store stuff that relates to the latter. It’s meant to cache resources. Not user generated data. That’s what localStorage / IndexedDB are for.

    I’m not sure what you mean when quoting Hixie’s “(offline) application store” definition. Care to elaborate?

Comments are closed.