What’s Missing From Client Side Data Storage

Earlier this year I began looking into the various client side data storage options as a way of improving the user experience at HauteLook. I decided not to bother with web databases for now, as there is limited support for them, and because a client side database didn’t really make sense for what I as intending to do with my storage engine — namely, using it like one uses memcached server side.

For those not familiar with client side storage, there are a few options available (that have fairly wide support).

Session Storage
Session storage, as the name implies, persists for the duration of the session. However, each sessionStorage object is local to the tab or window that instantiated it.

Local Storage
Local storage is a persistent version of session storage. Data stored here stays put until you or the user explicitly removes it.

User Data
The only form of client side storage supported by IE6 and IE7, it is also supported by IE8 for backwards compatibility. By default, each user data object can hold up to 128KB of data, with a limit of 1MB per domain. Each object is only available to a page within the same document path as the object was originally created in.

The big issues

Having these options available is great when dealing with a web application that makes multiple AJAX calls to fetch data from the server. However, there are a few big things that should change if browser storage is ever going to see widespread use. (Please note: when I refer to browser storage, I am mostly referring to session storage and local storage, as user data is specific to Internet Explorer).

1. Exceptions: Currently, the Storage object specification states that setItem should throw an exception when it attempts to write and fails.
2. Expiration: There is currently no way to set an expiration time for an entry stored in local or session storage. Items stored will stay on the users computer until you manually remove them or until the user clears them.

Now, the obvious solution to number one is to wrap your code in a try/catch block, and to ensure that your application can still function if a particular bit of data cannot be found in browser storage (something it should be doing anyway!). If client side storage is ever going to see a higher rate of adoption, it needs to a little friendlier to developers. How about simply returning true or false? Or if something must be thrown, how about downgrading from an exception to a warning? Something that won’t halt execution of code. Especially considering that the “easy solution” to this issue isn’t as cut and dry as it would first seem, due to the lack of a expiration time on entries. Eventually, the 5MB of space each site gets for local storage is going to fill up. Once this happens, every new write request will fail, and if you hadn’t accounted for this, your users will start experiencing problems that you may not be able to duplicate.

For the browser storage engine interface I created at HauteLook, I got around this issue by creating a meta object that stored additional information about each key written to local storage. On every page load it reads in that meta info, checks the timestamp, and prunes any expired keys. It works, but it just feels like a kludge to me, and having native code handle all of this behind the scenes would be a very good idea. After all, browsers already do this with cookies!

The little issues

There are, of course, a few other things I wouldn’t mind seeing in future versions of the Storage spec.

1. Remaining Space: For once, Internet Explorer does something much better than other browser on the market. It implements the property remainingSpace, which simply lets the developer know how much space is still available in the local or session storage object. All other browsers implement the “try it and hope” method. This just seems really handy to me.
2. Last Accessed: Let’s say you have written an application that heavily utilizes browser storage. You need to write a fairly sizable key/value pair to the Storage object, but are currently out of room. Simply abandoning the write isn’t an option, for whatever reason. How can you determine what data is fairly safe to delete? Knowing that the key ajaxResponse1234 hasn’t been touched for five months would be a nice little hint in the right direction.

Even with the issues client side storage has, it’s a very valuable tool that can greatly speed up your web applications — especially for repeat visitors. It is, however, a complicated system that developers really need to do their homework on before jumping into the pool.