Wordgard 0.1 リリース—ProseMirrorを超える新世代リッチテキストエディタの設計思想

9年の知見を詰め込んだ新たなスタート

Marijn Haverbeke 氏が Wordgard 0.1 をリリースしました。これは ProseMirror の後継にあたる新しいリッチテキストエディタシステムです。

同氏は ProseMirror を9年前に安定化させて以来、その設計に関しては誇りを持ちながらも「働くたびに改めたいと感じる部分がある」と述べています。むしろ ProseMirror を無理に進化させるのではなく、得られた知見を全て注ぎ込んで 完全に新しいシステムを一から設計するという判断に至ったということです。

Wordgard は新しい名前と新しいアーキテクチャで、ProseMirror からの教訓を全て取り入れた仕切り直しです。

このアプローチは実務的な判断だと感じます。ProseMirror 2.0 として互換性を破ったり、1.x として後方互換性を保ちながら新機能を追加したりすれば、どちらも余計な制約が生まれるからです。Haverbeke 氏は明確に、エディタアーキテクチャに関する「ニルヴァーナ」に近づくために、新しい名前で新しい実装を選びました。

変更管理フォーマットの抜本的な簡潔化

Wordgard における最大の改良点は、ドキュメント変更の表現方法です。

ProseMirror では「ステップ」と呼ばれる原子的な変更単位を採用していました。各ステップは前のステップが生成したドキュメントに対して作用し、その結果が次のステップの入力になるという設計です。複数ステップを「マッピング」して変更の意味的側面を保持しようとする取り組みでしたが、実装時には以下のような複雑さが発生しました。

• 複数ステップを適用する際の位置マッピングが複雑
• 置換範囲を特定するために前後両方向の反復処理が必要
• 開発者が直感的に理解しにくい

Wordgard は CodeMirror と ShareJS の「デルタ」フォーマットに着想を得た、より単純なアプローチを採用しています。

Wordgard では、ドキュメント内の位置を トークンベースのカウント方式で管理します。10文字のドキュメントの4文字目に「L」を挿入する場合、[keep 4] [replace 0 with "L"] [keep 6] という3つのセクションで表現されます。これは CodeMirror でも採用されている手法で、大きな利点があります。

シンプルな構造だからこそ、開発者は変更の意図を即座に把握でき、デバッグや拡張が容易になります。

さらに Wordgard は、リッチテキスト特有のニーズに対応するため 修正セクション (update sections) を追加しました。これにより、構造を保持しながら強調・リンク・画像の alt テキストといったマーク属性を追加・削除できます。3文字目から6文字目の単語を太字にする場合は、[keep 3] [update 3 +bold] [keep 4] で実現されるわけです。

JavaScript ライブラリとしての実装と CodeMirror v6 からの影響

Wordgard は ブラウザの DOM を直接利用して表示を制御する JavaScript ライブラリとして設計されています。CodeMirror v6 の再設計からも大きな影響を受けており、モダンな開発環境での使用を前提としています。

MIT ライセンスで公開されており、Forgejo サーバからソースコードを取得できます。

このアーキテクチャなら、既存の ProseMirror ユーザーが段階的に移行する際も、互換性レイヤーを自分たちで構築しやすいと考えます。エコシステムの分断を避けつつ、新しい設計の自由度を保つ—バランスの取れた判断だと感じます。

セキュリティとオープンソース体制

Wordgard がオープンソースプロジェクトとして長期維持されるには、メンテナンス負荷の管理も重要です。参考記事では Godot Engine が AI 生成コードの受け入れを制限する動きが報告されており、オープンソースコミュニティ全体で「品質を伴わない貢献」への警戒が強まっています。

Wordgard も同様の課題に直面する可能性があります。リッチテキストエディタは複雑なドメインであり、セクションベースの変更フォーマットを理解した上での貢献が求められるでしょう。設計の明確さが貢献ハードルを上げる側面もありますが、逆に「何が正しいか」を判定しやすくしてくれるとも言えます。