We need to kill off the localStorage API

Whenever someone says "We need technology X to go forward. It is our only choice." I see it as a warning. Is there really no other way forward, even if localStorage <i>is</i> broken? Maybe IndexDB is awesome (I have no idea), but perhaps it's not the holy grail.<p>One example of this is CSS. CSS is leaps and bounds better than, for example, GTK's layout and styling system. It is a huge improvement over spacer images and tables. However, it is far (far, very far) from perfect. Having umpteen different ways to position elements, inconsistent layout/display models, inconsistent implementations, no nesting and even lack of arguable features like constants (why can't I define color <i>main_color</i> = #cc0000; and use that everywhere, so I don't violate DRY principle?). It is important to recognize both the benefits and flaws of all technology we use.<p>Now, it sounds like a lot of the OT's gripe has to do with inconsistent implementations, which are always a huge pain when it comes to web development. However, as some comments suggest, it's at least possible that the spec itself is not broken. Issues like "it's slow" or "it's too small" seem like implementation details. That's like saying "JavaScript is slow" before/after Chrome came around. Right tool for the right job, etc.

Kill it off? I don't think so. Avoid using it if it's not the right tool for the job? Certainly. As a simple cross-browser key-value storage mechanism it beats cookies hands down in my experience, but obviously doesn't compare to database-style alternatives.

I too miss WebSQL. Every time I have to spend time changing my code to simulate what would be a simple SQL join, I wonder if we didn't adhere a bit too much to dogma.<p>The complaints about WebSQL being tied to a a specific library remind me of the "Linux shall really be GNU OS with a kernel and user-installed non-OSS stuff, and we're happy that non-techies will have to compile their own multimedia tools" or "Thunderbird will always put -- as a sig separator, b/c that's the way it has always been" arguments.<p>Perhaps if we make the standard we want, and let implementation rest in the hands of implementors, then we can get the KV store AND a SQL store, since they solve different problems in different ways.<p>This does remind me of the recently posted Marco Arment post, <a href="http://www.marco.org/2012/02/25/right-vs-pragmatic" rel="nofollow">http://www.marco.org/2012/02/25/right-vs-pragmatic</a>, of doing what your users want instead of what you want in some cases. Some devs really liked what WebSQL offered, or could use a good KV store... but due to purist principles, we are stuck with where we are.

The spec isn't broken; the browser implementations are broken. Even then, it's incredibly useful as is (although I haven't run into the locking issues described).<p>That said, we also need a client-side storage mechanism that supports queries, so I'm all for pushing toward IndexDB (or bringing back WebSQL).

The problem with the localStorage API is that it blocks on IO: <a href="https://blog.mozilla.com/tglek/2012/02/22/psa-dom-local-storage-considered-harmful/" rel="nofollow">https://blog.mozilla.com/tglek/2012/02/22/psa-dom-local-stor...</a>

Regardless of whether localstorage is the right tool I think people felt/feel no choice but to advocate it based on one all-important issue (saving grace?) "Browser Support". It would be nice to educate people and explain to them, don't try to use localstorage for any serious stuff, no querying, slow performance, etc. But what would you answer when they ask what's an alternative that I can use today? Based on <a href="http://caniuse.com/indexeddb" rel="nofollow">http://caniuse.com/indexeddb</a> it's not looking too good. I would suggest we continue to advocate its use, and at the same time add in a "but.. in the really near future" you should be switching. Is it great, no; But good enough for many use cases- I think so.

I can't say that I agree. For certain use cases, the localStorage API is great. For example, I have built an online Text Editor (<a href="http://wrrrite.com" rel="nofollow">http://wrrrite.com</a>) and I don't see any real alternatives to storing the text locally.

If anyone stopped and looked at his 'simple' IndexDB version of the backbone local storage you will see the issue right there. There is nothing simple about that...

One unfortunate thing about localStorage is that if you start using it, and then decide to move instead to IndexDB (or WebSQL, or the Filesystem API), you need to jump the chasm from synchronous to asynchronous.<p>Which in Javascript always means a hefty rewrite, since there's no way to abstract out async vs sync.<p>It makes me long for call-with-current-continuation.

I would like to see more tools to see what is stored inside localStorage. Right now, afaik, there is not easy way to inspect.

We need an async KV store:<p>1. Embedding of LevelDB or Kyoto. BitCask is terrific but has too slow a startup time for large data sets.<p>2. No range support.<p>3. No IndexedDB-style gargantuan-spec and setVersion versioning complexity. No versioning at all.<p>4. Just humble powerful KV.<p>5. Node-style callbacks.<p>6. Get/set/unset.<p>7. UTF8 keys.<p>8. ArrayBuffer byte-array values only - developers can layer any slow serialization/deserialization abstraction else on top.<p>9. Unlimited storage quota when requested by the app.<p>10. An option for the user to see how much storage the app is using so they can uninstall if it uses too much for their liking.<p>11. Fast.<p>12. True MVCC auto-completing read/write transactions (readers block writers in most IDB implementations, not MVCC) or cross-tab in-memory lock api.<p>After that we need an async BTree api.

localStorage ins't for heavy tasks? It is not meant to replace databases, it is more for a robust capable cookie system.. So your argument doesn't make much sense

This API is as simple, as it gets, and it's working OK for me (saving/loading game state), and I think for many other purposes also.<p>Why can't we have simple API AND second, async API with bells and whistles for people who need that?

I think the author is comparing apples and oranges. If you need large-scale data storage, then go with WebSQL or IndexedDB. If you just want to store data you normally used cookies to store, then use localStorage. This approach hasn't done me wrong yet.