# Sencha Offline Web Apps Workshop Position Paper

### Author: James Pearce, Sencha

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.

#### 1. Poor current implementations & documentation

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:

- unreliable offline/online events in developer & mobile environments
- an inability to clear the appcache or localStorage in a browser, either a) separately from cookies or other caches, or b) per domain
- an inability to view cached files while developing
- 404 on a single file invalidating an entire cache
- namespace collisions when manifest files from different domains have the same filename
- undefined behavior with 'ctrl-refresh' to force reload
- inability to easily debug the behavior of mobile device browsers (not a problem specific to offline apps alone, but certainly an exacerbating challenge)

Some solutions might include:

- real-world walkthroughs (see http://www.sencha.com/learn/taking-sencha-touch-apps-offline )
- a decent compliance test suite for browsers' offline support
- dedicated debug UIs for offline assets & behavior
- some way to mark apps as being 'in development mode' so that developers can iterate fast without cache impedance

#### 2. Improve the programmatic app cache API

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.

#### 3. Encourage browsers and operating systems to treat web apps as first-class apps

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:

- Allow web applications to programmatically claim fullscreen, chrome-less windows
- Allow web applications to be 'added to homescreen' as first class apps
- Allow task switching between web applications as though native
- Allow web apps to appear in process lists, complete with CPU, memory profiling etc
- Web intents to allow web apps to register as recipients of tasks requested by other apps
- Device API access of course

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