

LocalForage – An asynchronous data store with a simple, localStorage-like API - AndrewDucker
http://mozilla.github.io/localForage/#localforage

======
heydenberk
Submission and discussion from 5 months ago:
[https://news.ycombinator.com/item?id=7224225](https://news.ycombinator.com/item?id=7224225)

My question then, as now: why not standardize an API like this? Mozilla
obviously spends a great deal of time thinking about and advocating for the
future of the web, so I imagine they've thought about it.

~~~
shadowmint
To be fair, you cant just 'standardise' on something without feedback.

A polyfill for a new API implementation + feedback + people using it is
probably the right path to take towards standardising.

eg. If no one uses this much, dont bother. If lots of people do, push for it
as a standard.

------
shadowmint
I don't really get it.

IOS8 brings indexeddb to ipads; at that point it pretty much runs everywhere,
just use indexeddb.

Its a pretty decent async API which supports reasonably complex queries
(better than get-by-key like this), and has a (basic but working) node
implementation to run unit tests against. (see
[http://caniuse.com/indexeddb](http://caniuse.com/indexeddb))

Why would you use this primitive api?

Supporting older browsers is great and all, but if you dont get anything over
it except giant cookies, why bother?

~~~
aristidb
Android 4.4: 17.9% iOS 8: I don't know, but it's not released to the public,
so currently maybe 1%?

So if you want to actually reach the majority of mobile users at this point,
IndexedDB is not yet the way to go.

~~~
morsch
What percentage figures are that? I have to assume it simply relates to the
Android version installed, not to the Android browser market share. Android
has multiple browsers available; Chrome and Firefox work on Android <4.4 and
support IndexedDB per the linked page.

I have no idea how many people use "Android browser" versus Chrome; Google is
certainly pushing for higher mobile Chrome adoption. -- Okay,
[http://www.netmarketshare.com/](http://www.netmarketshare.com/) seems to
indicate that Android browser market is pretty much split two-thirds Android
browser, one-thirds Chrome. No idea how reliable their dataset is.

------
cwmma
Ugh it would have been nice if they had settled on a standard async api E.g.
Node style callbacks or promises instead of their own random one.

Edit: it would be nice if the documentation mentioned the promise support.

~~~
anotherbrick
It's not in the linked documentation, but localForage does support promises.
[https://github.com/mozilla/localForage#promises](https://github.com/mozilla/localForage#promises)

~~~
tofumatt
Thanks for pointing this out; I've filed an issue to add them:
[https://github.com/mozilla/localForage/issues/218](https://github.com/mozilla/localForage/issues/218)

------
masklinn
Has anyone played with it? Are the backends hierarchical (can you store stuff
in multiple backends)? Are they pluggable (can you add a new storage backend
e.g. to a remote system or a shared webworker)?

~~~
hliyan
Last month attempted to integrate it into a product that needed something in
between local storage and IndexedDB. All the fallbacks worked perfectly. But
the lack of an index (and therefore the inability to do bulk reads) was a
deal-breaker. I ended up going for IndexedDB with a WebSql-based polyfill.

------
EGreg
Why not just save JSON in localStorage?

~~~
fabrice_d
Because: 1) localStorage is limited to 5-10MB depending on the user agent. You
may need more! 2) localStorage only stores strings, and json stringification
and parsing is way less efficient than just dealing with objects in indexedDB.

~~~
mzarate06
Plus, local storage doesn't support async operations; it's synchronous only.

