为什么我又从 Gatsby 换回 Hugo
灵车 JavaScript 谁爱用谁用，我反正受够了
阅读时间 1 分钟
我受够 JavaScript 了。我不是说 JavaScript 这语言不好，我是说普遍的 JavaScript 项目动不动就来个 breaking change。天天更新，打开 commit log 一看全是 depend bot 在刷依赖。
转到 Gatsby 这段时间文章没写多少，依赖天天更新，这我也就忍了。最让我不能接受的是各种连报错都没有的 bug 和一些他妈的优秀的插件设计思想。
在不知道哪个依赖更新后，一些 CI 构建开始失败了。浪费半天时间测试之后发现，如果项目位置位于容器挂载路径点（例如 docker 将源代码挂载到 /workspace 目录）会导致失败。这是个很他妈奇怪的 bug。我浪费半天时间反复经历 怀疑自我 - 愤怒 - 无助 几个阶段，排除了权限、文件所有者、绝对路径、npm 与 root 身份、构建缓存等等我能想到的所有情况，在晚饭都没心思吃的状态下，确定只要项目在容器挂载目录上，就会报错。
例如挂载点是 /workspace 那么项目在 /workspace 路径上就会构建失败。而在 /workspace/sub 或者是 /any/path 上都没有问题。我大概猜测出错的原因，是这帮写 JavaScript 的喜欢用绝对路径去引用文件，如此一来你可以在博客中直接引用网络上的图片甚至是电脑里其他文件夹的图片，泰裤辣 😠。
我曾经很天真地去 Gatsby 源码里找可能会出错的地方。node_modules 里有 3000 多个包，每一个包都有出错的可能，然后错误被一直携带到 Gatsby 优秀的插件系统 上，最后在 GraphQL 查询上爆出一个没人看得懂的类型错误。
说到 GraphQL 我就来气。为了在网页中插入一张图片，需要在 JavaScript 中写十几行的 GraphQL 查询语句。为了渲染一个图片列表，你需要将图片路径传给 GraphQL，但是你不能将参数传给 GraphQL，是的，你不能渲染一个图片列表，因为 GraphQL 语句是在构建时就确定的，所以它必须是静态的。官方显然意识到这个问题，于是他们在原有扭曲的 GraphQL 上增加了一种更扭曲的方法来支持传入参数。
换回 Hugo，不用每次构建等十分钟，不用带上 800M 的依赖，没有华丽花哨的 React runtime。还是平平淡淡好。
