If there is one area where native apps definitely outrule web applications, it is persistent local storage. For native applications, the OS provisions for application-specific data like preferences or running state. This info may be stored in the registry, .ini files, or any other format or place per the operating system convention. If the native client needs massive data beyond smaller preferential data, you may use a database, the file system, or invent your your own file format; the possibilities are endless, and you can store MBs and GBs of local data.
On the other hand, what do most web applications have to store local data? A measly 4 KB cookie? Cookies were invented in the early days of the web’s history, and have gone through very little changes since invention by Lou Montulli of Netscape Communications in 1994.
While cookies are an optimal and efficient way for some use cases like session management, there are a few potential limitations:
- Cookies are included with every HTTP request, needlessly transmitting data to and fro the server over and over again, thereby slowing down the application.
- The data so transmitted is not encrypted, thereby rendering it unfit for sensitive information.
- Cookies are limited to 4 KB of data, which is not really useful for large data, but enough to slow down the application if sent over again
Other client-side storage mechanisms
There have been many attempts in storing large quantities of client side data without being ever sent to the server, and persisting across browser sessions:
- With the launch of Internet Explorer, Microsoft invented a few things to end the first browser war, including DHTML Behaviors. One of these behaviors, called userData, allowed webpages to store up to 64 KB per domain, and 10 times that for trusted sites such as Intranet sites.
- In the Flash 6 launch in 2002, Adobe introduced Local Storage Objects notoriously known as Flash Cookies, which can also store data more complex than simple text, unlike cookies, and allow 100 KB per domain. Shared objects can’t do anything to or with the data on your computer, and you can control the storage of local shared objects through the Flash Player Settings Manager.
- Flash cookies laid the foundation for an early prototype of a Flash-to-JavaScript bridge called AMASS (AJAX Massive Storage System), but it was limited by some of Flash’s design quirks. By 2006, with the advent of ExternalInterface in Flash 8, accessing LSOs from JavaScript became an order of magnitude easier and faster. AMASS was rewritten and integrated into the popular Dojo Toolkit under the moniker dojox.storage.
- In 2007, Google launched Google Gears, an open source browser plugin aimed at providing additional (storage) capabilities in browsers. Gears provides an API to an embedded SQL database based on SQLite. After obtaining permission from the user once, Gears can store unlimited amounts of data per domain in SQL database tables. Google used this for quite a while for its offline GMail before sunsetting Gears completely in March 2011 favour of HTML5.
The HTML5 Web Storage
All of the aforementioned approaches are either specific to a particular browser, or rely on a third-party plugin, have radically different interfaces and variable storage limitations, and present different user experiences. HTML5 Web Storage solves this problem by providing a standardized API, implemented natively and consistently in multiple browsers.
Web Storage is being standardized by the W3C. It was originally a part of the HTML5 specification but was later extracted out to its own specification. It is a way for web pages to store named key/value pairs locally, within the client web browser. Like cookies, this data persists even after you navigate away from the web site, or exit your browser. Unlike cookies, this data is never transmitted to the remote web server. Unlike all previous attempts at providing persistent local storage, it is implemented natively in web browsers, so it is available even when third-party browser plugins are not.
Web Storage is also referred to as Local Storage or DOM Storage, though Local Storage is just one type of Web Storage. The other type is session storage, and the difference being, local storage doesn’t have an expiry date, while the session storage expires as soon as you terminate the browser session.
The API, the works
HTML5 Storage is based on named key-value pairs. Data is stored based on a named key, and can be retrieved using the same key, very similar to cookies. Also, both the named key and values are strings. The data can be any type supported by JavaScript, including strings, Booleans, integers, or floats, but is converted to string before saving, and has to be cast back using methods like parseInt() and parseFloat() to the expected datatype.
From your JavaScript code, you can access HTML5 Storage through the localStorage object on the global Window object. Each site has its own separate storage area.
The API uses a Storage interface, one attribute each for localStorage and sessionStorage, and a storage event.
interface Storage {
readonly attribute unsigned long length;
DOMString? key(unsigned long index);
getter DOMString getItem(DOMString key);
setter creator void setItem(DOMString key, DOMString value);
deleter void removeItem(DOMString key);
void clear();
};
The Storage interface specs, in addition to the getter, setter and deleter for a key, a list-like implementation where key(n) should return the nth key. Session storage and local storage do not implement Storage, but use composition to include an attribute of Storage:
interface WindowSessionStorage {
readonly attribute Storage sessionStorage;
};
Window implements WindowSessionStorage;
interface WindowLocalStorage {
readonly attribute Storage localStorage;
};
Window implements WindowLocalStorage;
The sessionStorage attribute represents the set of storage areas specific to the current top-level browsing context. Each top-level browsing context has a unique set of session storage areas, one for each origin. The localStorage object provides a Storage object for an origin.
Like other JavaScript objects, the localStorage object can be treated as an associative array. Instead of using the getItem() and setItem() methods, you can simply use square brackets. For example, both these usages are valid:
var visitorCount = localStorage.getItem(“pluggd.in.page.count”);
var visitorCount = localStorage[“pluggd.in.page.count”];
A StorageEvent is fired on the window object whenever setItem(), removeItem(), or clear() is called and actually changes something. The StorageEvent object contains the item key, the old and the new values, and the url of the page that triggered this change. The StorageEvent is not cancelable, and which uses the StorageEvent interface at each Window whose Document has a Storage that is affected.
Security is maintained by user agents, that throw a SecurityError exception whenever any of the members of a Storage object originally returned by the localStorage attribute are accessed by scripts whose effective script origin is not the same as the origin.
Browser Support
The HTML5 Web Storage is supported in most of the browsers, IE8+, Firefox 3.5+, Safari 4.0+, Chrome 4.0+, and Opera 10.5+. Here is a small JavaScript function to test whether your browser supports HTML5 storage:
function supportsHtml5Storage() {
try {
return 'localStorage' in window && window['localStorage'] !== null;
} catch (e) {
return false;
}
}
Alternatively, if you want to test using just the browser, Ctrl C–Ctrl V the following in your browser’s address bar:
javascript:alert(‘localStorage’ in window && window['localStorage'] !== null);
For browsers that do not support HTML5, I believe you should stop supporting and using them, you can use HTML5 cross-browser polyfills. Here is a readymade localStorage polyfill that claims to be the best localStorage polyfill in the world.
Beyond key-value pairs
Though a relatively new concept and much advantageous, Web Storage still uses key-value pairs, a la HTTP Cookies. The good news is that there is work going on for more complex data structures.
One of these is the Web SQL Database, taking cues from Google Gears, an open source cross-browser plugin which included an embedded database based on SQLite. The early prototype later influenced the creation of the Web SQL Database specification. Web SQL Database provides a thin wrapper around an SQL database, allowing you to manipulate client-side databases using SQL. As of now this is supported only by Chrome, Safari, and Opera browsers.
The second is an Indexed Database API, a proposed web browser standard interface for a local database of records holding simple values and hierarchical objects. It does so by using transactional databases to store keys and their corresponding values, and providing a means of traversing keys in a deterministic order, implemented using persistent B-tree data structures. IndexedDB is supported by Firefox 14+, and only partially by Chrome 21+. It will be fully supported by Chrome 23 and IE10.0.
Web Storage is a robust, faster way of storing client side data. While the past is littered with hacks and workarounds, the present condition of HTML5 Storage is surprisingly rosy. With all these new support and development going around Web Storage, there is quite a lot to be seen in the future, some of which may be in another Tech Treats post.
»
Web Storage HTML5 API: Cookies are so 1994 [Tech Treats] @
Pluggd.in.
Link to full article
