Moment.dev published a controversial blog post this month claiming Yjs—the most popular CRDT library with 18,000 GitHub stars—is overengineered for most collaborative editing needs. Their alternative? A 40-line server-authoritative approach using prosemirror-collab instead of thousands of lines of CRDT complexity. The post sparked heated debate on Hacker News (179 points, 95 comments), dividing developers between “CRDTs are the future” and “simpler solutions win.” Consequently, as collaborative editing becomes table stakes for SaaS applications, the question isn’t whether to implement real-time collaboration—it’s whether you need the algorithmic sophistication of CRDTs to do it.
The Performance Problem: Document Recreation on Every Keystroke
Yjs’s y-prosemirror binding destroys and recreates the entire document DOM on every single keystroke. Moreover, this isn’t a bug—it’s confirmed as intentional by Yjs creator Kevin. Every keystroke forces recreation of all NodeView instances, DOM elements, and decorations across the entire document. As a result, 60 fps performance becomes impossible.
Furthermore, undo/redo breaks. Cursor positioning becomes unreliable. Collaborative cursor indicators flicker. In fact, node identity disappears entirely. These aren’t edge cases—they’re fundamental user experience problems.
Meanwhile, Moment.dev’s prosemirror-collab approach handles thousands of ProseMirror transaction applications per second with fine-grained DOM updates. The difference isn’t marginal—it’s fundamental. When your architecture requires full document reconstruction for collaboration, you’ve traded user experience for algorithmic purity.
The Complexity Cost: 40 Lines vs Thousands
The prosemirror-collab library provides collaborative editing in roughly 40 lines of core code. A single authority maintains the document, applied steps, and version number. Clients submit steps with their last-seen version. On version mismatch, they fetch changes, rebase locally, and resubmit. Additionally, optional server-side rebasing simplifies this further.
In contrast, Yjs requires converting ProseMirror transactions to Yjs XML updates, reading the entire XML structure, converting back to transactions, and replacing the document. The CRDT algorithm manages tombstones, handles conflict-free merging, and maintains per-character metadata. Meanwhile, server batching in the simpler approach completes in under 16ms without blocking the main thread.
Therefore, complexity isn’t just about lines of code—it’s about conceptual overhead, debugging surface area, and performance characteristics. Simpler architectures win on all three counts.
The Peer-to-Peer Myth: Do You Actually Need It?
The main advantage of CRDTs is masterless peer-to-peer editing without a central authority. However, most applications already have servers for authentication, media storage, permissions checking, compliance logging, and audit trails. Google Docs handles millions of users with Operational Transformation and a central server, not CRDTs. In fact, one Hacker News commenter reported running 30,000 to 50,000 concurrent websockets with OT-based collaborative editing.
The peer-to-peer capability sounds sophisticated, but it’s a feature you’re paying for in complexity and performance while likely not needing it. Furthermore, when building a SaaS application, you have infrastructure. The question isn’t whether you can build collaboration without servers—it’s whether avoiding servers is worth the architectural cost. For most teams, the answer is no.
When CRDTs Actually Make Sense
Nevertheless, CRDTs aren’t universally wrong. They’re the right choice for specific use cases: local-first applications where the server is optional, offline-heavy workflows requiring extended disconnection, agentic AI systems with long-running forks and validation before merge, and truly peer-to-peer collaboration. For example, Figma successfully uses CRDTs after switching from OT. Linear uses CRDTs for local-first task management.
However, the problem isn’t that CRDTs are bad technology—it’s that developers treat them as the default choice when they’re the specialized choice. Know when to use the complex solution. Building an offline-first app? CRDTs make sense. Building a web-based SaaS tool with user authentication and cloud storage? You probably don’t need them.
Moreover, the decision matrix is straightforward: if you have servers for authentication, storage, and permissions, you already have the infrastructure for server-authoritative collaboration. Don’t add CRDT complexity unless you genuinely need its specific benefits.
The Takeaway: Question the Hype
As Moment.dev put it: “When you design a library, you have to start with the end-user experience you want to enable, not an algorithm.” Most collaborative editing requirements don’t include masterless peer-to-peer capabilities. They include responsive performance, reliable undo/redo, and straightforward debugging—all areas where simpler server-authoritative approaches excel.
Therefore, the 40-line prosemirror-collab solution handles collaboration, disconnect tolerance, and optimistic updates without CRDT complexity. Choose boring technology until you can’t. Know your actual requirements before defaulting to sophisticated algorithms. CRDTs are powerful tools for specific problems. However, make sure you have that problem before adopting that solution.
