But, this seems silly. Why are the developers creating their own new way of storing and retrieving large, structured datasets? Don't we already have a reasonably good way of doing that? One that's taught around the world?
Complaining, as they do in their doc, that SQLite doesn't implement all of SQL92 is totally silly. I think they'd be better off implementing a custom JSON <-> SQL binding CRUD package than creating a totally new object-interactive layer on top of SQLite. (Yes, from the article, they use SQLite as the underlying engine.)
To me, the arguments for this just don't make sense.
Also, priceless quote from the article: "IndexedDB does not currently have an API specified for doing a join between different object stores. As a result, the example opens a cursor to the kids object store and an object cursor on the kidId index on the candySales object store and performs the join manually."
I know I'm sniping. But, for this, we are supposed to be happy to give up SQL?
The article contained a lot of bombast about giving up on SQL and taking the opportunity to do some blue-sky thinking about creating a better API for 'structured data'.
I was hoping this meant they were going to replace SQL with a more modern relational API, correct some of the flaws in SQL while they're at it and base it truly on the relational algebra.
Turns out it's just yet another souped-up key-value store, or 'hierarchical database'. No joins, no real relational functionality to speak of. I thought we already had a client-side key-value store API?
If only people would actually read some of the theory on relational databases before eagerly reinventing a square wheel.
</old fart before his time>
The reason the SQL standard exists is not because it's the absolute best way of accessing structured data, but because a standard way of accessing structured data is useful in and of itself. It has economies of training and learning and allows for some limited amount of portability between DB engines.
In 5 years, somebody is going to invent some kind of meta-API that allows you to use a single common API to access all of cassandra, couchdb, mongodb, and the rest, and I'm just going to laugh and laugh.
I get that people want simple Key-Value and Object storage APIs because they provide nice abstractions for a particular set of use-cases, but that doesn't warrant throwing out relational databases & SQL.
It's absolutely trivial to write an reasonably-performing key-value store on top of even the most minimal subset of SQL.
The reverse is most certainly not true.