2011 年创建这个博客时，我用的是 Jekyll。十五年来 Jekyll 一直表现不错。速度够用，虽然每次换电脑重装环境都要花上一两个小时，但总体来说基本没出过什么问题。不过去年年底，我在把本地所有环境都升级到运行时最新版本时，尝试把 Jekyll 升级到 Ruby 4，却怎么也装不上。Jekyll 项目最终在二月合并了对 Ruby 4 的支持（其实只改了一行代码），但这件事让我觉得，是时候换了。

我大概还能再用 Jekyll 撑几年，但不可否认，这个项目已经慢了下来，而我为这个博客搭建的优化方案也变得越来越复杂——如果能换一个更注重优化的工具，简化一下工具链，那就再好不过了。

于是，我换成了 11ty。或者说，用它即将启用的新名字——Build Awesome。我在那场风波之前就已经完成了切换，并开始写这篇博客，关于这次更名我确实有些想法，不过那不是本文的重点。

为什么 macwright.com 选择了 Eleventy？

在这个领域，真正占据主导地位的是 Astro，而不是 Eleventy。市面上还有很多其他静态网站生成器，比如用 Haskell 写的 hakyll，或用 Rust 写的 dodeca。像许多人一样，我自己也可以动手写一个。

对于这个网站，我没有其他利益相关方需要考虑。不用让别人上手新技术，也不用靠技术选型去打动谁。这个网站只有几个简单的优先级：

1. 简洁
2. 持久
3. 速度

我同时看重内部和外部的简洁——既包括 API 的简洁，也包括实现的简洁。因为我默认任何工具迟早都会出问题，我希望出问题时能自己打开代码找到原因。这一点也很关键，因为复杂的项目维护难度会成倍增加，如果不能占据主导地位，往往也就难以长久。

持久性很难预测。林迪效应是一个不错的捷径：

像技术或观念这类不易消亡的事物，其未来的预期寿命与其已存在的时间成正比

但在科技领域，最新的方案也可能就是最好的方案，所以还是得做一些预判。贡献者基数大也能说明一些问题，但前提是这些贡献者来自多个不同的主体。如果一个项目的贡献者大多来自同一家公司，一旦公司裁员，项目很快就会沉寂。如果项目经历过多次主导权和控制权的更迭而依然存活，也很能说明问题。

对于这个网站，我更在意面向最终用户的速度，而不是开发时的速度。对我来说，预览 Markdown 改动是花 100 毫秒还是更久并不重要，重要的是读者打开页面需要多久。反正只要不做蠢事，大多数静态网站生成器的速度都很快。以我的经验，那些“构建很慢”的静态网站生成器，往往是卡在了嵌套循环上，时间都耗在了那里。

Eleventy 在这些方面基本都符合要求。它的贡献者群体确实很小，但 Zach 非常坚韧，经历过大风大浪。它不仅构建网站的速度很快，还提供了大量网站优化工具——这些工具让我得以替换掉之前为 macwright.com 写的不少自定义代码。而且，与 Astro 形成鲜明对比的是，它把内部简洁作为优先原则。无论是代码行数还是依赖规模，它都是一个小而精的项目，也不依赖那些巨型依赖。全新安装的 Astro 会包含246 个依赖，其中包括 Vite 和 esbuild；而 Eleventy 只有大约一半——116 个依赖，体积也只有 14.6MB，而 Astro 则高达 87.9MB。

我觉得 Eleventy 还可以更简洁一些（写这篇文章期间我就顺手提了一个朝这个方向的小 PR），比如砍掉一些陈旧的、带着不必要微型依赖的包。e18e 项目致力于移除和精简依赖，真的非常有必要！

靠静态网站生成器谋生很难

当然，还有那个消息：Eleventy 现在要叫 Build Awesome 了。这之前已经有不少项目的类似动向：

• Cloudflare 收购了 Astro
• Netlify 收购了 Gatsby
• Shopify 收购了 Remix
• Vercel 收购了 Nuxt
• Sanity 收购了 Begin

因为这些都是开源项目，所谓的“收购”其实要打个星号：通常只是把团队招了过去，顺便拿到商标，以及接手已有的业务线。

Zach 因为这个决定受到了一些指责。我也认同，“Build Awesome”听起来有点千禧一代的味道，Eleventy 原本的名字要酷得多。这次更名确实有点奇怪。

但总体来说，我能理解。你不可能一边慢慢释放重大的战略和产品发布信息，一边征求所有人的意见。Eleventy 和 Web Awesome 旗下的其他产品——图标、Web Components、静态网站构建器——其实契合度挺高。它们都是优秀的 Web 工具，更偏向传统主义，而不是前端极繁主义那一路。

正如我们所看到的，底层工具想实现商业化也异常困难，很大程度上是因为每个开发者都随时准备以任何理由、甚至毫无理由地自己动手写一个静态网站生成器，仅仅因为听起来像个有趣的 side project。更高层的内容工具倒是可以实现商业化——Kirby、Sanity 以及其他几款带 CMS 功能的网站生成器已经做到了，并建立起了小而可持续的业务。但像 Eleventy 这样形态的工具，很难作为一个小型产品生意运转起来，至少也得靠做服务才行。

所以，可能的出路大致有几种：

1. 被某家大型、甚至可能是上市公司收购，以此来壮大其托管/CDN 产品的平台。这是 Astro、Nuxt、Gatsby、Remix，乃至在某种程度上 Begin 的命运。Jekyll 从一开始就是如此：它由 GitHub 的 Tom Preston-Werner 创建，正是它为 GitHub Pages 的成功提供了助推燃料。
2. 维护者从未全职投入，靠一份轻松的日常工作或其他间接方式赚钱。这种模式我很大程度上将其与生活在高福利、医疗可负担国家的好处联系在一起。我非常感激这种模式能孕育出如此多长期、高质量的软件，但也无法足够强调，在美国每个月都要自己在医保交易平台上购买医疗保险是多么糟糕的体验。
3. 围绕这个工具直接建立一家公司。Remix 早期就尝试过，靠卖许可证盈利；Astro 也尝试推出过一些产品。Eleventy 正在尝试这条路，同时还会推出 CMS 和其他一些功能。

这都不容易：如果你生活在美国、还要养家，第二条路很难实现；而第一条路或许是一种“难得糊涂”的解法，因为如果开源只是作为引流的亏本买卖，它本身是不可持续的。

使用 Eleventy 至今

话说回来，我从一月开始用 Eleventy，体验如何呢？

总体不错！一些亮点包括：用 Image 插件把图片优化得比以前更彻底，以及用一个小小的优化插件直接在构建流程中完成 HTML 压缩。网站构建比以前稍快了一些，通过使用 Eleventy 功能强大但有点让人困惑的目录数据文件，我得以简化每篇博文，用目录来区分分类，而不是靠 frontmatter。

模板用起来很有趣：使用 Vento 模板总体体验很好，因为它允许我在模板里直接写任意 JavaScript。而且不像 Liquid 那样会静默失败。

WebC 对我来说是快乐与痛苦并存。一方面，它绝对是个黄金工具：可以在页面中嵌入组件，支持服务端渲染、自动打包，性能还非常出色。而且它很简洁！包体积很小，因为它没有引入像 esbuild 那样庞大的 JavaScript 转译器。最近我在《In the Atmosphere》一文中的图表和《Color dithering》一文中的演示里都用了 WebC。

但痛苦也确实存在。这是个非常独特的工具，有很多限制，一旦哪里搞错就会彻底报错。文档只是对其潜力蜻蜓点水，留下了大量未解的问题。我觉得它潜力巨大，现在已经相当不错，但还需要投入更多精力打磨，正如 Zach 在最近一次分享中承认的那样。

对于 WebC 和 Eleventy，我对其不采用 TypeScript 的决定心情复杂。WebC 曾有一个 bug，用 TypeScript 甚至只用一个 linter 就能轻易发现。我觉得这些项目的工具链本可以好得多。

不过抱怨没什么意义：我一直在尝试为这些项目做贡献。主要是在文档方面，也就是为文档做贡献，文档还有很多需要完善的地方。Eleventy 的商业化让这件事变得复杂，这也是我自二月以来在文档更新上停滞的部分原因：会让人不禁去想，是否会有某个拿钱的专业文档贡献者突然出现，让我做的一切都变得无关紧要。也许 Kickstarter 众筹会非常成功，能支持多位全职维护者，或者至少让 Zach 能够安心全职投入。我希望至少这能腾出足够的时间，让 11ty 及其所有相关项目能够更快地审核和合并 pull request，因为遗憾的是，那边的进度一直很慢。

你该用 Eleventy 吗？也许吧！从零开始写一个新的静态网站生成器很有趣，但参与一个社区、去改进一个受欢迎的工具，则是另一种截然不同的充实体验。

Eleventy 的热度远不如 Astro。它自身也有不少问题。但和其他软件一样，它是一种愿景和价值观的体现，其中很多都与我产生了共鸣。我希望它是那种正确的软件，15 年后我依然会在使用它。

哦对了，如果你对 Build Awesome 的发布感到兴奋，欢迎去它的 Kickstarter 页面支持一下。我大概也会去赞助一点。