一款叫 Wordgard 的浏览器富文本编辑器库刚刚上线,官网标题只有一句话:出自"ProseMirror 的创造者"之手。这句话本身就是全篇最扎眼的信息——它没有自称"新一代编辑器",而是直接把自己和一个已经被大量产品当底层选型、用了十余年的行业基础设施绑在一起。

更值得琢磨的是代码仓库的地址:Wordgard 托管在 code.haverbeke.berlin/wordgard,而 ProseMirror 的仓库地址是 code.haverbeke.berlin/prosemirror——同一套自建代码托管系统,同一个域名。这种重合不太可能是巧合,更像是同一个人在同一块地基上,悄悄开了第二块田。

发生了什么

  • 功能.Schema 驱动的结构化编辑器,支持表格、嵌套列表、图注、协同编辑、无障碍访问和 RTL 书写方向
  • 许可.MIT 开源,和 ProseMirror 一致
  • 维护政策.明确不接受 Pull Request,商业使用者有"社会性但非法律性"的资助期待
  • 定位.官网特意强调"不是自由格式 HTML 编辑器",而是精确控制文档结构的系统——这套说法几乎是把 ProseMirror 十年来的卖点原样搬了过来
两个项目,同一套地基 Wordgard · 新发布 标题自称承袭 ProseMirror ProseMirror · 十余年基础设施 大量内容产品的底层编辑引擎 code.haverbeke.berlin 自建托管 · MIT 许可 · 拒绝 PR · 捐赠制维护

没人给答案的三件事

ProseMirror 的地位不用多说。它的 Schema 系统让开发者能精确控制文档结构,而不是放任自由格式 HTML;它的协同编辑机制被写进过大量教程和产品架构里。这套设计思路,原封不动地出现在 Wordgard 的宣传语里。

但官网没说清楚的地方也不少。Wordgard 和 ProseMirror 到底是替代关系、并行维护,还是一次实验性分支?现有基于 ProseMirror 搭建的产品,需不需要考虑迁移?"不接受 PR"这条政策在 Wordgard 上写得明明白白,但 ProseMirror 官方文档里其实找不到对应的整体声明——社区论坛里倒是有人反映过 prosemirror-tables 等个别仓库维护不够及时,这更像是精力有限的自然结果,而不是一条写死的规矩。

官方讲清楚的,和没讲清楚的 讲清楚了 没讲清楚 Schema 结构化编辑 协同编辑支持 MIT 开源许可 不接受 PR 捐赠制资助期待 与 ProseMirror 什么关系 老用户要不要迁移 维护精力怎么分配 两个项目一起养得起吗

我更在意的是维护模式,不是编辑器本身

《大学》里有句话,"苟日新,日日新,又日新"。用在开源基础设施上很贴切——一个好的系统应该不断自我更新。但地基级项目的"苟日新"从来不是没有代价的:旧房子还有人住,新房子要重新打地基,盖房子的却还是同一个工匠。

十年地基说换就换,官方却一个字没解释。

Haverbeke 一贯的路数是自建托管、拒绝外部 PR、靠捐赠维持——这套模式扛住了 ProseMirror 十年,靠的是一个人对单一项目的高度专注。现在同一套模式要同时喂养两个项目,精力会被摊薄,捐赠也未必会翻倍跟上。个别仓库维护滞后的先例已经出现过,这不是危言耸听,是这套模式本身自带的风险。

  • 风险.一人维护两套关键基础设施,历史经验是精力和资助都会被摊薄,维护缺位不是没发生过。

对已经用 ProseMirror 搭产品的团队,现在没必要恐慌迁移,但该盯两件事:ProseMirror 仓库的更新频率有没有明显放缓,以及 Haverbeke 本人会不会在论坛给出正式说明。对正在选型新项目的团队,Wordgard 可以记进观察清单,但一个刚上线、还没经过生产环境考验的库,现在下场未必是好时机。

  • 结论.与其说这是一次新品发布,不如说是十年编辑器基础设施的一次代际切换信号,只是官方还没挑明。