3 ms·
It's true that a CRDT is often not the right thing for a classic client/server application. But this doesn't mean we should just give up on ux and use locking.
by aboodman 3y ago
It's true that a CRDT is often not the right thing for a classic client/server application. But this doesn't mean we should just give up on ux and use locking.
There are approaches to multiplayer that are client/server native. By leveraging the authoritative server they can offer features that CRDTs can't, while preserving the great ux.
I'm partial to server reconciliation:
https://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html https://www.gabrielgambetta.com/client-side-prediction-serve...
My product, Reflect, implements server reconciliation as a service. You can learn more about how it works here:
https://rocicorp.dev/blog/ready-player-two https://rocicorp.dev/blog/ready-player-two
- zknill 3y ago> But this doesn't mean we should just give up on ux It's a little unfair to describe locking as "[giving] up on UX", especially given some well known collaboration products use it quite successfully; Google Sheets cell locking, Miro element/Text locking, etc. Ofc, it's going to depend on the scope of what's being locked. These two examples are quite finely scoped element locks.