[thoughtlede]

I have studied CRDTs at a deeper level for a few weeks and implemented several small prototypes. They are fascinating. As an eventual consistency model for data management, CRDT inspired techniques (op-based or state-based) are useful.

However, for building user-facing applications with CRDTs, their importance is unclear.

The question with CRDTs and local-first paradigms has always been the pressing need (or the lack thereof). The only one plausible 'need' that CRDTs serve is real-time collaboration and that too with a squinting eye.

Real-time collaboration support translates, in practice, to text-editing and picture-editing collaboration. Google docs and the ilk have solved that problem (using central solutions). A CRDT-inspired central-solution like Figma is inspiring, and maybe that's the only place CRDTs fit in their survival quest when combating against central-solutions.

The rest of the claimed advantages seem to not withstand the test of times. This articles talks about 7 features of CRDTs [1].

Fast: Things are already fast with central solutions.

Multi-device: There is multi-device support with almost all solutions (if you decouple the real-time collaboration aspect).

Offline: It's rare, at least in first world countries, to be in a need for offline access (except maybe in airplanes).

Longevity: As can be seen from another comment here, longevity is actually a problem with CRDTs because data model updates are not easy.

Privacy: With BYOK encryption pattern, privacy is not as much an issue.

User control: Even with CRDTs, user is not in control of their data - other peers can mess with your data.

[1] https://www.inkandswitch.com/local-first/

[jakelazaroff]

Author here! I think if you're just concerned with efficiency (speed/low overhead/etc) centralized solutions will always beat decentralized ones. The key advantage you can get with CRDTs — and, more generally, decentralized applications — is stability. By which I mean: Figma and Google Docs are great, but they can go out of business or delete your account or up their prices, and everything you've poured your time and energy into making just vanishes.

It's not just this way for collaboration software. Servers make everything more brittle. A few years ago, I tried to restore every website I've ever made. Static files were easy, things that relied on old versions of server-side languages were harder and anything stored on a server or in a database was just gone. That sucks. I want us to be able to keep our memories forever, not lose them because we stopped paying a hosting bill.

[thoughtlede]

Evolution of technology makes things unstable, not specifically servers. A decentralized application is not more stable than a centralized one. It depends on what's prioritized about the product. For example, you can still use SMTP servers developed several decades ago to send email to others.

Also, it is hard to buy the argument that docs based on Google Docs will live less longer than docs served by some CRDT-based collaborative application. It is easy to argue the opposite. My Google doc history shows docs I have even forgotten ever existed, and Google docs play nice with Microsoft Word - making it interoperable with the largest ecosystem around structured documents. Again, this is about product features and prioritization, not underlying building blocks.

CRDTs hold a very special place in my heart. But I also believe they don't offer a differentiated solution - on the user facing side.

[jakelazaroff]

Decentralized applications aren’t inherently more stable than applications that rely on central servers. But the ceiling is higher. Infrastructure is coupling, and coupling makes things brittle.

Yes, if everything goes right, a centralized service will probably do a better job of keeping your files around than you will. But I have way more stories where something went wrong and I lost them.

[ochiba]

I agree. We had similar conclusions around the implementation of PowerSync (sync engine enabling offline-first applications). Instead of CRDTs we went with the architecture of a central server authority and a form of server reconciliation [1] for consistency.

[1] https://www.gabrielgambetta.com/client-side-prediction-serve...