I’m a big fan of localStorage, and I’ve written about localStorage on dev.opera and .net Magazine as well. So after recently reading this article on Mozilla hacks, and another where some people discussed stuff like ‘We need to kill off the localStorage API’ , I decided to put more thought into it, and see if we really need to kill off localStorage.
Before that though, lets think of fast food joints like McDonald’s, Burger King and the like. They are everywhere, aren’t they? Do they provide the healthiest food on the planet? Not really. Do a lot of people want them to not exist at all? Yeah, I know some. However, they do provide a way to satisfy your hunger for cheap, and sometimes thats all you want, despite it’s disadvantages. However, if you goto a 3 star michellen rated restaurant in Paris, you probably would not appreciate a McDonald’s burger being served to you by the chef.
localStorage is like the fast food of storage for web apps. It’s quick, simple and very easy to get the hang of. Does it have it’s disadvantages? Of course, yes, it does. If you’re building a high performance application intending to store a large and complex set of data, then maybe localStorage is not going to be the best choice for you. However, if you just want to store some basic, simple stuff in a reliable fashion without relying on cookies, then I think localStorage will work just fine.
People have argued about performance. This in itself is a bit debatable as John Allsop points out. However, even if we remove the point about performance, there are indeed a few things not optimal about localStorage. Some of them include:
Just like localStorage has its disadvantages (and it really does have its fair share, as we’ve seen), so do other methods.
WebSQL is in impasse and will probably never be available on Firefox or IE, but is available on most modern mobile browsers on smartphones like the Native Android browser, Mobile Safari and Opera Mobile. It uses SQLite, so people can use full text search, and even if people are not enitrely familar with the SQL dialiect of SQLite, they can look it up online on the docs. SQLite has some of the best documentation for an open source project. However, once again, its worth mentioning, WebSQL is in impasse.
IndexedDB does not have full browser support yet, especially on mobile…and apart from that its right now too hard for everyday developers to get to grips with. We need an abstracton library good enough for everyday developers to get to grips with and understand it easily and use. We are not anywhere near that right now, despite some interesting work by Parshuram in this area. Also, even Indexedb is not fully upto speed with a conventional DB yet, as AFAIK, it still doesnt support full text search(technically its possible, but pretty much impractical to do with non-trivial data sets. People are asking for inverted indexes to be added to the spec. However, Chrome’s implementation of IndexedDB is based on LevelDB, so it maybe possible to do it either right now or eventually), joins, roll backs (DB version revert), etc which many developers are familiar with in a relational DB model. There is also no DOM interaction currently, and even in the browsers which support IndexedDB, right now it can’t be accessed by in-built browser developer tools (Though this should eventually not be the case. Also, you do currently have this external tool from MS ).
Even if we kill off localStorage, what about sessionStorage? It certainly has its use cases, and nothing like that is possible right now in other peices of offline storage yet. As Remy pointed out in his comment on the Mozilla Hacks article, typically the amount stored in sessionStorage is generally small anyways, so the performance hits would be negligible.
However, killing off localStorage and keeping sessionStorage would just be wierd.
You shouldn’t bring a knife to a gunfight, but its better than going empty handed. Right now the current situation is such that IndexedDB is not in a state where it would get mass adoption by developers, for a variety of reasons. When it comes to simple bits of storage, I think IndexedDB is overkill anyways. Often times web apps just need to store small bits of data here and there, and web storage is perfect for that. Anything more, and you will require a proper database, and for that localStorage should not be advocated (cue, nicolas cage meme). However, most developers I talk to already know this, and don’t use localStorage to emulate a DB in the first place. They are aware of what it can do well, and also of at least the most major limitations localStorage has.
In short, localStorage has it’s problems, but it is very easy to start using it, simple to implement, reliable and you can use it now on most modern browsers, including on mobile. It should be good enough for simple storage of key/value info. If you want to store more organized data and have a way to query it and do transactions and all that jazz, wait for IndexedDB support to land in all browsers, or if you’re only and only targeting smartphones for some reason, then another option is WebSQL (at your own risk, as the spec is in impasse).
No one needs to kill off anything. We just need to bring IndexedDB to a good enough state where there is good enough browser support, where developers don’t plug their hair out trying to work with the standard, and where browser developer tools support it. To be fair, I think Christian’s article on Mozilla Hacks just wanted to state the shortcomings of the technology, but I disagree with the view that we should stop advocating it. I think we should still advocate it, its just that we should make it clear what it really is meant for, and what its not meant for and at the same time realizing that solutions for more complicated data storage have their own limitations too, and people need to be aware of those as well.
So yes, localStorage and IndexedDB both have a place in the world, both have their good and bad points, are meant for entirely different purposes, and both can co-exist peacefully.