细谈 MarkMax 和 markdown-it 的异同

最近有点纠结，到底 MarkMax 自定义插件呢？还是 100% 支持 markdown-it 的插件？MarkMax 现在是实验性支持了 markdown-it 的部分插件，因为 MarkMax 的渲染器参数与 markdown-it 有差别，并且 MarkMax 的渲染机制与 markdown-it 同样有差别，所以对于 markdown-it 插件的支持程度需要进行源码级评估。需要注意的是，markdown-it 的插件不会支持 MarkMax 的运行时设计，这也意味着无法支持 MarkMax 的运行时性能优化和新的特性。

我深入思考之后觉得 markdown-it 的插件具有参考意义，但不意味着 MarkMax 将会 100% 支持其插件，所以开始着手设计工程级的 MarkMax 插件开发。因为 markdown-it 插件是存在设计缺陷的，具体表现在无法解决 rules 键存在冲突的问题，例如：默认类型为 text 的节点，我有多个插件修改同一个 text 的规则，就会导致渲染函数冲突，这对于任何一个插件设计机制来说都是有挑战性的。

当然，那些框架把决定权踢给了用户，比如 docsify。docsify 插件对我来说就是尤其失败的设计，我给社区开源了好几个 docsify 插件，这些插件通过 cdn 统计至少有数万的网站正在使用。也因为 docsify 失败的插件设计，导致了用户踢 issues 我还得去解释和进行适配，非常的恼火。

所以 MarkMax 插件设计除了借鉴了我自己对于 Vditor 的插件设计之外，将会针对 markdown-it 原理进行定制设计。先谈 MarkMax 究竟是如何支持 markdown-it 插件的吧，说起来其实非常简单，通过包装器进行实现的。因为 markdown-it 对于 markdown 文件 parse 之后的结果，一般都是 HTML 标签或其组成部分，所以 MarkMax 将这些渲染函数通过 MarkdownItWrapper 包装转化为 VNode，然后交给 MarkMax 的“清洗工”进行处理。理论上来说，此机制同样可以实现对于 Vditor Plugin 的支持，但是 MarkMax 已经计划移除其中所有的代码了。

MarkMax 的 Washer 其实是个非常有意思的设计，这个不光会“洗掉”不必要的节点生成，还把 markdown-it 的队列转化为了 VNode 树结构，实现详情可以参考源码，我是通过栈这一数据结构进行实现数据结构转化的。MarkMax 渲染器与 markdown-it 最大的差别在于 markdown-it 的输出是字符串，而 MarkMax 的输出是虚拟节点。MarkMax 虽然是参考 markdown-it 渲染器的重写，但因针对 VNode 映射 DOM 节点原理的不同，这也导致了有些方法的实现是有差异的。

到目前为止，说 MarkMax 是对于 markdown-it 的套壳毫不为过，但是对于新的插件设计机制和利用 vdom 而提供新的特性则与 markdown-it 差异会越来越大。MarkMax 是综合了我这么多年来对于 markdown 解析器、markdown 编辑器、markdown 渲染器、Vditor 插件和运行时设计、markdown-it、lute、marked.js 二次开发等等经验的产物，可能直到目前它的设计并不完美，但是一定会是更有特色的。

MarkMax 将会持续发挥 vdom 的特点。在首次渲染上，其渲染性能达不到基于字符串模板的方案，性能会稍微差一些（但是总体差距并不大）。但 MarkMax 将会提供 diff 的特性，降低 DOM 节点大量修改带来的性能损耗，针对于可能会引入编辑器的场景，MarkMax 将会采取更小粒度的节点修改。除此之外，MarkMax 会去实现版本比较的特性。普通的撤销和编辑虽然可以做到每一处修改历史记录的操作，但并不会主动去做到对于文字多次修改的历史版本保存。这个意义差距还是蛮大的，并且有望实现渲染器进行类似于 diff 的版本可视化修改比较。

MarkMax 是基于 markdown-it 和 million 的产物，在富文本编辑这块大概会引入 wangEditor 作为富文本编辑器进行定制开发。正如 MarkMax 在简介里所说的，MarkMax 是在 Web 端的一个新的 markdown 解决方案。市面上的 markdown 方案千千万万，此项目只是为了满足我设想高性能 markdown 方案实现的个人主义产物。

如果你对此项目感兴趣，可以提出参考意见或者参与开发，路过也欢迎给个 Star～

项目地址：https://github.com/HerbertHe/markmax