4 ms·

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

paulryanrogers 5y ago
I read that one and agree it feels absurd. Not something I want to depend on.
- dorian-marchal 5y ago
  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 https://jlongster.com/future-sql-web Obviously this project is still young, but I find it convincing (disclaimer: I don't use it yet).
- samwillis 5y ago
  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.
  - PopeUrbanX 5y ago
    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.
    - jitl 5y ago
      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.
      - PopeUrbanX 5y ago
        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.

paulryanrogers 5y ago

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

dorian-marchal 5y ago
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 https://jlongster.com/future-sql-web Obviously this project is still young, but I find it convincing (disclaimer: I don't use it yet).
samwillis 5y ago
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.
- PopeUrbanX 5y ago
  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.
  - jitl 5y ago
    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.
    - PopeUrbanX 5y ago
      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.