写一个 Markdown 博客客户端

这个“伪需求”是最近才想到的。

关于文章管理的想法，说来话长。我最初是在 CSDN 写技术文章，就用网页上的编辑器。后来在 CppBlog 写，用上了 Windows Live Write，一般在 Word 里面写好，再贴到 WLW 发布。再后来由于太忙了，一直停到现在。其中除了我懒，有两个客观原因，第一是中间好几年不搞 C++，那么在 CppBlog 上写非 C++ 的东西好像有点奇怪；第二是，服务端的东西真的没法每天下班自己玩呀，每天下班提心吊胆地看短信报警，也没哪个心情和时间再去重新开辟一个和白天工作内容迥异的学习场景维持下去。（佩服自己找借口的能力~）

前些年，Markdown 兴起，GitHub Pages 兴起，一众静态博客工具也蓬勃发展。Markdown 真的太适合用来写技术博客了，唯一不足是图片的处理。尽管如此，我还是花了很大的精力把以前所有的文章都转成了 Markdown。然后曾经一度也玩上了 GitHub Pages，用 Huge 生成静态博客。然而，博客的这东西我认为价值点和动力还是在于交流、碰撞，自己写自己看，跟存本地没啥区别——我的 GitHub Pages 几乎没人看……那时候也没写几篇，大概是 2018 年末到 2019 年初的时间。

半年前，我想到了近年来第一个“伪需求”。我嫌 Hugo 这种形态操作太罗嗦：先写 Markdown，再放到 source repo 的 post 里，提交一把；再生成静态页面，把 public 提交到 public repo。如果折腾模版啥的，就更复杂。我就想写 Markdown，写完提交一次 .md，能不能就看到呢？甚至干脆不提交，直接同步到服务端。这样，就得做一套动态系统（相对于 Hogo 的静态页面）去做这件事，而生成被浏览的数据的逻辑理论上跟 Hugo 之类的没本质区别。而一般个人博客这种文章量，根本不用纳入性能上的考量，因此做成动态是完全可操作的。看了下市面上没有此类的工具，于是就开搞了。我把它叫“NoteIsSite”，GitHub 地址 https://github.com/Streamlet/NoteIsSite，Demo 地址 https://note-is-site.streamlet.org/，然后把我所有的文章也用这个工具挂在主页下的一个子分类，见 https://www.streamlet.org/note/。关于这个，以后再开一篇文章细说。

到这里为止，写的过程代价很小了。但是刚才说了，博客这东西，对于我的动力很大一部分来自于评论、碰撞，还是需要发到公共平台上去的好。最近看到一个去年离职的前同事的博客 https://gclxry.com/，我惊叹于人家一直在坚持写。我想我是不是也要捡起来了，还是回归 CppBlog 吧。于是问题就来了。最近觉得最好用的 Markdown 编辑器是 typora，然后它没法发博客；以前的 WLW 虽然还能用，但毕竟不基于 Markdown。然而 typora 不开源，没法给他加一个“发布”功能了事。所以自己做做看？顺便入一下 Electron 的坑，以及前端的坑。

花了这么大篇幅把需求来源说完了。至于为什么选 Electron 呢？就是为了快点搞定……

上周学习了下 Electron 的 demo 以及打包流程：https://github.com/StreamletStudy/ElectronHelloWorld

然后正式用这个 repo：https://github.com/Streamlet/MarkdownBlog
现在功能就两个：编辑、发布。编辑不是所见即所得的，左边 Markdown，右边 HTML。发布要每次填 API 地址、账号，没做管理。整个流程通了，于是停下来写了这篇文章，用刚写的工具发布上来。

发现了 Electron 的一个坑，只要在页面里调用了 alert，页面上的焦点就有问题，输入框再也无法输入内容了。目前用 remote.dialog.* 替代。不知道有没有正解？

后面的规划:

1. 搞清楚前端的语言体系，然后选择用原生 JS 还是它的衍生语言，把工程组织进一步完善
2. 搞清楚 UI 复杂度，看要不要选择一个虚拟 DOM 方案
3. 撸功能，账号管理等
4. 撸功能，做成所见即所得
5. 撸功能，支持图片粘贴、上传

再后面，先不规划，做完了再看。当前版本 Release：https://github.com/Streamlet/MarkdownBlog/releases/tag/publish_to_metaweblog_api