关于javascript:精读对-Markdown-的思考

Markdown 即使在 2022 年也十分罕用，比方这篇文章仍然采纳 Markdown 编写。

但 Markdown 是否应该成为文本编辑畛域的默认技术选型呢？答案是否定的。我找到了一篇批评无脑应用 Markdown 作为技术选型的好文 Thoughts On Markdown，它提到 Markdown 在标准化、结构化、组件化都存在硬伤，如果你真的想做一个现代化的文本构造编辑器，不要采纳 Markdown。

概述

Markdown 流传甚广，甚至已成为咱们的第二语言。Markdown 最早的解析器由 John Gruber 在 2004 年基于 Perl 编写公布，那时候 Markdown 只有一个目标，即为了不便网络写作。

网络写作必须基于 HTML 标准，而 HTML 标准对大部分人上手老本太高，因而 Markdown 就是基于文本创立的更易了解，或者说上手老本更低，甚至傻瓜化的一种语法，而要解析这个语法须要配套一个解析器，将这种语法文本最终转化为 HTML。

而数字化倒退到明天，Markdown 已不再适宜当下的写作场景了，次要起因有二：

1. Markdown 不再适宜当下富交互、内容状态的编写。
2. Markdown 纯文本的开发体验不再满足当代开发者日益进步的体验需要。

首先还是从 Markdown 思维开始介绍。

Markdown 的核心思想

Markdown 最大劣势就是好上手，不须要接触 HTML 这种简单的嵌套语句（尽管对程序员来说 HTML 也简略到处于鄙视链底端）。原文形象了三个劣势：

1. 基于文本的适合形象。尽管 HTML 甚至代码都是文本，但“适合”这个词很重要，即任何文本都能够是 Markdown，只有加一点点小标记就能形容业余构造，学习老本极低。
2. 有大量生态工具。比方语法解析器、高亮、格局转换、格式化、渲染等工具齐备。
3. 编辑内容便于保护。比方 Markdown 很不便作为源码存储，而其余格局的富文本可能并不不便在源码里保护。

如果把 Markdown 与数据库表构造做比拟，那数据库的了解老本真是太高了。

然而在现在后端即服务的时代，数据库拜访越来越轻松，甚至呈现大量如 AirTable 等 SAAS 产品将结构化数据疾速转化为利用，其实接触了这些后才真正发现，结构化数据对开发者有多重要。Markdown 用来写写文章还是不错的，但用来表白逻辑构造最初肯定会引发劫难结果，原文作者的团队就深受 Markdown 技术选型的困扰，被迫解决大量远超预期的难题。

如果真的要在 Markdown 的坑越走越深，就必须应用语法拓展来满足自定义诉求。

Markdown 语法拓展

最后 Markdown 语法是不反对表格的，如果想用 Markdown 绘制一张表格，只能应用原生 HTML 标签：<tabke></table>，当然，这也阐明了 Markdown 实质就是给 HTML 增强了便捷的语法，咱们齐全能够将其当 HTML 应用。

然而并不是所有创作平台都反对 <table></table> 语法的，笔者本人就常常受到困扰，比方有些平台会屏蔽原生 HTML 语法，已保障所谓的“安全性”或者内容体验的“一致性”，而这些平台为了补救缺失的绘制表格能力，往往会反对一些自定义语法，更蹩脚的是不反对，这就说到了 Markdown 的语法拓展。

Markdown 有哪些拓展呢？比方：multiMarkdown、commonMark、Github Flavored Markdown 等等。

这里轻易举个例子，比方规范 MD 格局，其实第一行最初要加两个空格能力换行，但 GFM 勾销了这个限度。这尽管更不便了，但暴露出平台间标准的不一致性，导致 Markdown 跨平台根本肯定被坑。

而各平台拓展的语法，咱们是否有足够的精力学习和记忆呢？先不说能不能记得下来，首先值不值得学习就是个问题，为什么一个网络写作平台须要占用写手学习与认知老本，而不是想方法去简化写作流程呢？所以语法拓展看似很美妙，但放在写手角度，或者整个互联网各平台林立的角度来看，这种非标准的做法肯定不靠谱，没有用户感觉你的平台有资格“教他语法”，除非你是微信，钉钉或者飞书。

原文提到的观点是：

1. 作为写手，你不晓得 Markdown 哪些语法可用，哪些语法不可用。
2. 标准规范存在一些 含糊地带 导致开发者实现时也会遇到各种纠结。

原文还提到一个语法拓展导致了解老本增高的例子：slack 平台自定义的 mrkdown 就不反对 [link](https://slack.com) 形式形容链接，而应用了 <link|https://slack.com> 语法。

总结来说，Markdown 语法拓展本应该是件坏事，但理论无规范导致了规范的百花齐放，使 Markdown 成为了实际上没有规范的状态，整体来看弊病更多。

Markdown 面向的用户群

Markdown 的对本人的定位其实很不清晰，这也导致了始终不想确定标准化语法。

最后 Markdown 是服务给相熟 HTML 的人提供的标记语言，而起初面向用户群本质上转向了开发者，因为开发者才会想到拓展语法以满足更简单的应用场景，Markdown 原生语法无奈适应越来越简单的视觉展现状态。

现在 Markdown 的次要用户曾经是开发人员与对代码感兴趣的人了，这倒不是说开发者有多喜爱它，而是在说 Markdown 的受众变窄了。现在任何一款面向非开发者群体的文档编辑器都不会采纳 Markdown 了，而是所见即所得的 WYSIWYG（what you see is what you want）模式。

这个转变的过程是苦楚的，但当初来看，富文本编辑器不利用用 Markdown 语法，而是 WYSIWYG 模式曾经是共识了。

从段落到区块、从文章到利用

简略来说，即 Markdown 曾经不适应以后 HTML 丰盛的生态了，能轻松形容段落的标记语言，遇到富裕交互的组件区块时，不得不引入例如 MDX 等计划，但这样的计划基本只适宜程序员群体，齐全无奈移植。

网络浏览状态也从简略的文章倒退到具备整体性的利用，这些利用领有简单的布局、款式与交互，如果你尝试基于 Markdown 拓展语法来反对，最初可能发现还不如间接用原生 HTML。

对结构化内容的诉求

从编程角度了解就是“组件复用”。Markdown 原生语法无奈实现内容的复用，如果必须要复用内容，只能将其反复写在每一处，势必造成微小同步老本。

比方 Jekyll 就提出了 FrontMatter 概念用来创立复用的变量：

---
food: Pizza
---

<h1>{{page.food}}</h1>

WYSIWYG 编辑器不应将 HTML 作为底层数据结构

尽管浏览器真正将 HTML 作为底层数据结构，但这并不代表所见即所得的编辑器也能够如此，这也是为什么浏览器只能提供从源码到 UI 的输入，而不能提供从 UI 编辑到源码的反向输出。

因为用户的输出与 HTML 并不是一一对应关系，其中存在大量含糊地带，比方以后光标处在粗体与细体文字两头，那下一个输出到底算加粗还是不加粗呢？从 UI 上看不到加粗标签。再有，如果 HTML 存在冗余，其实以后光标所在位置曾经被加粗标签包裹了好几层，但因为光标所在区域又被另一个款式标签笼罩成非加粗模式，当再次输出时可能就跳出了覆盖范围，从新变成了加粗，这个过程合乎用户预期吗？从技术上，这种简单标签构造也简直无奈被解决，因为组合花色切实太多。

古代大多数编辑器都以 JSON 格局存储数据结构，就因为其结构化且易于检索。

结构化最重要的体现是，其生成的 HTML 构造能够是稳固的，即对于一个既加粗又标红的文字，肯定包裹在一个 <strong style="color: red"> 标签里，而不是 <strong><div style="color: red">，也就是这种模式基本没把 HTML 作为结构化数据去对待，天然就不会呈现歧义。

Markdown 也是一样，其自身也会呈现相似 HTML 标签的二义性，不适宜作为底层数据结构存储。

精读

批评 Markdown 的文章不多见，笔者也是看了之后才恍然发现 Markdown 居然有这么多毛病。笔者联合本人的教训谈谈 Markdown 的毛病吧。

不反对富交互的无奈

Markdown 仅能反对简略的 HTML 构造，而无奈形容逻辑区块。Github 上大部分 Readme 都采纳图片来实现这些性能，包含状态卡片、构建后果、个人信息名片等，惋惜交互能力还是太弱，我感觉有朝一日 Github 应该会推出比方 Block 小区块的概念，让这些区块能够直接插入 Markdown 成为一个可交互的元素。

MDX 解决了 Markdown 的痛点吗？

看似完满兼容 JSX 与 Markdown 的 MDX 已经也是笔者写作的救命稻草，但该计划移植性是一大痛点，组件只能在本人部署的网站用，如果你想把文章公布到另一个平台，齐全不可能。

这还仅是笔者的视角，如果从 Markdown 生态来看，MDX 面向用户仅是程序员群体，基本没有解决其使命“不便网络写作”，而程序员最终也会摈弃 MDX 而转向开发所见即所得编辑器解决问题。

Markdown 到 HTML 的转换存在逻辑问题

Markdown 实质上还是一种脱离 HTML 的文本示意构造，看上去解耦很优雅，实际上会遇到不少不统一的问题。

比如说间断敲击多个空格会呈现什么状况呢？在 Markdown 会变成一个援用区块，那如何能力展现多个空格呢？谁也不晓得，可能须要查阅具体平台提供的额定语法才能够做到。

这种大体上用起来不便，但细节无奈定制，甚至用户无法控制的状况会大大挫伤曾经深度应用 Markdown 的用户，此时用户要么硬着头皮创造新语法解决这些破绽，要么就齐全放弃 Markdown 了。

结构化能力有余

看上去 Markdown 的语法挺具备结构化的，但实际上 Markdown 的结构化不具备强约束力。

拿 JSON 作比照，比方咱们能够用 JSON 拓展出 https://json-schema.org/ 构造，这个构造甚至能够反推出一个残缺的表单利用，其起因是 JSON 能够针对每一个 Key、层级下定义，首先有构造，其次才有内容。

而 Markdown 正好反过来，是先有内容，再有构造。比方咱们能够在 Markdown 任何中央写任何 HTML 标签，或者任意段落的问题，这些内容是无奈被序列化的，即使咱们依照浏览器解析 HTML 的规定解析成 JSON，也无奈从中不便的提取信息。

背地的根本原因是，Markdown 自身定位就是“近乎于 UI 渲染后果”的，而实际上浏览器渲染 UI 背地是须要一套谨严的 HTML 语法，因为 UI 与背地语法并不能一一建设映射，一个稳固的渲染逻辑只能是从源码推导到渲染，而不能从渲染反推出源码。Markdown 自身定位就近乎于渲染后果，所以结构化能力有余是人造的问题。

总结

记得语雀晚期外部试用时，编辑态还是采纳 Markdown 的，但起初很快就把 Markdown 的编辑入口下掉了，这件事还引发了不少开发者的不满，甚至还有一些 Markdown 编辑的插件被开发进去，一度很受欢迎。但慢慢的咱们都习惯用所见即所得形式编辑了，Markdown 惟一留给咱们的印象就是快捷键，比方 ### 后敲入空格能够生成 h3 题目段落，而语雀编辑器也在富交互组件区块上越走越远，要是当年被 Markdown 锁定住了技术，也不可能有明天这么高级的编辑体验。

所以技术前瞻性真的很重要，Markdown 所有程序员都爱，但提前看到它在以后互联网倒退阶段的局限性，并设计一套结构化数据代替 Markdown 构造不是所有人都能想到的，咱们须要以动静的眼光对待技术，也要放下技术人的偏见，把偏爱让位于产品定位。

探讨地址是：精读《对 Markdown 的思考》· Issue #397 · dt-fe/weekly

如果你想参加探讨，请 点击这里，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。

关注 前端精读微信公众号

<img width=200 src=”https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg”>

版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）