Store information on the client side with DOM Storage/Web Storage – plenty of improvements available
Saving state or values have never been easy on the web, especially on the client-side, and using cookies have been far from ideal. Enter DOM/Web Storage!
Web Storage is a W3C draft which covers exactly how saving information on the client-side should be done. It was initially part of the HTML 5 specification, but was then taken out to be independent. Web Storage, or the somewhat confusing popular name DOM Storage, is a great way to save information for the current session and window, or for returning users.
Types of storage objects
There are two types of storage objects: sessionStorage, for the current session and window, and localStorage, which will last between sessions. Here are a couple of code examples:
sessionStorage
sessionStorage["name"] = "Robert"; var theName = sessionStorage["name"];
localStorage
localStorage["occupation"] = "Web Developer"; var occupation = localStorage["occupation"];
The syntax
As you could see above, basically the syntax for working with DOM Storage is accessing values with keys, just as for any regular JavaScript object. There are also some properties and methods, available for both types of storage objects:
Properties
- constructor
- Reference to the object’s constructor.
- getItem
- Get value of item with sent in name.
- length
- Get length of the number of items
- remainingSpace
- Get remaining space for the storage object. Only seems to work in IE 8 – personally, I find this property very useful.
Methods
- clear
- Clears all items in the storage object.
- key
- Get the name of the item at a certain position.
- removeItem
- Remove item with sent in name.
- setItem
- Set item value with sent in name.
Web browser support
DOM Storage is supported in these web browsers:
- Internet Explorer 8
- Firefox 2 for
sessionStorage, 3.5 forlocalStorage - Safari 4
I find it interesting that Opera nor Google Chrome doesn’t support this yet. Also worth mentioning is that since Firefox 2, there was support for something called globalStorage. That is now obsolete, and replaced by localStorage (although it isn’t exactly the same thing).
Data saving capacity
The space available for saving data is 5 MB in Firefox and 10 MB in IE 8 (not sure about the size in Safari 4, but probably 5 MB as well). Compare that to cookies, who offers 2 to 4 kb! Imagine the possibilities!
More reading
- DOM Storage – Mozilla Developer Center
- Introduction to DOM Storage
- DOM Storage – John Resig (a little outdated, since it goes into the obsolete globalStorage object instead of localStorage)
Test cases
Naturally, in my splendid JavaScript test page, I’ve put together two simple test cases for sessionStorage and localStorage.
Progressively enhance today!
My suggestion to you is to play around with this today! Soon over half of the web browsers used on the market will support this, so it’s not only here to stay, it’s the ground some serious coding in terms of storing things. Just make sure to use progressive enhancement and have storage objects where it’s supported, and other options/fallbacks where it’s applicable.
Progressive enhance today, what you could have enhanced tomorrow! 🙂
Very neat stuff.
However, at the risk of sounding trendy, I have to say that with increased reliance on the cloud, I'm finding myself needing to rely less and less on local storage of any sort, be it 4KB or 10MB. I'm just having trouble finding reasons to be enthusiastic about the new types of HTML 5 DOM storage! 😛
If I recall correctly (and I suspect this was linked to both your IM + Tweet), that Safari 3 does also support DOM Storage.
I am sure that session storage will come in handy, and can easily imagine scenarios where that would be handy, or at least very easy to work with.
For data loaded by XHR, proper use of client side caching is your friend. The browser will store stuff for an extended period, and all regular user-agents has builtin support (even IE4 on Windows Mobile). The user-agents will even handle expired content with complete transparency. So, shiny new toys are still no replacement for thinking 😉
However, as soon as you start modifying or interpreting data, and want to persist it, browser caching won't cut it anymore, you need to resort to other means…. and this is where I see DOM Storage to come into play. With DOM Storage, we can allow the more sophisticated user agents to not repeat the expensive calculations on data, but save the results locally for lightning fast access.
mdmaph,
I think that that's one of the most common misconceptions about the cloud, though; it's not a replacement, it's a complement. Same goes for DOM Storage.
Imagine, for instance, a web site with lots of data. Storing that data on the client instead of retrieving it for each page would give a tremendous performance boost.
Remy,
From what I gained, and people testing for me, it doesn't exist in Safari 3. I think it was first included with nightly builds of Safari 3.2.1, which led to Safari 4.
Morgan,
I completely agree with everything you said. 🙂
[…] Store information on the client side with DOM Storage/Web Storage – plenty of improvements available (tags: browser html5 storage) […]
@Robert
And data that changes a lot? Or users in mobile fields that don't know what computer they might be using at any given time?
I still find it neat, but I just feel that all this increased local browser storage stuff would've been a lot more useful 10 years ago. 🙁
mdmadph,
That's still the thing! Set a time stamp on the data – if it becomes obsolete or the user is on another computer, just get it from the server again. No code should ever completely rely on DOM Storage, but I think it can be vastly improved by using it to complement things.
Just agree that it's useful, ok, dammit? 🙂
Okay, it's definitely useful. 😀
It's just late! :p
mdmadph,
Good! 🙂
And yes, I agree, we could have had this long time ago!