In practice, most apps will only need Last-Writer-Wins registers and not the more complicated sequence CRDT's that you find in Y.js and Automerge.
We've built a auto-syncing database that uses CRDTs under the hood but never exposes them through the API. So if you want all of the benefits of CRDTs e.g. offline-first user experience, checkout our project, Triplit!
Yep. I figured this out the hard way. Spent a year or so investigating CRDTs before I came across Figma's blog post and realized they fit my use case exactly, and I really didn't need to bang my head against the desk for so long because the solution actually isn't so bad for tree-based editing.
Dumb question time - why didn't/don't you build Triplit on cr-sqlite? I'm guessing cr-sqlite wasn't on your radar when you started the company, but now that it exists... it would give you joins and access to the whole SQLite ecosystem.
Not a dumb question at all! We're aware of cr-sqlite and I've talked to the author, Matt, a few times. Short answer: SQLite has serious shortcomings when it comes to reactivity and we think we can be as fast as SQLite for the application-type queries we aim to support. The long answer would be about supporting all of features we don't need in SQLite and all of the quirks that come with it like having null as a primary key[1].
In practice, most apps will only need Last-Writer-Wins registers and not the more complicated sequence CRDT's that you find in Y.js and Automerge.
We've built a auto-syncing database that uses CRDTs under the hood but never exposes them through the API. So if you want all of the benefits of CRDTs e.g. offline-first user experience, checkout our project, Triplit!