

We need to kill off the localStorage API - kinlan
http://paul.kinlan.me/we-need-to-kill-off-the-localstorage-api

======
IgorPartola
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 _is_ broken? Maybe IndexDB is awesome (I have no idea), but
perhaps it's not the holy grail.

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 _main_color_ = #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.

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.

~~~
daleharvey
Exactly

localStorage wasnt build as a replacement for your dataStore, its just a
convenient place to put some of your data, things like preferences, keep ui
state across pages etc, its a perfect replacement for cookies without the HTTP
overhead, turning it into a more sane localJSON api is like 10 lines of code.

I do agree that we should be making sure we move to more robust solutions that
were designed for large amounts of data and queries etc when there is a
requirement for them, but that doesnt mean localstorage is bad or evil

~~~
masklinn
> its a perfect replacement for cookies without the HTTP overhead

Or for a big global object (to reload on each arrival/page)

------
tagawa
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.

~~~
masklinn
> 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

Exactly. localStorage is not a _database_ , hence not having "database" in its
name as opposed to "Indexed Database" or "Web SQL Database". It's a persistent
key/value store, aka a big hashmap/dictionary which survives restarts.

If you need a database, it's _not_ the right tool for the job, and if you want
to store tens of megabytes of shit in the browser it's _not_ the right tool
for the job either.

If you need to store a bunch of site-wide configuration items or to cache some
basic information, it's quite good enough, and at the same time safer, easier
to use and providing far more storage space than cookies (which are the actual
alternative).

The big issue is that we _do not_ have a stable cross-browser client-side
database interface (some browsers implement IndexedDB, others implement
WebSQL), so people try to jump the gun and coerce localStorage into a DB
role... which unsurprisingly breaks.

------
mwexler
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.

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.

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.

This does remind me of the recently posted Marco Arment post,
<http://www.marco.org/2012/02/25/right-vs-pragmatic>, 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.

~~~
Groxx
I really never understood the WebSQL single-implementation problem. It doesn't
have to be - SQLite is _public domain_. Fork it. Maybe even change it so it
fits a bit more smoothly with JS. But instead we invent something new, with
new optimization problems, new usage annoyances, new inconsistencies between
browsers...?

~~~
unwiredben
Yeah, plus there's already a "single implementation" thing with HTML5, since
most of the browsers have moved to use a common parser based off Java code (in
some cases, translated automatically to C++).

~~~
batista
_since most of the browsers have moved to use a common parser based off Java
code_

err, say what?

------
lukifer
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).

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).

~~~
kinlan
I think our context of use for localStorage is at fault too, it is insanely
simple to use for small key value pairs.

~~~
lukifer
Yeah, that's exactly what it's perfect for; like cookies, but without the 4K
limit and the HTTP overhead.

------
obtu
The problem with the localStorage API is that it blocks on IO:
[https://blog.mozilla.com/tglek/2012/02/22/psa-dom-local-
stor...](https://blog.mozilla.com/tglek/2012/02/22/psa-dom-local-storage-
considered-harmful/)

~~~
huggyface
The problems listed in the linked page have little to nothing to do with
localstorage, but rather are implementation problems. Localstorage is scoped,
so if an implementation is blocked on irrelevant meebo data, the implementer
needs to fault themselves.

~~~
obtu
> Webpage completely freezes for a few seconds while the browser populates
> Local Storage key/value store.

The synchronousness means the whole DOM will block; blocking anything else
would be an implementation bug, however that is not what Taras's post
describes.

Blocking the DOM is bad. JS is designed as an evented language (the insight
that led to node.js), which means it can't accept primitives that stall its
main loop; breaking that assumption would add a lot of complexity to code that
never uses localStorage.

~~~
huggyface
_JS is designed as an evented language (the insight that led to node.js)_

It was? How do you explain alert and confirm, two of the first uses of JS? I
don't think we need to add religion to JS. Node.js is evented because that
works best for it. In my JavaScript thread if I want to wait for the
localstorage get, so be it. This is isolated to my thread, breaking nothing.

However my point was that the claim of the scope of the problem are overblown.
If a given implementation loads one massive store for localStorage, that's a
problem with the implementation, not localStorage. The linked article worst
cases on the back of a bad, lazy implementation decision.

~~~
gregory80
Dont forget document.write, or the blocking behavior of script tags
themselves.

------
dannyc
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 <http://caniuse.com/indexeddb> 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.

------
mmackh
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 (<http://wrrrite.com>)
and I don't see any real alternatives to storing the text locally.

~~~
kinlan
Nice app but I quickly got to a point where the UI became unresponsive and
digging into the CPU profiler it was all in storeValue and setItem, granted
some of it can also be the issue of reading the data from the DOM, but I the
point stands, localStorage's synchronous API causes issues.

It all depends on the app, but we seem to be using localStorage for all our
storage and bolting complex querying on to it etc and this is a huge recipe
for disaster.

------
peregrine
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...

~~~
kinlan
Granted IndexedDB is not simple, and that pains me, but the migration was very
simple with the library (that was the point).

~~~
pavel_lishin
Which library?

~~~
csears
<https://github.com/superfeedr/indexeddb-backbonejs-adapter>

------
ef4
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.

Which in Javascript always means a hefty rewrite, since there's no way to
abstract out async vs sync.

It makes me long for call-with-current-continuation.

~~~
untog
It's not Javascript proper, but take a look at tame.js. Would make switching
between sync and async very easy. Also, IcedCoffeeScript for the CS-ers.

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

~~~
kinlan
Chrome DevTools and Safari (and I am sure FF) have had tools for a long time
to see inside localStorage. It is inspection tools for IndexedDB we haven't
got.

~~~
kinlan
Actually according to [http://peter.sh/2012/02/scoped-styles-deflated-
websockets-an...](http://peter.sh/2012/02/scoped-styles-deflated-websockets-
and-the-vibration-api/) we now have IndexedDB inspection in the latest
Chromium (behind a flag).

------
jorangreef
We need an async KV store:

1\. Embedding of LevelDB or Kyoto. BitCask is terrific but has too slow a
startup time for large data sets.

2\. No range support.

3\. No IndexedDB-style gargantuan-spec and setVersion versioning complexity.
No versioning at all.

4\. Just humble powerful KV.

5\. Node-style callbacks.

6\. Get/set/unset.

7\. UTF8 keys.

8\. ArrayBuffer byte-array values only - developers can layer any slow
serialization/deserialization abstraction else on top.

9\. Unlimited storage quota when requested by the app.

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.

11\. Fast.

12\. True MVCC auto-completing read/write transactions (readers block writers
in most IDB implementations, not MVCC) or cross-tab in-memory lock api.

After that we need an async BTree api.

~~~
forgotusername
So you're basically asking for something like jQuery for IndexedDB (which
could probably be written on top in a few 10s of lines of JavaScript). Baking
a barebones API into the browser when a more powerful one has already been
implemented doesn't make sense.

Similarly for the WebSQL apologists, there's no reason <50kb of JavaScript
couldn't provide a fully featured SQL engine on top of IndexedDB - IndexedDB
implements most of the hard work (indexes, transactions, the container itself)
already.

~~~
jorangreef
"So you're basically asking for something like jQuery for IndexedDB"

No. To use your terminolgy, IndexedDB is like jQuery on top of LevelDB. We
need just LevelDB without the IndexedDB overhead. Surprisingly, there are
things you can do with LevelDB that you can't do with IndexedDB. It's too high
a level of abstraction.

------
jdefr89
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

~~~
kinlan
yes it does, it is being pushed as _the_ cross platform datastorage solution.

~~~
gregory80
Who is pushing this cross platform datastorage solution you speak of?

~~~
jorangreef
In discussion at Public Web Apps, someone from Mozilla suggested LocalStorage
as a suitable alternative to those who preferred WebSQL over IndexedDB.

~~~
rsanchez1
Figures it had to be someone at Mozilla. If I prefer WebSQL, I'll use WebSQL.

------
ajuc
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.

Why can't we have simple API AND second, async API with bells and whistles for
people who need that?

~~~
kinlan
The async api with bells and whistles is supposed to be indexedDB.

It would have been nicer to have an async mode for localStorage, but even then
I don't think it covers it. I really worry that developers are starting to try
and build serious apps on it and it just won't work..

Question: what happens if your gamestate gets over 5Mb?

~~~
ajuc
> Question: what happens if your gamestate gets over 5Mb?

I hope it won't, because I only save stuff that changes. I can compress
biggest data, if it becomes a problem, to get more space, but I don't think
I'll have to.

Anyway - it's not a problem of API, but of constraints of browser
implementations. There's nothing preventing browsers from implementing
configuration option that allows users to assign available space in
localStorage to domains.

------
rsanchez1
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.

