为什么前端markdown没有用开源库，而是自行实现？

[ty114514]

我不理解，现有的库都很成熟，实现了markdown全部的语法支持，有的支持同步滚动有的支持所见即所得，为什么会需要自行实现一个功能不完全的解析器呢？感觉用起来很怪异

[Nicolasking007]

• 1

[boojack]

之前调研过几个 markdown parser in js 有几个缺点：

1. 无法对空行进行渲染；
2. 无法增加自定义语法：例如渲染 tag

所以就实现了一个满足了目前需求的 parser：支持渲染多行纯文本内容，支持渲染 tag，支持一些常用的 markdown 语法：粗体、代码块、todo 块等等。

目前 memos 是主推纯文本格式的内容记录，所以一些复杂的、需要额外查阅的 markdown 语法（比如 table）就没在实现范围中。

---

同时我们现在正在实现一个 golang 的 markdown parser for memos，主要是为了在 API 里返回一个 html string 或者格式化的结构体，以供其他第三方应用更加方便的渲染 memo。

[ty114514]

抱歉已读不回，之前因为感觉风格不符就没有继续关注了，最近又折腾回来

只是这两个原因嘛
我是 markdown 先入为主，不太理解为什么需要空行
易用性对于普通用户来说，高级语法在 UI 上勾选即可；专业用户应该也可以流畅盲打
tag 的话，能否从内容中抽离出来给单条帖子打标签？

感觉现状是 memos 很适合不会 markdown 的新用户入门，老用户用起来非常别扭；理解你们对于简洁的追求，但全量 markdown 未必会变得复杂，统一风格就可以兼容任何语言框架下现有的ast parser/render，不需要重复造轮子，从开发或者使用方面都是简洁的，而且 issues 里的呼声也不低

我的想法是把 memos 当做轻博客，替代纯静态生成器，所以会相对大量使用 markdown 的完整特性，感觉就差那么一点点了，希望能推动一下（）