lighthouse

为什么我要逃离Hexo

可能仅仅是书写了一个特殊符号,就会导致你的hexo崩溃并且使你寸步难行

为什么我需要Hexo

静态博客是一种不错的部署博客的方式,它仅仅需要一个内容渲染器和一个仅需支持静态页面输出的web服务器即可成为一个较为完整的博客系统。相比于动态博客,静态博客拥有着维护简单、部署方便等优点。
似乎从刚开始接触web开发的时候我就开始折腾各种博客系统,wordpress、typecho、Ghost,甚至一些国产的、可以当成博客使用的CMS我都有尝试的经验,记得当初最引以为豪的事情就是成功拿免费域名+免费空间成功的给自己搭了一个wordpress博客出来。然后便是研究各种插件,每天最大的乐趣就是自己在刚刚搭建好的wordpress博客上安装各种主题和插件。
虽然博客系统装得可以说滚瓜乱熟,但是渐渐的突然发现了自己另外一个问题,总是沉迷于折腾博客系统,但是自己所折腾的博客系统中却没有几篇自己写的文章。正要写得时候,却突然发现站点存在各种问题。保存文章时超时,呈现不完美,这些问题经常困扰我,虽然到后来曾经拿质量好一点的vps来部署动态博客,但是诸如备份等问题依然时常困扰着我。
不经意的一次搜索使静态博客进入了我的视野。那种简单的部署方式可以说非常的吸引我,自己尝试装了一下hexo之后更是对其爱不释手,在vscode中编写语法优雅的markdown,然后通过简单的几行命令就可以部署到诸如Github Page或者Coding Pages这样的公共平台上,呈现效果完美,或许这真的就是我一直所需要的

但是,为什么今天我选择逃离

当初为了追求”更好、更易于专注的写作环境而选择了Hexo,而使我放弃她的,也正是因为这个理由。
第一次经历是,有一次晚上在写博客的时候,书写一段js的时候忘记了用pre包裹,结果尝试hexo server时直接报错了。当时望着那一堆nodejs的调用栈信息,我突然有一种手足无措感。后来翻看Hexo官方的troubleshooting时看到了这样一句话

Hexo 使用 Nunjucks 来解析文章(旧版本使用 Swig,两者语法类似),内容若包含 {{ }} 或 {% %} 可能导致解析错误,您可以用 raw 标签包裹来避免潜在问题发生。

我希望专注于写作,然而我还需要时刻顾及render的bug,这算什么?
第二次经历,暑假的时候本想利用闲下来的时间来给自己的博客重写一个主题,然而正当希望调试主题的时候hexo server却突然报错无法运行
我不会写nodejs,我至今还不懂为什么hexo启动的时候要加载我主题文件夹内的node_modules
然后我尝试在Github上提了一个issue,至今还没有得到一个能解决的答复。
所以说,Hexo对于我来说,主要的问题集中在以下几个方面: 1. Bug太多,经常出现莫名其妙的各种错误 2. 我平时仅仅在写gulpfile时才能用到nodejs,由于不懂nodejs,所以完全无法对整个生成器进行debug,hexo内部的错误处理机制还不禁完美,结果直接导致遇到错误之后一片茫然无法处理 3. 启动缓慢。不是很懂为什么hexo启动竟然这么慢。原来以为是机器问题,后来换了一台配置比较高的笔电,启动时仍然好几秒之后才有反映。
4. 二次开发由于不会nodejs所以非常的不方便,即便是想写一个简单的根据特定结构渲染特定结果的插件

那么,我的建议是什么

如果你是一位使用nodejs的开发者,或者纯粹是想折腾的人,那么我觉得你还是可以使用这款页面渲染工具的。但是如果你从没有接触过nodejs,特别是初入茅庐的新手,我不建议你使用Hexo作为你主要使用的博客工具。曾经和某位前辈交流关于静态博客的问题时,他曾经对我说,静态博客有的时候会比动态博客更为折腾,现在从我使用Hexo的经历来看,似乎确实是这样。另外还有一款静态页面渲染叫做Jekyll,由于没用过所以说我在这里不评价,但是Jekyll是Ruby写的,你要想清楚对于这一点你是否真的能够接受,比如日后如果需要在此基础上做一些定制是否便捷等等。
博客系统确实是一个很简单的系统,也有包括我在内的很多人通过不停的折腾博客系统来获得一些经验。但是一定要注意,博客是用来写的,大部分时间不是用来折腾的。。良好的内容才是一个博客的关键。

PS: 至于我现在的静态博客方案(wordpress + simply static)晚些时候我会攥文介绍