Example: QuizCards

QuizCards is a Chrome extension that I wrote for learning a language through interactive flash cards. Once installed, the extension lives only in your browser, via an icon on the toolbar. As you answer the flash cards, the extension uses localStorage to remember which cards you answered correctly and how many times, so that it can be smart about which ones to show you next.

Here's an example of what it stores in localStorage:

Retaining Application State

Even if you are using a server to store user preferences and data, there are still some types of data that are better to store on the client, because they are actually about the client — like the current "state" of the website.  Some websites are more like static documents, and don't really have a state beyond where the users have scrolled to, but other websites (such as gmail) are more like applications, with many different sections that can be opened, closed, and moved around, all under the same URL. Users doesn't always expect application state to follow them across clients, and it can be overkill to store the data on your server. If you realize that you do need to store the data there, you can always migrate it later.

Example: EatDifferent

EatDifferent is the website I'm working on now, and it's more of an app than a document. It's a nutrition tracking tool for users to log their updates and view others updates, and features the stream of latest updates on the home screen. I use localStorage to remember which stream filter the user most recently clicked, and also to remember which UI messages the user has seen and dismissed.

Here's an example of what it stores in localStorage:

Example: jshint

JSHint is a tool for checking the quality of JavaScript code, and since JavaScript style is so variable, it includes many options for evaluating the quality. The JSHint website features an interactive tool that lets you paste in code and report problems with it, and it uses localStorage to remember your enabled options for the next time you visit.

It stores all the options as a serialized object in one key:

Remembering Form Input

You can also use localStorage to remember user-entered form input, like their login username, commonly filled options in forms (like location and phone number), and long text input that they may accidentally forget to save. It's a great use of localStorage because form input doesn't need to be remembered — but when it is, it can bring a lot of joy to the user — almost like magic. But if for some reason localStorage isn't supported or the user changes computers, they won't actively notice their form input hasn't followed them. If you decide to use localStorage to remember form input, don't just remember everything — carefully consider which parts of a form should be remembered, and for how long. There are a few libraries specially designed for remembering forms, notably autoStorage and savify.

jsperf.com

The jsperf.com website lets developers create tests to compare performance of JavaScript snippets, and it starts with a form for creating new test cases. The website uses localStorage to remember author information, since that's the same across tests, and then it uses that same author information to auto-populate the commenting form.

It stores the author information in 3 keys in localStorage:

Example: Disqus

Disqus is a popular embedded commenting system for blogs and websites [and used on Dr. Dobb's –Ed.]. It  adds a feature that uses localStorage to remember any text a user typed in a comment box but didn't post — so that when users leave a Web page and return, they'll see their draft still there, waiting to be posted. The Twitter web client also does this, and they also save an expiration for the draft, so that they don't show it after a certain point.

Disqus stores the drafts in one localStorage key, and keys it by thread name and website:

Improving performance

Websites are increasingly reliant on AJAX and API requests, and in many cases, the results of these requests can be cached so that users do not have to wait as long. The traditional way of caching server-side requests is to set cache headers on the server so the browser serves them out of its own cache, but there are times when it's better to use localStorage. First, you have more control when you can do the caching yourself — you can decide when to invalidate resources and cache requests for different amounts of time in different areas on your site. You can also decide to first load from your cache and then refresh the cache, improving the apparent loading speed for a page. If you're developing for mobile browsers, you can significantly improve your performance there by using localStorage instead of relying on their browser cache, because many mobile browsers have smaller caches and can do less HTTP requests than desktop browsers.

There are several libraries customized for caching – such as lscache, which we discussed earlier (and an lscache jQuery plugin), YQL localCache for caching YQL API results, jQuery offline for storing AJAX results, and Inject and basket.js for caching JS files.

Example: RageTube

RageTube is a website that I made for watching music videos based on online playlists. It uses a server-side XMLHR to scrape and parse the HTML playlists, and it uses the YouTube API to find the top result for each song on YouTube. I use localStorage (via my lscache library) to store the results of the playlist scraping indefinitely, and to store the API results for a few days (because video searches don't change often). When a user watches the same playlist often, the app won't have to make so many XMLHRs and API requests, making it both faster for the user and cheaper for me, the developer.

For each request, there are two keys in localStorage, one to store the actual data, and one to remember the expiration date: