Hacker News Reader

Comment by paulryanrogers | Hacker News Reader

I evaluated sqlite for a web extension but ultimately decided it wasn't worth it. There is no easy way to save the data directly to the file system. And saving the data in other ways meant I was probably better off with IndexDB instead. Still it is a tempting option and one that seems to work well for separate tenancy.

View on HN

> There is no easy way to save the data directly to the file system.

That's what absurd SQL is for (link in the parent comment).

I read that one and agree it feels absurd. Not something I want to depend on.

I believe the absurd things are: - the idea (i.e. storing a database in a database) - the fact that the resulting storage is faster than vanilla indexed db.

The repo's readme is a bit misleading and it does make it look like a mad scientist experiment but you can read more about it here (really interesting stuff): https://jlongster.com/future-sql-web

Obviously this project is still young, but I find it convincing (disclaimer: I don't use it yet).

I’m 100% sure this is (very nearly) suitable for production. It works and works well.

It is only a matter of time before browsers implement the proposed sandboxed virtual file system apis with block level access and this would be superseded.

Do you know of any oss projects using absurd? Or maybe an ORM built on top of it? It doesn't seem like there's any ecosystem built around it yet, and their example project is too trivial to be useful. I'd have to have to built even the most basic CRUD functionality from scratch.

It’s really not that much trouble. Most of the ORM like things over IndexedDB introduce extra bugs and slowness for you to deal with anyways - SQLite is millions of times easier to use than IndexedDB, so you’re getting a good deal out of considering AbsurdSQL “just” an ORM for IndexedD… as long as you don’t need to support Safari.

Yeah but you don't need to go through a web worker to use any other database product. Seems like with absurd you'd have to create a separate worker for each query and write your CRUD stuff in a potentially clunky, asynchronous style by passing messages to/from those workers. Sounds painful to me.

Reply on news.ycombinator.com