Two people type in the same paragraph at the same time. Their keystrokes cross in flight. Both editors have to end up showing exactly the same text — and neither user should see their work vanish.
There are two established ways to solve that, and the major editors have split between them. The choice is mostly invisible in a demo and quite visible in your architecture diagram, so it is worth understanding before you pick a vendor.
Operational Transformation
OT is the older approach, and the one behind Google Docs. Edits are expressed as operations — insert "x" at position 4, delete 2 characters at position 9— and when two operations are made concurrently, the system transforms one against the other so the positions still make sense after the other edit landed.
If I insert at position 4 and you delete at position 2 at the same moment, my insert has to become “at position 3” before it can be applied on your copy. That transformation function is the whole game, and it has to be correct for every pair of operation types.
- Upside: operations are small and readable, and the document state stays compact.
- Cost:correctness is genuinely hard. The transformation matrix grows with the number of operation types, and rich text has many — text, formatting, tables, embedded objects, nested lists. Most implementations require a central server to impose a total order on operations.
CKEditor 5 is the notable rich text implementation in this camp: they extended OT to tree-structured data and describe it as the product of several years of dedicated research and development. That is a fair signal of how much work the approach demands.
CRDTs
A Conflict-free Replicated Data Type takes the opposite route: instead of transforming operations to fit, design the data structure so that concurrent changes always merge to the same result, in any order.
Each character gets a globally unique identity rather than a positional index. “Insert after the character with id A7” means the same thing on every replica regardless of what else happened, so there is no position to fix up.
- Upside: convergence is a property of the data structure, not of a correct transformation function. No central authority is required to order operations, which makes offline editing and peer-to-peer topologies natural. The relay server can be dumb.
- Cost: metadata. Every character carries identity, and deletions typically leave tombstones, so documents carry more than their visible text. Modern implementations mitigate this heavily, but it is the structural trade.
Yjs is the dominant rich text CRDT in practice. Tiptap, Froala and RichTextEditor all build on it; Lexical ships an official Yjs binding.
What actually changes for you
| Question | OT | CRDT |
|---|---|---|
| Server role | Usually authoritative — orders and transforms operations | Can be a dumb relay that forwards updates |
| Offline editing | Harder — divergence must be reconciled on reconnect | Natural — merge on reconnect is the normal case |
| Document overhead | Low | Higher (identities and tombstones) |
| Self-hosting difficulty | Higher — the server contains real algorithm | Lower — standard relays are off-the-shelf |
| Ecosystem | Mostly vendor-specific implementations | Shared: Yjs providers, awareness, persistence |
The practical consequence for most buyers is the server. With OT you are usually adopting the vendor’s collaboration backend — hosted, or self-hosted on their terms and often their higher tiers. With CRDTs the sync layer is commodity: a Yjs WebSocket relay is a small, replaceable process you can run yourself.
Do not take convergence on faith — test it
Both approaches are sound in theory. What breaks in practice is the binding between the algorithm and the editor’s DOM, and that failure mode is nasty because everything looksfine: the server accepts connections, presence works, cursors move — and text silently does not merge, or the editor quietly drops to a degraded “last write wins” mode.
We have hit exactly that ourselves. A bundling mistake meant the CRDT engine and the host application each loaded their own copy of Yjs; every protocol-level test passed while real text sync was completely broken, because the two copies did not recognise each other’s types.
The lesson is a test procedure. When evaluating any collaborative editor, insist on all five:
- Two real editors, one real server. Not a protocol test, not two documents in one page without a server. Actual editor instances syncing over the wire.
- Confirm the sync mode. Ask the editor what mode it is in and assert it is the real one. Many implementations fall back silently; if there is a status API, check it says CRDT (or OT) and that the fallback reason is empty.
- Both directions. A → B and B → A. One-way sync is a surprisingly common bug.
- Interleaved edits into the same paragraph. Alternate typing between the peers with realistic gaps, then assert both documents are byte-identical and every edit survived.
- Disconnect and reconnect. Edit on both sides while one is offline, reconnect, and check convergence. This is where the theory earns its keep.
Choosing
Neither approach is universally better, and for most teams the algorithm is not the deciding factor — the operational shape is.
- If you want a vendor to run collaboration for you and offline is not a requirement, OT-backed hosted services are mature and the algorithm is somebody else’s problem.
- If you need to self-host, run air-gapped, support offline editing, or avoid per-seat collaboration pricing, CRDTs give you a commodity sync layer and far more freedom in where it runs.
RichTextEditor takes the second path: a per-node Yjs CRDT engine with a self-hosted relay, included in the licence rather than sold as a collaboration add-on. The architecture is documented in the CRDT internals guide, and there is a two-editor demo if you would rather try the test procedure above than read about it.
RichTextEditor is a perpetual-licence JavaScript editor — one purchase, self-hosted, no metered editor loads. Download the evaluation or see how it compares.