There are three topics which I believe are of importance to web application developers. One is short-term urgence, one of mid-term need, and one of long-term aspiration.
This is a topic of short-term urgence. Implementations of app cache, storage, and offline support in browsers are, in theory, widespread, but in practice poor and buggy. Many developers try, and fail, to create reliable offline implementations of applications - not because the theory is hard (although it does have surprising gotchas) but because browsers behave unreliably. And by definition, developing and developing for offline behavior is a fiddly process: this is further hampered by browsers' weak debugging and inspection tools in this regard. Non-exhaustive examples of all of these issues include:
Some solutions might include:
Local storage and session storage only provide programmatic APIs, and app cache mostly provides a declarative API. The programmatic part of the app cache mechanism is highly event-centric and provides few imperative operations.
Although the intent is clearly to use app cache for application assets themselves (templates, scripts, styles, images, etc) and local storage for application data (records, stores, configuration), the boundaries are often blurred and developers try to use each for the other's purpose. (For example: newspaper apps trying to use app cache for articles, or apps like GMail using local storage for scripts to avoid app cache bugginess, as above)
The blurring of these two types of storage exacerbates the fact that their APIs are different, and I would propose, at the very least, a local-storage-like API for app cache to reconcile them.
So it should be possible to programmatically access the entries in the app cache, keyed by URL. It should be possible to add, update or delete each of these entries, and to read or write the contents of the file within each record (as well as query the metadata about each file's state).
All of this should be subject to cross-domain policies, of course.
One other nice side effect is that this will allow developers to programmatically retrieve and store binary objects in app cache without the overhead of base64 encoding them to place them in local storage (which itself is impossible without hacks like writing images to canvas and even then generally only when from the same domain).
This activity will allow applications to take far more granular and flexible control of how their own resources, modules, and plugins are loaded, allowing them to be requested on-demand and yet still benefitting from caching mechanisms.
If the web is to compete as a application runtime, applications written with a web technology stack must be indistinguishable from native apps. By this, I do not mean encouraging the pixel-precision of web apps mimicking their host OS and its native widgets, but the converse way in which operating systems treat web applications. For example:
(See also Windows 8 et al)
Again, it is understood that this is all subject to suitable policy & security considerations.
It is likely that this hybridization of web apps into host operating systems will be an important way in which the web (as a stack of technologies at least) ascends to its next level of ubiquity.