HTML5 Client-side Local Storage

From practical apps like Google Wave, Gmail (mobile), we’ve seen that minimal client caching can be a good idea for most web applications. However, faster internet fades away half of the value. But for the mobile, the growing contender of the internet, it still makes a lot of sense.

Till now, the most popular method for local storage had been limited potential HTTP cookies or Google Gears for a few. All Cookies can do is key-value pairs of strings that are stored locally in a text file of 4KB max. We definitely need a smarter solution that an industry wide standard can solve.

Out of all that comes bundled in HTML5, Client-side storage is probably one of the most talked about features: Both +ve and -ve — lot of criticism of it’s security, and +ve innovation.

Client-side storage is divided into 3 methodologies:

  1. Session storage.
  2. Local storage
  3. Database storage

Let’s get into each one of them:

1. Session Storage

Session storage is way better than what cookies have to offer. With different implementations the max limit can be something sufficient of the order of few MBs.

Unlike Cookies Session data is not sent with every request. The advantage: request payload is minimal.
So how exatly do we write it? Here goes an example:

sessionStorage.setItem('userName', 'taranfx');              // defining the session variable
alert("Your user is: " + sessionStorage.getItem('userName'));// accessing it
alert("Hello " + sessionStorage.userName);                   // another way of accessing the variable
sessionStorage.removeItem('userName');                       // finally unset it

2. Local Storage

The localStorage JavaScript object is functionally identical to the sessionStorage object. They only differ in persistence and scope. Scope: localStorage data is accessible across all browser windows while sessionStorage data is confined to the browser window that it was created in.

Global Storage is a memory space given by the browser that websites can use to store persistent data that doesn’t need to be sent to the server. The data is accessible by JavaScript/AJAX and hence by Flash. this could be really handy for Flash Games:

globalStorage[''].foo = 'bar';               // foo will be accessible by any website
globalStorage['com'].foo1 = 'bar1';          // foo1 will be accessible by websites ending in '.com'
globalStorage['taranfx.com'].foo2 = 'bar2';  // foo2 will be accessible by taranfx.com

The specification was more insecure what different browsers implemented. 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. This means strictly we will disallow XSS which is very important.

Persistence: The choice for Local Storage is obvious — the data persistence — data remains there even when the browser Window/Tab closes. Here’s how this can be done:

localStorage.setItem('userName', 'taranfx');                 // defining the localStorage variable
alert("Your user is: " + localStorage.getItem('userName'));  // accessing it
alert("Hello " + localStorage.userName);                     // another way of accessing the variable
localStorage.removeItem('userName');                         // finally unset it

3. Database Storage

Till now what we have discussed is limited to key-value pairs. But when you are dealing with a larger amount of data, database is the weapon of choice. So far, I think Safari is the only browser (correct me if wrong) to have implemented this feature. It uses SQLite database, which is light and fast with few limitations like lack of foreign key constraints.

Here is example code for accessing the local database:

var db = openDatabase("Database_Name", "Database_Version");
database.executeSql("SELECT * FROM taranfx", function(result1) {
  // do something with the resultset, there could be n no. of things
  database.executeSql("DROP TABLE taranfx", function(result2) {
    // do some more cleanup or blah
    alert("My second database query finished executing!");
   });
});

You can get a demo of this local database storage here (needs webkit nightly)Apart from the limited functionalities, it has some serious vulnerabilities Detailed in Vulnerabilities in HTML 5 and Future.

I believe, as HTML 5 finds its destiny in more and more web applications, they would become more powerful and capable. You can check our other Programming articles and Subscribe to us, discuss Technology, programming via Twitter @Taranfx - Join the dialogue.

Related:

VN:F [1.9.22_1171]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)
HTML5 Client-side Local Storage, 10.0 out of 10 based on 1 rating

Related Posts

Bookmark and Promote!

  • florin

    I guess you need to be consistent in your variable naming:

    var db = …
    database.execute…

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    • http://www.facebook.com/dannythefool Daniel Fischer

      That whole block of code there looks awfully familiar if you read the webkit blog on local database storage from 2007 ;-)

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
      VA:F [1.9.22_1171]
      Rating: 0 (from 0 votes)
  • http://joshbetz.com/ Josh

    I just saw an iPhone app the other day that is completely web-based using HTML5 for this kind of stuff. Instead of dealing with the app store approval process they challenged themselves to write an app that was equal to something they could do in a native iPhone app, but in HTML5. It turned out really nice. And the best part? They control it. Then send updates when they want without going through apple approval. And it's completely cross-platform.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    • http://www.taranfx.com Taranfx

      Yeah, this makes more sense after months of frustration of App Store approval fights

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
      VA:F [1.9.22_1171]
      Rating: 0 (from 0 votes)
  • http://google.com/profiles/SeifElIslam.Sallam Seif Sallam

    we should see CouchDB rising soon, as its RESTful API, JavaScript can access it easily.

    this can be done in 2 ways:
    1. CouchDB integrated in the browser, which can use the replication feature between the Browser and the Database Server, and JS can access it locally
    2. Remote access and Local Storage, and in this can it will pull data from CouchDB and store it locally.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  • Pingback: New Twitter Web Client

  • Niux

    thank´s, useful information

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  • Nathan Campos

    Thanks very much. Great article indeed.

    Another good reading material: http://developer.apple.com/library/safari/#documentation/iphone/conceptual/safarijsdatabaseguide/Name-ValueStorage/Name-ValueStorage.html

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
© 1162 Geeknizer. All rights reserved. XHTML / CSS Valid.
Designed by taranfx.