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

http://mozilla.github.io/localForage/#localforage

by AndrewDucker • 12 years ago

91 19 12 years ago

mozilla.github.io

heydenberk• 12 years ago

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.

elwell• 12 years ago

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

shadowmint2• 12 years ago

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.

masklinn• 12 years ago

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

tofumatt5• 12 years ago

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.

hliyan• 12 years ago

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.

cwmma• 12 years ago

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• 12 years ago

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

tofumatt5• 12 years ago

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

tofumatt5• 12 years ago

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.

woah• 12 years ago

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

EGreg• 12 years ago

Why not just save JSON in localStorage?

fabrice_d• 12 years ago

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• 12 years ago

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

shadowmint2• 12 years ago

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?

aristidb• 12 years ago

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• 12 years ago

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.

tofumatt5• 12 years ago

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.

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

Related Stories