✳flâneur — a map of the web's best reading

You don't need CRDTs for collaborative experiences - /dev/knill

zknill.io · 1,316 words · saved by 1 readers

So maybe you are convinced that CRDTs are not the be-all-and-end-all of collaboration, and that you aren’t in one of the two categories where you probably should use a CRDT, and you’ve made it this far in the post. Now, let me explain why you don’t need CRDTs, and what you do need instead: Remind me again why this is better? Well, you get realtime collaborative experiences in a data format/structure that you own and control, without suffering any of the downsides of CRDTs. TL;DR - because it works! I’ll run through a bunch of broad categories of applications, and describe how to make use of these features. Typically lots of smaller individual inputs. You’re unlikely to want two users collaborating on the same form-box at once. How to make it collaborative: Typically lots of ‘cards’ or ’tasks’ with various properties: status, owner, title, description, project, epic, etc. How to make it collaborative: Typically a ui of rows and columns. Sometimes the records can expand to show inner-det

You don't need CRDTs You don't need CRDTs for collaborative experiences. First lets get the 'what-about-ery' out the way… Things you do need CRDTs for Offline first - this is wayy harder to get useful behaviour with out CRDTs. If you don't use them, you're pretty much destined to have LWW (which is actually a CRDT behaviour), and one user is likely to overwrite the changes of another. This isn't a great experience for anyone involved. Text editing - everyone's gonna say "but hey, google docs uses operational transform not CRDTs".. OK yes, but you are not google . Martin Kleppmann has a gr

Explore this link on the map →

related reading