HTML 5: Client-side Storage | WebReference

HTML 5: Client-side Storage

By Arpan Dhandhania

What is client-side storage? In a few years, all our files and documents will be stored in the cloud. We won't be storing anything on our desktops. While this has several advantages, such as location independence, data accessed over the internet can never be as speedy as accessing data locally. No matter how fast the internet connection, it can't compete with data being read locally from your hard drive. At a macro level, everything is moving towards the cloud and less and less data is been stored locally by users. However, at a micro level, specifically with browsers, a lot of data is being stored on the client side. The following are the reasons:

  • more responsiveness
  • reduced load on server
  • increased accessibility (you are remembered on your computer, you don't need to login every time)

How is client-side storage achieved?

The most popular method for local storage in all browsers has been the good old HTTP cookies. Cookies are key-value pairs of strings that are stored locally in a text file and are sent to the server with every HTTP request that goes to the same domain name. There are a few other browser-specific or plugin-dependent methods like:

  • userData: in Internet Explorer 5.5 and above.
  • Local Shared Object: part of the Adobe Flash Player browser plugin.
  • Google Gears: a plugin for Mozilla Firefox and Internet Explorer.

In an attempt to resolve this chaos and standardize client-side storage, the Web Hypertext Application Technology Working Group (WHATWG) came up with a well-structured client-side storage solution, which is part of the HTML 5 specifications approved by W3C. As you must already be aware, HTML 5 is a work in progress and is being implemented in browsers in phases. Fortunately, for us, client-side storage is one of those features that have already been implemented in most popular browsers like Safari, Firefox and Internet Explorer.

HTML 5's Client-side Storage

Client-side storage is probably one of the most talked about features in HTML 5. It has received a lot of criticism because of its lack of security, but it is nonetheless an interesting innovation. Client-side storage is divided into 3 methodologies:

  • Session storage.
  • Local storage
  • Database storage

Before we plunge into the details of each methodology, it might interesting to see if your browser supports all storage methods.

Browser Feature Test Results

Session Storage: not supported
Global Storage: not supported
Local Storage: not supported
Database Storage: not supported

In case your browser doesn't support the storage methods that we just tested, I suggest you upgrade your browser because they are required for the examples that will follow.

Session Storage

I suppose you know what HTTP cookies have to offer and how they function. Session storage isn't much different from that. It, however, has some additional benefits.

  • Cookies are limited to 4 kilobytes of space, which can sometimes be a little restricting. Session storage allows much more space. Depending on the browser implementation, the exact space can vary, but it usually runs into megabytes.
  • Cookies are sent to the server with every HTTP request. Session data, however, isn't sent automatically. This reduces the payload that goes with every request. The developer can choose which key-value pairs need to be sent with each request.
  • Most e-commerce sites use cookie-based authentication to remember which user is logged in on a computer, or more specifically browser session. If two users want to shop from the same site from two windows of the same browser, it is not possible because cookies are tied to the browser session. With session storage, this can be done as it is tied to the browser tab/window. As each tab/window maintains its own session information, as far as the site is concerned, the users are accessing their accounts from different systems.

sessionStorage should be used to store ephemeral data related to a single browser window as it doesn't persist after the window is closed. Using sessionStorage is extremely easy. It is like defining and using a regular variable, except that it needs to be prefixed with sessionStorage.

Here is the code to define, access and remove a session variable:

Local Storage

The early drafts of HTML 5 introduced a storage mechanism called Global Storage. In short, it is a memory space given by the browser that websites can use to store persistent data that doesn't need to be sent to the server. The data is accessible by JavaScript and therefore by Flash (this feature is mainly used by Flash games). According to the specifications, you can define global storage objects in the following manner:

The specifications also mention that all the domains at an equal or lower level of the one defined for a global storage object can access its storage data. Fortunately browser developers didn't implement it as per specifications. They never supported public data storage and specifically not top-level-domain data access. Firefox in fact went to the extent of blocking access to any domain other than the one you specify.

After the browsers implemented their version of global storage, and their implementation made sense, WHATWG modified the specifications. They replaced global storage with local storage where you cannot specify domains; the data you store is automatically associated with the domain under which the script is running.

The localStorage JavaScript object is functionally identical to the sessionStorage object. They only differ in persistence and scope.

  • Persistence: localStorage is used for long-term storage. Its data persists even after the window is closed. The data stored in sessionStorage is lost when the browser window closes.
  • Scope: localStorage data is accessible across all browser windows while sessionStorage data is confined to the browser window that it was created in.

Database Storage

Session and local storage are both string-based key-value pairs. When you are dealing with a larger amount of content, it would be nice to be able to store it in a structured manner and be able to access it randomly. If you're thinking of a database, you are absolutely right. With HTML 5, you get database storage, which allows you to save structured data in the client's machine using a real SQL database. So far, I think Safari is the only browser to have implemented this feature. It uses SQLite database, which is light and fast but has a few limitations like its lack of foreign key constraints. You should remember that this is not the primary database, it is merely to store temporary data that can be accessed when the client is disconnected for a brief period of time. You will need to spend some time to figure out what data you really want to store in the client-side database.

Here is example code for accessing the local database:

I believe that the current local database implementation is not quite fit for use, because of a few basic deficiencies such as the data is not encrypted and accessible by anyone and that there is no way to directly sync the local database with the one on the server. Having said that, I also believe that local database is going to be one of the key features in the future of browsers.