A Place To Put Your Stuff

1.   Cookies have three potentially dealbreaking downsides:

 

  a)  C ookies are included with every HTTP request, thereby slowing down your web application by needlessly transmitting the same data over and over

  b)   Cookies are included with every HTTP request, thereby sending data unencrypted over the internet (unless your entire web application is served over SSL)

  c)   Cookies are limited to about 4 KB of data — enough to slow down your application (see above), but not enough to be terribly useful

 

2.   Microsoft invented DHTML Behaviors , and one of these behaviors was called userData . userData allows web pages to store up to 64 KB of data per domain, in a hierarchical XML-based structure. IE does not present any form of permissions dialog, and there is no allowance for increasing the amount of storage available.

 

3.   In 2002, Adobe introduced “Flash cookies” in Flash 6. The feature is properly known as Local Shared Objects . Briefly, it allows Flash objects to store up to 100 KB of data per domain. By 2006, with the advent of ExternalInterface in Flash 8, accessing LSO s from JavaScript became an order of magnitude easier and faster. Brad rewrote AMASS and integrated it into the popular Dojo Toolkit under the moniker dojox.storage .

 

4.   In 2007, Google launched Gears , an open source browser plugin aimed at providing additional 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. This early prototype later influenced the creation of the Web SQL Database specification. By 2009, dojox.storage could auto-detect (and provide a unified interface on top of) Adobe Flash, Gears, Adobe AIR, and an early prototype of HTML5 storage that was only implemented in older versions of Firefox.

 

5.   HTML5 Storage 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, close your browser tab, exit your browser, or what have you. Unlike cookies, this data is never transmitted to the remote web server (unless you go out of your way to send it manually). 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.

 

6.   You’ll access HTML5 Storage through the localStorage object on the global window object.

 

7.   HTML5 Storage is based on named key/value pairs. The named key is a string. The data can be any type supported by JavaScript, including strings, Booleans, integers, or floats. However, the data is actually stored as a string. If you are storing and retrieving anything other than strings, you will need to use functions like parseInt() or parseFloat() to coerce your retrieved data into the expected JavaScript datatype.

interface Storage {

  getter any getItem(in DOMString key);

  setter creator void setItem(in DOMString key, in any data);

};

 

Calling setItem() with a named key that already exists will silently overwrite the previous value. Calling getItem() with a non-existent key will return null rather than throw an exception.

 

 

8.   You can treat the localStorage object as an associative array:

var foo = localStorage["bar"];

// ...

localStorage["bar"] = foo; 

 

 

9.   There are also methods for removing the value for a given named key, and clearing the entire storage area (that is, deleting all the keys and values at once).

interface Storage {

  deleter void removeItem(in DOMString key);

  void clear();

}; 

 

 

10.   There is a property to get the total number of values in the storage area, and to iterate through all of the keys by index (to get the name of each key).

If you call key() with an index that is not between 0–(length-1), the function will return null .

interface Storage {

  readonly attribute unsigned long length;

  getter DOMString key(in unsigned long index);

};

 

 

 

11.   The storage event is fired on the window object whenever setItem() , removeItem() , or clear() is called and actually changes something. If you set an item to its existing value or call clear() when there are no named keys, the storage event will not fire, because nothing actually changed in the storage area:

if (window.addEventListener) {

  window.addEventListener("storage", handle_storage, false);

} else {

  window.attachEvent("onstorage", handle_storage);

};

 

The handle_storage callback function will be called with a StorageEvent object, except in Internet Explorer where the event object is stored in window.event .

 

 

function handle_storage(e) {

  if (!e) { e = window.event; }

} 

 

 

12.   A StorageEvent object, which has the following useful properties:

 The storage event is not cancelable. It’s simply a way for the browser to tell you, “hey, this just happened. There’s nothing you can do about it now; I just wanted to let you know.”

 

13.   By default, the storage space is 5 megabytes across browsers, although it is phrased as no more than a suggestion in the HTML5 Storage specification. One thing to keep in mind is that you’re storing strings, not data in its original format. If you exceed your storage quota of 5 megabytes, you will get a “QUOTA_EXCEEDED_ERR ” exception. No browser supports any mechanism for web developers to request more storage space, although it can be a user-initiated action to control the storage space for some browsers.

 

14.   Another competing vision for advanced, persistent, local storage for web applications: the Indexed Database API , formerly known as “WebSimpleDB,” now affectionately known as “IndexedDB.” An early walk-through of IndexedDB is a good tutorial of how IndexedDB works, giving side-by-side comparisons of IndexedDB and Web SQL Database.