The Hidden Costs of Yjs: When Simpler Collaborative Editing Approaches Prevail

The collaborative editing landscape has long been dominated by the narrative that CRDTs (Conflict-free Replicated Data Types) represent the pinnacle of collaborative technology, with Yjs standing as the most prominent implementation. Yet as Moment's Alex Clemmer articulates in part 2 of their series on collaborative editing myths, this widespread acceptance may be built on questionable foundations. The article presents a compelling case that Yjs, for all its sophistication, introduces unnecessary complexity and significant drawbacks that make it inappropriate for most collaborative editing use cases.

The Simpler Alternative

Clemmer begins by demonstrating a remarkably simple solution using the prosemirror-collab library that achieves what many believe requires the complexity of CRDTs. This minimalist approach, implemented in approximately 40 lines of code, provides:

• Optimistic updates during network interruptions
• Fine-grained edit provenance
• Offline editing capabilities
• Efficient reconciliation when connectivity is restored

The elegance of this solution lies in its straightforward authority-based model. Each document maintains a single source of truth, with clients submitting transactional steps alongside their last seen version. When versions mismatch, clients fetch recent changes, rebase their edits, and resubmit. This protocol, while not masterless like CRDTs, supports peer-to-peer scenarios when needed without the associated complexity.

Performance Implications of Yjs Architecture

The most damning critique concerns Yjs's fundamental approach to document updates. According to the author, Yjs completely destroys and recreates the entire document on every single keystroke—a design choice revealed in a six-year-old discussion thread that continues to impact performance today.

This approach creates cascading problems:

1. DOM Recreation: Every keystroke triggers recreation of all DOM elements, NodeViews, decorations, and widgets across the entire document
2. Plugin Breakage: Position-dependent plugins (comments, presence indicators) continuously break as their reference points shift
3. Selection Instability: Cursor positions and selections become unpredictable as the underlying document structure repeatedly changes
4. Undo Complexity: Implementing undo functionality becomes significantly more challenging

The performance consequences are severe. For an application targeting 60fps performance with a strict 16ms budget per frame, Yjs's approach creates an immediate uphill battle. Modern machines can process thousands of ProseMirror transactions per second when applied incrementally, but Yjs's document recreation strategy negates this advantage entirely.

Schema and Permission Challenges

Beyond performance, Yjs presents significant challenges in maintaining document integrity and access control.

Document schemas—those essential rules governing document structure—become problematic in Yjs's authority-less architecture. Without a central authority to validate transactions, schema mismatches can lead to silent data corruption. Clemmer recounts how invalid nodes can be permanently deleted and propagated to all peers when schema validation fails. While workarounds exist, they require careful implementation and introduce additional complexity.

Permission management follows a similar pattern. Implementing role-based access control (Editor, Viewer, Commenter, etc.) becomes awkward when working with Yjs's XML-based representation of ProseMirror documents. Rather than directly evaluating transactions for permission compliance, developers must predict the net effect of XML transformations—a process far more error-prone than direct transaction inspection.

Memory Management and Debugging Nightmares

Yjs's design for truly masterless peer-to-peer systems necessitates maintaining tombstones for deleted content—markers that record an item's deletion to ensure proper reconciliation. This creates a fundamental tension:

• Retain tombstones indefinitely to preserve data integrity, consuming memory
• Implement garbage collection with arbitrary time limits, risking data loss

The underlying YATA protocol garbage collects tombstones at approximately 30-second intervals—a compromise that makes little sense in non-masterless topologies where simpler approaches can efficiently store and retrieve edit history.

Debugging CRDT-based systems presents its own challenges. Unlike simpler approaches where bugs typically manifest as predictable synchronization failures, CRDTs converge only eventually. This makes identifying transient divergence from permanent corruption nearly impossible, turning debugging into an exercise in frustration. Standard debugging techniques—idempotency keys, duplicate request testing, race condition detection—become ineffective when the system's behavior is probabilistic rather than deterministic.

The Availability Myth

A commonly cited advantage of CRDTs is improved availability during server outages. Clemmer challenges this notion, pointing out that modern collaborative applications rely on numerous services beyond text storage:

• Media servers for embedded content
• Permission services
• Presence systems
• Durability layers (S3, K/V storage)

When any of these services fail, the application typically needs to stop serving traffic anyway. In such scenarios, using a CRDT primarily as a networking protocol rather than an availability strategy introduces unnecessary complexity with minimal benefit.

When Yjs Makes Sense

The article doesn't entirely dismiss Yjs, acknowledging its potential value in truly masterless peer-to-peer editing scenarios where no single authority can be established. However, such use cases remain rare compared to the majority of collaborative applications that can benefit from simpler, more predictable approaches.

Rethinking Collaborative Editing Design

Perhaps the most significant implication of Clemmer's critique is a call for rethinking how we design collaborative editing technologies. The current ecosystem appears to prioritize algorithmic elegance over practical user experience, resulting in tools that are needlessly complex and introduce significant performance and reliability challenges.

As the author notes, "when you design a library, you have to start with the end-user experience you want to enable, not an algorithm." For most users, this means collaborative editing that is fast, predictable, and reliable—not one that occasionally sacrifices document integrity for theoretical convergence guarantees.

The prosemirror-collab approach demonstrated in the article offers a compelling alternative, delivering the core collaborative editing functionality users need with dramatically reduced complexity. While Yjs and CRDTs may continue to dominate discussions of collaborative editing technologies, this thoughtful critique serves as an important reminder that sometimes simpler solutions better serve real-world needs.

For those interested in exploring the alternative approach mentioned in the article, the prosemirror-collab library provides the foundation for the 40-line solution. The Yjs documentation offers insight into the CRDT approach, though developers should carefully consider whether the complexity aligns with their specific requirements.