But the real problem with offline storage is that Apple refuses to support IndexedDB, when every other browser vendor implemented it years ago (even IE!). My question is, why? I can think of three potential answers:
1. They just don't care about the web. (But in that case, why raise such a stink about not letting other web browsers run on iOS?)
2. They are incompetent. (But in that case, how have they made so much other great software? And IndexedDB isn't even very complicated. Even if it was, they could just copy Mozilla's or Google's open source implementation.)
3. It's a conspiracy to cripple HTML5 apps and encourage people to write native apps. (I don't like conspiracy theories, but it's hard to come up with a better explanation than this...)
Occam's Razor applies here.
Incidentally, I've been trying to make non-dev users care. I wrote a semi-popular HTML5 game that runs everywhere except iOS because it uses IndexedDB. When people complain that it doesn't run on iOS, I implore them to direct their complaints at Apple for not supporting IndexedDB. AFAIK nobody has even gotten a response.
Libraries like localForage are great if you're doing very simple stuff. But if you need to use slightly more advanced DB features (indexes, transactions, etc), they don't work. IndexedDB, while not a panacea, does generally work for that stuff... except for Safari :)
Given they already have a working implementation just waiting to be merged, and webSQL is both dead and their implementation horribly broken, I also cant come to any other conclusion that Apple have little interest in their devices being used for advancecd web content
Would have been nice seeing as it solves the same problems in a very similar way. I would rather have one good implementation than two buggy ones.
(Now, one could argue that IndexedDB is still not low-level enough... but that's a separate problem.)
IndexedDB is neither low or high level, it's just worthless. I'd like to be able to use HTML APIs WITHOUT a framework. At least WebSQL was usefull. One could build an IndexedDB on the top of it if one wanted,or use it directly, but you cant build WebSQL on top of IndexedDB.
Thank you Mozilla.
you cant build WebSQL on top of IndexedDB.
I don't see why you couldn't build Web SQL on top of IndexedDB. Nobody's done it and it would be a ton of work, but it should be possible.
I'd like to be able to use HTML APIs WITHOUT a framework.
You can use the IndexedDB API directly. It's not that hard. It's just overkill for something like localForage that is only doing very simple data storage and retrieval.
It wasn't just Mozilla. Microsoft deserves much of the credit/blame, since they were also in the anti-Web SQL and pro-IndexedDB camp. And Google quickly came to agree with them, even though they had implemented Web SQL previously.
Simple key-value store is quite useful in most cases, but it's not enough if you want to build really advanced applications, e.g. when you have a dataset that doesn't fit all in memory at once, but you want to filter/sort/search it (imagine GMail that stores e-mails client-side).
IndexedDB primitives are powerful enough to be an engine for a SQL database (and I presume was the idea given it's been created as the WebSQL killer).
I'm actually working on a similar project, but it instead uses the file system abstraction for storing and retrieving data. It's called BrowserFS , and it emulates the Node file system API.
I haven't written an IndexedDB or WebSQL backend yet, because I've been focusing on the architecture and other problems recently. But I'd appreciate any comments people have on it. :)
Still, it carries the normal limitation of key-value only storage in the sense that you have to keep track of your keys yourself. No queries are possible.
There's also some benchmarks here: http://jsperf.com/indexeddb-vs-localstorage/6
So, in practice you're benchmarking actual I/O vs in-memory data structure updates.