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