關於協作編輯的謊言（第二部分）：為什麼我們不使用 Yjs

背景

本文是 Moment 開發團隊針對協作編輯技術系列文章的第二部分，主要探討為何他們在生產環境中放棄了目前最流行的 CRDT 函式庫 Yjs。作者認為 Yjs 與 CRDT 雖然在學術上具有吸引力，但在實際應用於複雜的編輯器（如 ProseMirror）時，會導致文件結構損壞、性能下降以及插件相容性等嚴重問題，並提倡回歸更簡單、基於權威伺服器的同步機制。

社群觀點

在 Hacker News 的討論中，社群對於 CRDT 的實用性展現出兩極化的評價。支持作者的一派認為，CRDT 在現階段確實被過度神化，甚至有留言者直言 CRDT 是一個不適合嚴肅應用程式的「迷因」，主張傳統的作業轉換（Operational Transformation, OT）技術早已被證明可行且更易於調試。這類觀點強調，絕大多數應用場景最終仍需要中心化伺服器來處理權限與持久化，因此為了追求極致的去中心化而引入 CRDT 的複雜度與墓碑（tombstones）記憶體開銷，往往得不償失。

然而，也有不少技術專家為 Yjs 與 CRDT 辯護。有留言指出，作者批評 Yjs 會在每次按鍵時銷毀並重建整個文件，這其實是 y-prosemirror 綁定層的設計限制，而非 Yjs 核心算法或 CRDT 本身的缺陷。支持者認為，CRDT 的真正價值在於處理非同步的長任務，例如在 AI 代理系統中，能夠隨意分叉與合併文件的能力對於非線性協作至關重要，這是傳統 OT 難以企及的優勢。此外，針對作者提出的「40 行程式碼解決方案」，有開發者補充這僅適用於最理想的狀況，現實中的本地優先系統還需處理多分頁同步、廣播頻道競爭以及離線狀態下的競態條件，其複雜度遠超簡單的伺服器回傳。

討論中還出現了關於技術誠信與利益衝突的爭論。部分用戶質疑作者作為競爭產品開發者的立場，甚至懷疑文章是由 AI 生成或存在人為操縱評論的嫌疑，但作者隨後親自澄清其開發動機是基於作為 Yjs 潛在用戶的挫折感，而非直接競爭。此外，有留言者從學術角度補刀，聲稱 Yjs 的原始論文在證明邏輯上存在循環論證。儘管爭議不斷，社群普遍達成的一項共識是：協作編輯技術不存在銀彈，開發者必須在 CRDT 的靈活性與 OT 的穩定性之間，根據具體的編輯器架構與業務需求做出權衡。

延伸閱讀

在討論串中，開發者們分享了多個值得關注的替代方案與資源。DocuKit 提供了 DocNode 與 DocSync 兩款工具，旨在簡化本地優先的同步邏輯；Val 則是一個基於 RFC 6902 JSON 補丁的本地優先內容管理系統。對於想深入了解 CRDT 未來發展的人，Joseph Gentle 的部落格文章《CRDTs are the future》被視為平衡本次討論負面觀點的重要參考。此外，ProseMirror 的作者 Marijn 針對協作機制所撰寫的原始文獻，也是理解該領域底層邏輯的必讀材料。