LocalForage – An asynchronous data store with a simple, localStorage-like API | Hacker News Reader

LocalForage – An asynchronous data store with a simple, localStorage-like API

mozilla.github.io

91 pointsAndrewDucker19 comments

Submission and discussion from 5 months ago: 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.

It's been reposted, I suppose, in response to this submission regarding a similar 'library', Basil: https://news.ycombinator.com/item?id=8089382

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.

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)

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?

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.

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

When this was written, iOS 8 was unannounced and folks generally just used localStorage for cross-browser storage. IndexedDB isn't as high-level as some folks would like, and key-value is handy for many apps/sites.

Even with iOS 8's support for IndexedDB, there are edge cases in different browsers localForage handles, and it handles storage of Blob data and TypedArrays transparently too, which is handy.

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.

It's not in the linked documentation, but localForage does support promises. https://github.com/mozilla/localForage#promises

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

It uses Promises and callbacks, though you're right it doesn't use node-style. It's not a node library and I frankly dislike needing to supply error as a first arg, as strictly speaking it's optional and just adds cruft.

I had a few folks mention this in the early stages of library development but it hasn't come up since.

probably best to prioritize de facto standards over your own personal aesthetic preferences.

Fair enough, I've asked the contributors/users what they think and am open to making the change for 1.0: https://github.com/mozilla/localForage/issues/219

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

You could easily add your own backend relatively easily (the API is easy to copy), though it's not really "optimized" for that yet. It's designed with offline storage for JS in mind though, so the library itself likely won't support remote calls.

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.

Why not just save JSON in localStorage?

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.

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

Reply on news.ycombinator.com