博客系统的需求在哪里

半年前，有了更多对前端的思考便打算将自研博客系统落地。这个想法由来已久，从大学时期的 wordpress、dokuwiki到毕业后搭建的 hexo 静态博客，折腾了系统、捣鼓了插件，最终写的文章寥寥，后来也兴致缺缺。渐渐就期望有一个亲手建立的博客系统，删减复杂的功能，保留最精要的功能即可。

差不多花了一个月时间写出了博客主要的功能，采用了 Twitter 的页面风格，前端架构主要使用 react + mobx + antd，后端使用 flask。Feature 包括了人脸识别登陆、markdown在线编辑、moment 和博客差异化显示、支持 hashtag 等等。

闲来也写了点东西，功能确实精简也舒适，无需手动登录，允许网页使用摄像头就能开始在任何地方写作了。但慢慢发现使用起来又回到了最初的问题，似乎又懒得写作了。画图需要先画，再截图，然后上传到七牛，最后把地址丢在文章中，图片一多（人）就崩溃了，即使用了一些手段图片自动上传七牛，流程依然复杂。即使后面做下去我做到最好也就是现有博客系统的层次，对我来说依然是鸡肋的。

最近想了想，无论是 wp、hexo 还是自研博客说到底是工具不称手了，没有系统化的思考过写作到底是什么，用发布工具来当做写作平台，自然有些南橘北枳的感觉。遵循接口设计的一系列原则，我们应该将模块功能做到尽可能单一、对外暴露尽可能小，就这两点去思考之前的写作流程，便会发现我做错了，博客网站功能依然太多了，需要再进行功能的划分。

我们首先将写作一整个流程进行拆分：

• 灵感
• 腹稿
• 大纲(暂时我随性写)
• 写作
• 发布

之前的错误在于混淆了写作与发布流程，糅杂在了一起。虽然在线的富文本编辑器非常好用，方便做排版之类的工作，但是终究是功能不完善的，而且不能做到本地软件这样的方便。

考虑了半天，还是写作和发布分离吧，其中最复杂的地方可能是所见即所得，因此要求网页后台 markdown 渲染和编辑器 markdown 采用同一套渲染方案。这样再编辑器上写的东西就能保证和网页上显示的一样了。

这部分找了些资料，例如 marked、highlight、simplemde等前端 md 渲染或是富文本编辑器，似乎效果都会有出入。最终准备从 vscode 入手，发现 markdown preview exhance 的作者有在 github 开源其插件，从插件的代码中不难找到他使用的 markdown 渲染方式。

最终在其另一个开源项目『mume』中找到了解决方案，其调用非常简单，在 vscode 中的插件配置项几乎源于这一项目的配置。在做新的博客页面时直接用mume渲染即可~ 当然这样就相当于是另外做一套静态网页了。（这个想法倒是可以和原作者交流呢~ hhh）

新博客系统其实并不类似静态网页，依然会有前后端交互，只是将文章部分的渲染交给了后端的mume，前端的 marked 渲染依旧会继续使用，用于渲染出摘要。

这样的新设计，抛弃了原有的一堆功能，在新方案中，将会有四个成员来完成一整套博客系统：

• 撰写工具：vscode+mpe
• 发布工具：nodejs+mume 将和mpe 使用同一份配置，保证所见即所得
• 后端：仅用于读取数据库
• 前端：依然采用之前的展示方式，删去渲染部分

这样的方案，写作流程就会变得更简单，对于 markdown 来说比较麻烦的图床也可以通过 mpe 中的图片管理来解决。