Web Storage API

If we compare the tools available to developers ten years ago to develop websites and the tools available today, we can literally put up a whole novel on it.

It's just that the novel would be heavy enough to be used in the gym, rather than being studied!

Today we have a huge inventory of APIs to work with and utilise their potential in our web applications. To name a few and perhaps the most dominant of them, we have:

1. The DOM API to manipulate the HTML structure of a webpage on-the-go
2. The XMLHttpRequest API which sits right at the heart of AJAX
3. The Event API to give life to a webpage by responding to users' actions
4. and the list goes on and on....

The API that we're interested in exploring right now is the Storage API.

It allows for a cleaner and more efficient way to store data on a client's computer.

Previously storing data on a client's computer was only limited to cookies, but with the advent of the Storage API, it's now possible to do numerous things that were previously considered impossible.

In this unit we shall explore the global properties localStorage and sessionStorage that are based on the Storage API and see how to use them to store data.

But before all that, let's first get a brief overview of the old-day polyfill of storing data on a client's computer - HTTP cookies.

Cookies were originally introduced to the web as an HTTP header.

They allowed a web server to track old users to one of its webpages and likewise make decisions on what to serve to these old users.

The idea was that when a user visits a webpage for example www.example.com, the server would send in a Set-Cookie header to the client setting up a cookie with a given name and a corresponding value.

Suppose we visit a webpage www.example.com, and the server at the backend wants to create a cookie visited with the value true. It'll send the following response header (amongst many other HTTP header):

Set-Cookie: visited=true

The browser will parse this header, and consequently create a small cookie file visited, holding the content true.

Now each time the same webpage www.example.com is requested for, on subsequent occasions, the cookie visited would be sent to the server, this time via the Cookie header.

Cookie: visited=true

The server at the backend would parse this header, extract out the cookie along with its value, and then provide some useful interface to query this cookie i.e retrieve it or change it.

And so in this way, the server could pass on information to be stored on a client's computer and then use that same information on subsequent requests to make important decisions.

In short, with the advent of cookies, it finally became possible for servers to remember old users.

The idea was splendid and its usage couldn't stop from going beyong the summit. However, soon cookies began to be misued!

Cookies were meant to store little amounts of data on the client's machine - data which was to be used by the server.

However, with the introduction of the document.cookie property, which allowed client-side JavaScript code to manipulate cookies as well, developers of websites began creating redundant cookies - ones that were never used by the server.

The cookies were used only by client-side JavaScript to make decisions on what to serve to the user; for example whether to change the background color to black if the user had previously selected a dark theme.

Not only this, but developers also began to store large amounts of data in cookies; once again redundant data.

Essentially, cookie data needs to be sent to the respective web server each time a webpage, which has access to those cookies, is requested for.

As you would agree, if we have a lot of cookies (and they are of no use to the web server) then the request will have a lot of overhead in it because of them and will likewise take a decent amount of time to be sent.

And this isn't it - usually the upload speeds of ISPs are slower than the corresponding download speeds they provide, which means that sending a huge box of cookies via the upload stream can cause a serious bottleneck in loading times, especially on those connections that already cough in downloading!

Just imagine it!

Moreover, web servers also tend to die when the size of an HTTP request, thrown at them, grows beyong the limits. Not surprisingly, cookies are the main culprit of this boundary-crossing.

And all this sounds even more gross when we see that the cookies have no use on the server i.e they are redundant cookies.

A cookie isn't a local dweller - it goes to-and-fro the client-server connection. If we just need a local dweller that stays just in the client's home, then why even bother to consider cookies!

This is exactly the idea that led to the birth of the Web Storage API.

The idea is simple - data remains on and is used by the client only.

Due to the fact that data stored using this API doesn't recide in HTTP requests, it's a definite recommendation for storing data that's only used locally, in modern web applications.

You talk about performance, efficiency, ease-of-use - the API has got all of it!

Now that we know the reason for the creation of the Storage API, it's time to dive right into it and explore it to the core.

In the next chapter we shall start with localStorage that works on a persistent storage mechanism and after that move to discover sessionStorage that's based on a temporary session-driven storage mechanism.

Both these global properties are based on the Storage API - it's just that one stores differently than the other one - except for this everything on both these properties is exactly the same.

So with the track all set up, we are only far from sitting in the ride and beginning our journey to unravel modern web storage.

Are you ready to ride in?