Completely agree. Where CRDTs really shine is when you have a larger deviation of changes over time. They are brilliant for offline first type apps, and in
fact are what Apple Notes use.
Last year I experimented with combining Yjs with PouchDB/CouchDB to achieve automatic conflict handling with a multi master type architecture and eventual consistency. It worked brilliantly!
I think it’s because there is just generally so much hype around “real-time” collaborative apps at the moment. But the reality is people spend much more time working async and merging changes later. I suppose what’s particularly brilliant with CRDTs is that they handle both use cases very well, you don’t have to have two different systems.
When CRUD is done with a shared spreadsheet (Google Docs, Office 365, etc.) it's a solved problem because a spreadsheet is a total information UI. C = insert row, R = just read the screen, U = type in and other people know where your pointer is, D = delete row.
The problem is when it's done with a database and people cannot see all the information at once. So they cannot see which records other people are working on and coordination is problematic.
A traditional CRUD web app in a shared desktop is a poor man solution that works with parallelism one.
Multimaster CRUD would be the same thing accessed by different people on different computers? 3270 terminals, Windows 95 client/server applications, traditional web and SPAs. I might be wrong but the problem is always who's working on what and how to solve that. Plenty of money thrown to that: management is there also to solve that problem. Talking with colleagues is another part of the solution.
Basically anything were you want to update data locally on different devices then sync. Or any multi-database system where you want all nodes to accept writes. In these scenarios there will be conflicts.
> Why is the talk around CRDTs all about collaborative editing, and less about the more mundane...
I'm unclear how much of this is just a function of the 'talk' that we hear. For cultural reasons building frontend web-apps has bigger communication share than e.g. embedded software. Something similar might apply.
Alternatively, CRUD apps are more the domain of enterprise SW which has not traditionally been where innovative software engineering has been done.
Good point. I think this is because it's interesting how CRDT being a solution for conflict merging it's inherently capable of allowing real time applications, even when it's not exactly about that.
Because CRUD is the opposite of collaborative editing, and people are sick of it - CRDT represents a solution to getting humans working together through computers that isn't based on decades of cruft (disclaimer: imho)
Last year I experimented with combining Yjs with PouchDB/CouchDB to achieve automatic conflict handling with a multi master type architecture and eventual consistency. It worked brilliantly!
I think it’s because there is just generally so much hype around “real-time” collaborative apps at the moment. But the reality is people spend much more time working async and merging changes later. I suppose what’s particularly brilliant with CRDTs is that they handle both use cases very well, you don’t have to have two different systems.