Hacker News Reader

Comment by hinkley | Hacker News Reader

I entirely missed the era where SQLite was a candidate for W3C inclusion. It was always a mental bookmark in case I found a need to have an app with any substantial offline mode, but by the time I found a perfect candidate (cataloging plants in situ), it was already deprecated, and a key-value store is no replacement for SQLite.

View on HN

Key-value store would be OK, we (developers) can handle that. And in fact, we do it already. But IndexedDB is broken by design. But I agree, handle relational data is what we want. And you can easily emulate non-relation data with it, if you need.

> Key-value store would be OK, we (developers) can handle that. And in fact, we do it already. ... But I agree, handle relational data is what we want.

You can now have both: a relational database in your key-value localStorage:

<https://sqlite.org/wasm/doc/trunk/persistence.md#kvvfs>

:-D

localStorage suffers from issues like size limits and performance (which, probably, leads to higher battery consumption).

> localStorage suffers from issues like size limits and performance

Absolutely, but _it works_ and nothing trumps working code ;). A slow and space-limited database is better than none at all!

We implemented that functionality primarily to make peoples' eyes bug out ;), but also so that folks who don't yet have OPFS can have some form of persistent sqlite databases.

The lack of guarantees about longevity put it in the realm of local cache, not buffering. If I can't count on the data to stick around then its use case is predominantly for consumption of data, not creation. We ought to pay more attention to how often we make systems whose sole purpose is for consumption.

Reply on news.ycombinator.com