One major goal for IndexedDB was to be low-level enough that people could build the APIs they want on top of it. This type of design is popular these days due to some older standards like appcache and localstorage which have nice, simple, usable APIs but are not flexible enough to handle many real world situations.
(Now, one could argue that IndexedDB is still not low-level enough... but that's a separate problem.)
> One major goal for IndexedDB was to be low-level enough that people could build the APIs they want on top of it.
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.
It's a bit much to call IndexedDB "worthless". You can asynchronously store/access large amounts of indexed JS objects. That's a huge win, despite the fact that I agree the IndexedDB API is not ideal.
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.
Thank you Mozilla.
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.
(Now, one could argue that IndexedDB is still not low-level enough... but that's a separate problem.)