[exelib]

You already gave a great overview of issues. But inventing something totally different from what people know without any reason doesn't make any sense. Look, YugaByteDB, CockroachDB, and some others use Postgres-compatible protocol/dialect. You can use most of standard tooling/query-builders/ORMs to speak with this databases. Why not use Redis or Cassandra protocol? Damn, leaving WebSQL as is would be much better choice. And please, don't say that "Web is different".

[tehbeard]

> But inventing something totally different from what people know without any reason doesn't make any sense.

See this argument falls apart because:

It's a key-value store... I'm fairly certain people are aware of that concept, or can grok it fairly quickly once introduced to it.

Also as to "without any reason"? It handles js data natively. You're not having to immediately throw an ORM or a bunch of custom code to marshal data into and out of the db. People build more than just todo lists. There was also some intent of it being "low level" that others could build niceties like rich query syntax etc atop.

Now, that didn't really happen much, so the debate about it being "terrible" should maybe focus there on what got missed for that goal.

[exelib]

> See this argument falls apart because

No, it isn't. While kv is easy on its own, the IDB API was never the right answer to the demand. This is exactly the reason why we (devs) are so hot about the persistent client-side storage. We want just use something like SQLite (or WebSQL, or Postgres) and forget about the IndexedDB nightmare. I'm pretty sure, we will see a huge boost around libraries and tooling when the things get more stable eventually.