Hey folks, this is issue #6 of the Browsertech Digest.
Welcome to the new subscribers who found it through our CRDT post.
You might not need a CRDT
Over on the Drifting blog, I published a post called “You might not need a CRDT”.
CRDTs (conflict-free replicated data types) are one of several technical approaches to building the shared-state foundation used by real-time multiplayer apps.
The post stemmed from a mismatch between the way I often see CRDTs discussed in online developer discourse, and the stories we were hearing from developers actively building apps with multiplayer collaboration.
The prototypical story arc we hear from developers is:
-
When we set out to build multiplayer, we sat down and read a bunch of materials/papers/blog posts about CRDTs.
-
As a first pass, we built something simple, borrowing some ideas from CRDTs but not implementing a proper CRDT.
-
It turned out to be mostly fine and since we have a thousand other priorities, we kept it.
The core technical point of the post is that to keep a pair of remote data structures synchronized, you need to either make the same changes in the same order on both, or ensure that the order of the changes doesn’t matter.
CRDTs take the second path — they are essentially special versions of familiar data structure like lists and sets, carefully designed so that the order of the changes doesn’t matter.
(This is technically not quite true — a CRDT may need a weaker order guarantee called causal ordering — but that’s getting into the weeds a bit.)
CRDTs make sense when establishing an order of changes is expensive or impossible, such as in a true peer-to-peer application.
In the post, I argue that this is usually not the case for real-time collaboration, where everyone is connected to a central server and that server is free to impose a global order on changes.
In practice, we find that developers end up relying on a global order — it simplifies things and is also generally faster.
Browsertech NYC
For folks in NYC, a reminder that the next one is tomorrow! and there is still time to grab a (free) ticket.
Other stuff
Fiberplane has a good post on how they use WebAssembly to implement operational transform (another state-synchronization technology), allowing them to use the same Rust implementation on the client as on the server.
Zed also published a good post on using CRDTs for text sync. I didn’t say they’re never useful!
Apparently, the best-supported way to write a UI on Windows is to embed a web renderer.
Until next time,
Paul