What's localStorage About

I've read even too many articles recently talking about storing anything you want in the localStorage ... and I believe this is wrong in so many levels.
First of all, localStorage is not a database, 'cause if you consider it a database you should have considered a database document.cookie before ...

As Simple As That

document.cookie has been there, problematic as it is, since ever.The limit of this technique has always been the 2Mb on average across different browsers.
Have you ever asked yourself what the hell is document.cookie doing and how comes it's instantly available?
Well, it's about storing some stuff in your hard disk or your browser (SQLite) database, so that every single request will send this file loads of key/values pairs through the HTTP request.
The side effect of this technique is that more you pollute cookies in your site to remember stuff, the more the interaction will be slower, specially on mobile, since all these info have to be sent to the server for each bloody request.

What's localStorage Good For

First of all don't forget localStorage does synchronous I/O which means it's blocking and the bigger it is, the slower it will be to retrieve or store data. Secondly, don't forget that if every script in your page is using it, the possibility that its rich 5Mb gonna be filled up are higher.
As summary, the moment you start storing files there you are kinda doing it wrong. You don't know how long it takes to retrieve or store data in the localStorage and the moment you feature detect this delay you have already potentially compromised your page/app visualization time.
localStorage best practice is to keep it small, as small you have kept, hopefully, until now, any document.cookie related task.
Of course if your code is the only one using localStorage, and you have things under control, you may think to use it as generic key/value paris DB but on Web, where usually more than a framework/library is in place, you can't pollute this storage as much as you like because is like polluting the global scope with any sort of crap ... and I hope we got this is bad, right?

As Less As You Can Remembering It's Public

True story bro, if you care about your code behavior don't trust, believe, use, this storage that much. Store what you think is necessary and nothing more, use proper DBs interfaces to store more, use the browser cache if you have your server under control, use the manifest if you want to make your app available off-line.
If you are thinking to speed up, without considering localStorage side-effects, the initialization of your page, storing your script once because it's too heavy ... well, the moment you both block the I/O to read that script and the moment you gonna evaluate it, you have gained zero performances boost in 90% of the cases.
Keep it small, think about other libraries, never be greedy with the localStorage, the worst case scenario is that your web page will temporarily kill your same startup time, or the stored data is more than 5Mb and we are screwed, or other libs in your page may be so greedy to erase everything that's not in their prefixed key namespace in a call

for (var key, i = localStorage.length; i--;) {
  key = localStorage.key(i);
  if (key.slice(0, 3) !== "my-") {
    localStorage.remove(key);
  }
}

Without considering the fact that a single clear() call performed from another library would destroy all the data you rely on.

Bear In Mind

document.cookie should be used as client/server channel while localStorage is client only matter. Put in cookies what the server should know, and put in localStorage what you would like to remember for the user always keeping in mind, as explained before, that its data is available for any other lib in your page.

So ... now you know ;)