Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Save Me!
One of the other things that HTML 5 adds explicitly for web applications is the addition of offline storage. One of the big problems with web applications is that they are useless when the network is down. A lot of web apps these days are really client-side apps written in JavaScript and HTML that just use the web server for saving documents. If you add the ability to store data locally, then you turn the browser into a sandboxed environment for running portable local applications, too. Whether this is a good idea is a matter of some debate.
Storing data on the client side is quite tricky. You can easily store data that persists as long as the page in JavaScript objects, and use asynchronous HTTP requests to update the page so that these objects aren't destroyed, but what happens when the user closes the window? The typical solution to this is to periodically push the content to the server and get it again later.
You can store small amounts of data in cookies, but as these are sent to the server on every HTTP request, it's not a good idea to store much in them. Typically they just store a key used to index the data on the server. If the server is offline, you can still access the cookies from local scripts, but that's not much help if they just contain a unique ID.
With HTML 5, you have a family of Storage objects. These define a simple storage interface, storing key-value pairs. The values can be any data, so this provides a lot of flexibility; large JavaScript objects can be stored, for example. Each session gets a temporary storage object, and each site gets a more permanent one.
One of the interesting things about this is that it highlights the fact that HTML 5 is moving beyond the single-page model. The session storage object has well-defined behavior when multiple scripts, associated with multiple browser windows, try to access it. You can even use it as a simple way of communicating between browser windows that are part of the same session (this was previously difficult to do with any more granularity than telling one window to load a new URL). Every time you modify a storage object, every window that has access to it receives a storage event. This gives you a very simple mechanism for inter-window communication. You can set a value for a key in the session object, and every window will then receive a notification of this change, including the old and new values.