march 2017

Offline or local usage of web sites and apps has some nice applications. The most well known is probably a mobile offline web app, that could be almost indistinguishable from a native mobile app.

There are many different technologies and terms you might encounter. Here I will summarise most of these and give some pointers what to use when.

• Accessing your applications whilst offline.
• Storing application data offline.
• Working with the local file system.
• Data communication between client and server.

If you use all of the above you will be able to create a fully offline web app, that optionally gets new data when online. Each of the technologies described below is known by multiple different names. I have mentioned every name I could find for each tech to prevent some of the confusion I felt myself when diving into this subject.

To find out if a particular technology is supported in a particular browser use caniuse.com.

During app usage, you should ensure that its state is saved periodically to the offline data store. Also you might want to save the state locally when user closes the app (though not all technologies allow this).

Web Storage / localStorage / Storage API / DOM Storage

Web Storage is a method of storing data locally like cookies, but for larger amounts of data (sessionStorage and localStorage, used to fall under HTML5). Web Storage was designed for smaller amounts of data. It's essentially a strings only key - value storage, with a simplistic synchronous API. Because of this not useful for large data amounts.

The Web Storage API provides mechanisms by which browsers can store key/value pairs, in a much more intuitive fashion than using cookies. The two mechanisms within Web Storage are as follows:

• sessionStorage maintains a separate storage area for each given origin that's available for the duration of the page session (as long as the browser is open, including page reloads and restores)
• localStorage does the same thing, but persists even when the browser is closed and reopened.

These mechanisms are available via the Window.sessionStorage and Window.localStorage properties (to be more precise, in supporting browsers the Window object implements the WindowLocalStorage and WindowSessionStorage objects, which the localStorage and sessionStorage properties hang off). Invoking one of these will create an instance of the Storage object, through which data items can be set, retrieved and removed. A different Storage object is used for the sessionStorage and localStorage for each origin. They function and are controlled separately.

Summary:

• Limit of ~5MB.
• Access to Web Storage from third-party iFrames is denied if the user has disabled third-party cookies.
• Since iOS 5.1, Safari Mobile stores localStorage data in the cache folder, which is subject to occasional clean up, at the behest of the OS!
• Supported in all major browsers.

Web SQL (deprecated)

Web SQL is a method of storing data client-side, allows Sqlite database queries for access and manipulation. Web SQL is basically SQLite but embedded in the browser, which would make it accessible to HTML5. However, the Web SQL specification is no longer being maintained and although it is supported on iOS and Android browsers, support may be dropped in the future.

Summary:

• Deprecated.
• Supported in Chrome and Safari.

IndexedDB

IndexedDB is a method of storing data client-side, allows indexed database queries. Where SQLite provides a typical relational database approach, IndexedDB provides a NoSQL approach. This means that data is stored as objects rather than in tables. NoSQL databases are generally considered to be faster and more scalable than SQL databases, and since there is no pre-defined schema it is really easy to add new data. This is a bit of a double edged sword, this less structured approach isn’t necessarily a good thing in all cases, nor is it a bad thing – it all depends on the circumstance and preference. For easier usage there is dexie.js, a wrapper for IndexedDB that allows fast code development via a nice, simple syntax.

Summary:

• Supported in all major browsers.

localForage

To get up and running quickly with offline data you don't need to choose a specific data storage option: Use localForage instead! This is a handy library that abstracts away the differences in cross browser support for offline data technologies. It provides asynchronous data storage via IndexedDB for browsers that support it; it then falls back to WebSQL for browsers that support that, and localStorage for browsers with even more basic support.

NB: localForage does not work if called from a local file:// uri. You need to serve it using a webserver.

NB: localForage serialises objects, and this does not work for objects with enumerable methods (functions) in them.

Syncing with server side

Your app should also save its data back to the server periodically. If your app is offline you should consider building a queueing solution that can handle a lack of connectivity, aiming to save the updates once the network is available again. See handy libraries for this such as PouchDB.

All of the technologies below are supported in all major browsers.

Polling

To communicate with the server the simplest and wordt solution is Polling. Just fire a request repeatedly from the client to the server to sent or receive data. Very wasteful on resources.

Long polling / Hanging GET / COMET

This is a slight variation on polling. In long polling, if the server does not have data available, the server holds the request open until new data is made available. Hence, this technique is often referred to as a "Hanging GET". When information becomes available, the server responds, closes the connection, and the process is repeated. A more advanced version of this technique is COMET.

Server-Sent Events / SSE / EventSource

SSE is a method of continuously sending data from a server to the browser, rather than repeatedly requesting it (EventSource interface, used to fall under HTML5). When communicating using SSEs, a server can push data to your app whenever it wants, without the need to make an initial request. In other words, updates can be streamed from server to client as they happen. SSEs open a single unidirectional channel between server and client.

The main difference between Server-Sent Events and long-polling is that SSEs are handled directly by the browser and the user simply has to listen for messages. Why would you choose Server-Sent Events over WebSockets? In some scenarios data doesn't need to be sent from the client. You simply need updates from some server action. A few examples would be friends' status updates, stock tickers, news feeds, or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexedDB object store). If you'll need to send data to a server, XMLHttpRequest is always a friend.

SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.

NB: SSE is not supported in IE and Edge. There is a polyfill for this: EventSource.js

WebSockets

WebSockets is a bidirectional communication technology for web apps to asynchronously communicate with a server.

They provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions.

Finne Fortuin is Drupal development and deployment configuration expert. He also dabbles in JavaScript and offline (game) applications.