hexo 真的死了吗？

# 起因

前些日子在 tg 上看到了这个文章，讲的是 lz233 因为觉得 hexo 社区不太活跃便将自己的博客转移到 Astro 上的事。

本来这也没什么，然后笔者就去搜了下 Astro 和 hexo 的区别。从上面的文章笔者觉得 Astro 应该是类似于 wordpress,hexo 这样的博客系统。

然后笔者就看到了这个文章。

讲的是北雁云依的博客又 hexo 到 vuepress 再到 Astro 这件事。

本来这也没啥，如果不看标题的话。

那么标题是什么呢？

"Hexo 的表演该落幕了，让它退场吧"

咱先不说有多少博客用的是 hexo。咱就说搜索 搭建博客 清一色推荐的是 hexo + github pages。当然也有推荐 hugo 和 typecho 的。

虽然 hexo 生成文章是挺慢的

然后仔细看文章内容，博主用了一部分的笔墨说 hexo 的架构缺陷，诸如 hexo 浪费资源，hexo 无法对前端代码进行优化什么的。然后他提到在学 vue 后这些缺陷使他忍无可忍便转到了 vuepress。

他是怎么描述 hexo 的缺陷呢？

"我不能把我的大脑当成 JavaScript 解释器，去看看全局对象被改成了什么样子；我也不能靠大脑优化 css 的内容。Hexo 能提供的方案（构建之后遍历 html，剔除未使用的 css 类名）对我来说还是不够用，而且显然增加了一个多余步骤 —— 更不用说绝大多数 Hexo 主题也没这么做。"

然后紧接着博主又花了一部分笔墨述说了 vuepress 的观点，一是生态不好，二是拖慢了首屏的加载速度。

最后博主又花了一部分笔墨说明了 Astro 的优点。

"它带来了群岛架构、TypeScript、ESM 语法、MDX 和完全自动化的按需加载。Astro 的模板系统使用了类似 jsx 的语法，能像写 jsx 一样，用 esm 的 import 语法去引入一个组件或布局，而不用担心使用了但是没有引入、引入目标不存在或引用了没被使用的东西这样的问题，因为它有完整的 TypeScript 支持。像 “漏掉一个大括号” 这样的问题则更不可能发生。"

最后博主得出了以下结论:

"现在我们可以说，除了生态不如 Hexo，Astro 就是 Hexo 的完全上位替代 —— 体积更小、功能更多、开发更便捷。只是因为刚刚出现，Astro 的生态比 VuePress2 的还差。幸好该有的东西全都有，而且很大程度上它能复用已有的现代前端技术成果（比如 tailwindcss 和我正在使用的 UnoCSS）。"

然后还呼吁 hexo 开发者 "立即停止为 Hexo 生态继续贡献代码，而是转向 Astro"。

# 个人拙见

虽然笔者不知道从 hexo 迁移到 Astro 的成本有多大，不过咱可以如法炮制地对比一下从 hexo 迁移到 hugo 的成本:

• 首先就是安装，这点 hugo 完胜。
• 其次就是迁移配置。由于 hexo 与 hugo 配置并不完全相同，可能需要一定的时间。
• 然后就是文章。由于 hexo 的文章格式和 hugo 文章的格式并不相同，需要进行大量的修改。
• 最后就是主题了。

这里就以 shoka 主题为例。

• hexo 有 hexo-theme-shkoa，虽然已停更，不过有后续的 shokax

• hugo 有 hugo-theme-shoka，但是对笔者来说体验并不好。

主要是有两点。

一是主页头图，这个可以引用 image.yml 来勉强解决，

二是评论系统，hugo-theme-shoka 虽然支持 waline 评论系统，但是笔者添加了之后并没有看到评论区。

而且该项目已归档。这意味着将没有人来修复后续的 bug。

• 至于生成网页和 push 嘛，由于笔者使用 Makefile 进行管理，所以问题不大。

而且根据博主的意思:

"自 2013 年 Hexo 发布首个版本至今，已经过去了 9 年。尽管 Hexo 仍然是一个非常优秀的静态页面生成器，它的生态和社区都很完善，文档也很详细，但它的维护和开发成本已经显著高于期望。Hexo 作为旧时代的产物，已经和 jQuery 那样到了该被抛弃的时刻。"

笔者觉得博主的意思是 hexo 是过时的。

那么什么是 “过时”？标准是什么？

• 一个事物陈旧不合事宜，超过一定的时限就算过时？那算盘和计算机比较算过时么？

• 还是说少部分存在就算过时，不符合大多数人的观念？

• 不符合社会发展算过时？那么社会发展需要的是什么？

这些暂且不提，后面博主还说 "hexo-theme-yun 开发者云游君已经在半年前转向，甚至直接自己搓了一套博客系统 valaxy。看来英雄所见略同。"

笔者没有资格批判这样的行为，但是笔者还是怀疑这样的博客系统能走多远。一是生态不好，二是现在貌似没多少人还在坚持写博客。

想起 @dboy 大佬的一句话：

“你们这些孩子哪里是真为了写博客。你们只是想体会换新工具的愉快感觉，顺便体会一下否定掉旧工具，觉得自己特别的小欣喜。”

博客是写作的工具， 搭建博客的目的，是为了更好地写博客，写的博客文章才是重点。重点不是用什么工具，内容更重要，不能本末倒置。而且，现在的博客系统又不是不能用。

如果换工具带来的愉快超过了写作带来的愉快，选择前者很正常。

# 题外话

"C++" 和 c 造轮子笔者还可以理解，因为 "c++"（和 c）中，你造的轮子是真的可以跟官方的轮子拼性能的，只要你的算法足够优秀，实现足够小心。

但是其他语言例如 js 引擎大部分都是是基于 c 和 "c++" 写的，所以几乎是不可能造出比官方库更快的轮子的。

所以为什么还是有那么多 js 轮子呢？

笔者觉得 v2ex 上的一位网友的解答很具有代表性:

"因为前端随便改，挂了最多页面丑一点，数据也不会丢。而且前端 js 一家独大，前端开发不搞出点大新闻会被遗忘"

不好意思跑题了。

书接上回，接着看博主的观点: "Hexo 作为旧时代的产物，已经和 jQuery 那样到了该被抛弃的时刻。"

根据这句话套用其他的地方上也可以得出相同的不严谨结论:

"Perl 作为旧时代的产物，已经和 Lisp 那样到了被抛弃的时刻。"

然而事实上真的是这样吗？并不是。

相反，生命力旺盛。只是大家看不到罢了。Perl 语言是最符合霍夫曼编码准则的，最常用的以最简单的形式表示，潜台词的以约定默认的方式运行。Perl 是面向程序员的，其他大多数语言是面向机器的。Perl 在文本处理方面也有它的优势，在 Lunix 系统下直接调用处理文本非常方便快捷，而且处理效率很高。

尽管 Perl 可能并不适用于应用类的开发，或者做 CGI 的 web 开发，而且编程语言相较于 Python 显得很抽象，但是作为脚本语言在数据挖掘、linux 系统管理等偏重于面向过程的文本处理分析方面仍然是十分顺手的工具，并且有很多自动化测试领域的工具都是 Perl 写的，所以显然 Perl 还活得好好的，只是逐渐淡出了为人们所熟知的 Perl CGI 开发而已。

从 github 页面的提交和 issue 反馈来看，Perl 仍然在积极的开发着。

# 总结

笔者觉得 hexo 一时半会儿还不会倒，毕竟用户基数摆在那。你看少数人用的 jekyll 不也在更新着吗

结论就是，现在是属于 hexo，未来属于谁，就看他们谁发展更好了。

Update1: "书接上回，接着看博主的观点:"Hexo 作为旧时代的产物，已经和 jQuery 那样到了该被抛弃的时刻。"" 这一部分已经更改。

原文: