By: Bayshore Solutions Web Development Team
Over the last few years, the World Wide Web Consortium (W3C)—the organization that maintains the standards for HTML—has been working on new specifications for the HTML language, thus dubbed HTML5. So far, many items have been added to and removed from the list of features to be included in the new version of HTML, but one topic in particular has interested me for a while, client-side storage. You may also find it called Web Storage, DOM Storage, or any other number of names, but I like client-side storage, because to me, it’s the most appropriate.
Client-side storage allows websites the ability to save, and persist, data on the client browser; and is something that developers have been eager to see for many years. Sure, the ability to store cookies to the client has been available in just about every browser since the dawn of the web, but cookies aren’t really suitable for anything but storing the most basic bits of data, are severely limited in size, are best suited for use by server-side scripts, and increase the total page size (albeit scarcely, ~4Kb), as cookies are passed back and forth in the header with each http request.
Currently, all of the leading browsers support client-side storage to one degree or another. It also comes in a couple different flavors, most notably local Storage and sessionStorage. Both are nearly identical, with the exception of their scope and persistence. Local Storage variable are available to all pages in a client, even after the browser has restarted. In contrast, sessionStorage values are only available to the original page that loaded the data, and values are lost once the browser closes. There has also been another, even more intriguing, storage option in the works, client-side database storage, which includes a SQLite database embedded in the client, and allow the usage of SQL queries. Sadly, though, it doesn’t currently look like database storage will make the HTML 5 cut. Thus, why I’m not blogging about it.
Being nearly identical in function, local storage and sessionStorage both use the same syntax when used, and the API for them is sparse; you have: getItem, setItem, and removeItem, and that’s about it. The storage objects are direct children to the document.window, so accessing them is pretty simple, although, the protocol currently only accepts string key/value pairs, so it can take some finagling to get things to work properly. Naming your objects can also be a little painful, as client-side storage doesn’t yet support objects or object notation you have to index your variables manually. I can deal with those issues for now, though, since it’s a new and much anticipated technology.