230

readme.md

@@ -6,7 +6,7 @@
 
 前端界的好文精读，每周更新！
 
-最新精读：<a href="./前沿技术/229.%E7%B2%BE%E8%AF%BB%E3%80%8Avue-lit%20%E6%BA%90%E7%A0%81%E3%80%8B.md">229.精读《vue-lit 源码》</a>
+最新精读：<a href="./前沿技术/230.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%AF%B9%20Markdown%20%E7%9A%84%E6%80%9D%E8%80%83%E3%80%8B.md">230.精读《对 Markdown 的思考》</a>
 
 素材来源：[周刊参考池](https://github.com/ascoders/weekly/issues/2)
 
@@ -185,7 +185,6 @@
 - <a href="./前沿技术/225.%E7%B2%BE%E8%AF%BB%E3%80%8AExcel%20JS%20API%E3%80%8B.md">225.精读《Excel JS API》</a>
 - <a href="./前沿技术/226.%E7%B2%BE%E8%AF%BB%E3%80%8A2021%20%E5%89%8D%E7%AB%AF%E6%96%B0%E7%A7%80%E5%9B%9E%E9%A1%BE%E3%80%8B.md">226.精读《2021 前端新秀回顾》</a>
 - <a href="./前沿技术/228.%E7%B2%BE%E8%AF%BB%E3%80%8Apipe%20operator%20for%20JavaScript%E3%80%8B.md">228.精读《pipe operator for JavaScript》</a>
-- <a href="./前沿技术/229.%E7%B2%BE%E8%AF%BB%E3%80%8Avue-lit%20%E6%BA%90%E7%A0%81%E3%80%8B.md">229.精读《vue-lit 源码》</a>
 
 ### 设计模式
 
@@ -241,6 +240,8 @@
 - <a href="./源码解读/155.%20%E7%B2%BE%E8%AF%BB%E3%80%8Ause-what-changed%20%E6%BA%90%E7%A0%81%E3%80%8B.md">155. 精读《use-what-changed 源码》</a>
 - <a href="./源码解读/156.%20%E7%B2%BE%E8%AF%BB%E3%80%8Areact-intersection-observer%20%E6%BA%90%E7%A0%81%E3%80%8B.md">156. 精读《react-intersection-observer 源码》</a>
 - <a href="./源码解读/227.%20%E7%B2%BE%E8%AF%BB%E3%80%8Azustand%20%E6%BA%90%E7%A0%81%E3%80%8B.md">227. 精读《zustand 源码》</a>
+- <a href="./前沿技术/229.%E7%B2%BE%E8%AF%BB%E3%80%8Avue-lit%20%E6%BA%90%E7%A0%81%E3%80%8B.md">229.精读《vue-lit 源码》</a>
+- <a href="./前沿技术/230.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%AF%B9%20Markdown%20%E7%9A%84%E6%80%9D%E8%80%83%E3%80%8B.md">230.精读《对 Markdown 的思考》</a>
 
 ### 商业思考
 

前沿技术/230.精读《对 Markdown 的思考》.md

@@ -0,0 +1,143 @@
+Markdown 即便在 2022 年也非常常用，比如这篇文章依然采用 Markdown 编写。
+
+但 Markdown 是否应该成为文本编辑领域的默认技术选型呢？答案是否定的。我找到了一篇批判无脑使用 Markdown 作为技术选型的好文 [Thoughts On Markdown](https://www.smashingmagazine.com/2022/02/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](https://fletcherpenney.net/multimarkdown/)、[commonMark](https://commonmark.org/)、[Github Flavored Markdown](https://docs.github.com/en/get-started/writing-on-github) 等等。
+
+这里随便举个例子，比如标准 MD 格式，其实第一行最后要加两个空格才能换行，但 GFM 取消了这个限制。这虽然更方便了，但暴露出平台间规范的不一致性，导致 Markdown 跨平台基本一定被坑。
+
+而各平台拓展的语法，我们是否有足够的精力学习和记忆呢？先不说能不能记得下来，首先值不值得学习就是个问题，为什么一个网络写作平台需要占用写手学习与认知成本，而不是想办法去简化写作流程呢？所以语法拓展看似很美好，但放在写手角度，或者整个互联网各平台林立的角度来看，这种非标准的做法一定不靠谱，没有用户觉得你的平台有资格 “教他语法”，除非你是微信，钉钉或者飞书。
+
+原文提到的观点是：
+
+1. 作为写手，你不知道 Markdown 哪些语法可用，哪些语法不可用。
+2. 标准规范存在一些 [模糊地带](https://johnmacfarlane.net/babelmark2/faq.html#what-is-this-for) 导致开发者实现时也会遇到各种纠结。
+
+原文还提到一个语法拓展导致理解成本增高的例子：slack 平台自定义的 [mrkdown](https://api.slack.com/reference/surfaces/formatting#basics) 就不支持 `[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](https://mdxjs.com/) 等方案，但这样的方案根本只适合程序员群体，完全无法移植。
+
+网络浏览形态也从简单的文章发展到具有整体性的应用，这些应用拥有复杂的布局、样式与交互，如果你尝试基于 Markdown 拓展语法来支持，最后可能发现还不如直接用原生 HTML。
+
+### 对结构化内容的诉求
+
+从编程角度理解就是 “组件复用”。Markdown 原生语法无法实现内容的复用，如果必须要复用内容，只能将其重复写在每一处，势必造成巨大同步成本。
+
+比如 Jekyll 就提出了 [FrontMatter](https://jekyllrb.com/docs/front-matter/) 概念用来创建复用的变量：
+
+```yml
+---
+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/](jsonSchema) 结构，这个结构甚至可以反推出一个完整的表单应用，其原因是 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](https://github.com/dt-fe/weekly/issues/397)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+