Hacker News Reader

Comment by tehbeard | Hacker News Reader

> I hope the author(s) of IndexedDB would finally understand how stupid the idea of IDB was

While not one of said authors... You mind giving me an actual rundown on issues you've got with it instead of just slinging mud?

I've used IDB in a few projects, and apart from:

- The god awful callback crap born of being pre-promises. - The lack of partial indexes (e.g. indexing a subset of documents based on some parameters) - The iOS Webkit teams continued habit adding weird, app-breaking bugs every other release to an api/system that should be stable?

It's been fairly useful. Hell, it supports storing JS types like CryptoKey or Blob/File with no real issues[1]

[1] Sans iOS WebKit, which a version or 2 back would just eat Blobs at random.

View on HN

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".

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

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

> You mind giving me an actual rundown on issues you've got with it instead of just slinging mud?

Here's a log of one developer's anguish with IndexedDB...

https://gist.github.com/pesterhazy/4de96193af89a6dd5ce682ce2...

Much of that log is just issues with one implementation, which would indicate that the Safari team is either underfunded (time/talent/money wise) or incompetent to break a working/"feature complete" system, multiple times. Not really an issue with the spec as written.

As for transactions.... Yeah I'll admit they suck hard, and can be a pain to remember the quirks of them, as well as dealing with the callbacks.

Quotas and Private mode... Those same issues would apply to webSQL, and webSQL didn't have a way to delete the database to clear it up.

Reply on news.ycombinator.com