There are majorly two types of applications that can be used on a client – native applications and web applications. Persistent storage is an arena where the native applications have an edge over their counterparts, the web applications.
In order to serve the storage requirements of persistent applications, there are a variety of options available, viz. registry, INI files, XML files, database storage, etc. If there is a requirement to store data beyond the standard key-value pairs, a custom file format can also be invented. Conventionally, the web applications have had no such luxuries where they could persist data.
Enter –> Cookies
Cookies were invented long ago to overcome this drawback and store data for web applications. In the beginning, they seemed to be a good solution, but, with the advent of time, few drawbacks were found in them:-
- Cookies are included with every HTTP request, thereby slowing down the web application. It needlessly transmits the same data over and over again.
- Cookies are included with every HTTP request, thereby sending data unencrypted over the internet (unless the entire web application is served over SSL).
- Cookies are limited to about 4 KB of data.
All that was required was a large storage space at the client end that could persist data beyond page refresh and the information does not get transmitted to the server. Before HTML5, all the attempts to achieve this were largely unsuccessful.
Local-Storage hacks before HTML5
userData: It allows web pages a storage of upto 64KB per domain in hierarchical XML based structure. For trusted web pages, such as intranet, the limit could be 640 KB, about 10 times more.
Local Shared Objects: This feature was introduced by Adobe within Flash. It also came to be known as the Flash Cookies. It allowed storage upto 100 KB per domain without any restrictions. Beyond that it would ask the user for each magnitude increase in the data storage.
Gears: This was introduced by Google. It provided APIs to an embedded SQL database based on SQLite.
Modern Solution : Web Storage or localStorage
The requirement of larger persistent storage for web applications led to the invention of HTML5 storage called the Web Storage. It also came to be known as localStorage. This is a storage mechanism within the browser itself. Almost all modern browsers, by default, support localStorage.
What is localStorage?
Simply put, this is a storage mechanism locally within the browser where the data is stored as a key-value pair. Just like cookies, the data would persist even after navigating away from the page, closing the tab, closing the browser or restarting the machine. But unlike cookies, this data is never, automatically, transmitted to the web-server, unless some crazy programmer decides to send the localStorage data manually to the web-server. It does not require any third-party plugins as it is implemented natively in web browsers.
- Set a value:-
eg. localStorage[‘foo’] = “your data here”;
eg. localStorage.setItem(‘foo’,’your data here’);
- Get a value:-
eg. var a = localStorage[‘foo’];
eg. var a = localStorage.getItem(‘foo’);
- Delete a value:-
Tracking changes to HTML5 localStorage area
In order to track changes to the localStorage, the ‘storage’ event can be trapped using event-listeners.The storageevent is fired on the window object whenever setItem(), removeItem() is called and actually changes something.
The storage event is supported everywhere the localStorage object is supported, which includes Internet Explorer 8. IE 8, however, does not support the W3C standard addEventListener().