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
- 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 ResultsSession 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.
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.
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
is extremely easy. It is like defining and using a regular variable, except
that it needs to be prefixed with
Here is the code to define, access and remove a session variable:
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.
object is functionally identical to the
object. They only differ in persistence and scope.
localStorageis used for long-term storage. Its data persists even after the window is closed. The data stored in
sessionStorageis lost when the browser window closes.
localStoragedata is accessible across all browser windows while
sessionStoragedata is confined to the browser window that it was created in.
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.