我在 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 用起來簡單，實作本身也要簡單。因為任何工具遲早都會出問題，我希望出問題時能自己打開來找到原因。複雜的專案也往往更難維護，這也是關鍵——如果沒有取得主導地位，往往就活不久。

長久性很難預測。林迪效應（Lindy Effect）是個不錯的捷徑：

某種不易消亡的事物，例如一項技術或一個想法，其未來的預期壽命與它目前已經存在的時間成正比

但在科技領域，最新的解決方案也可能是最好的，你還是得做一些預判。貢獻者數量多寡也是一個指標，但前提是這些貢獻者來自多個不同的組織。如果一個專案的貢獻者大多來自同一家公司，一旦公司裁員，專案很快就會沉寂。如果專案能在多次主導權與掌控權的更迭中存活下來，也很能說明問題。

對這個網站而言，我更在意使用者端的速度，而不是開發時的速度。對我來說，預覽 Markdown 修改要花 100 毫秒還是多久，遠不如讀者載入頁面要花多久來得重要。反正大多數靜態網站產生器只要不亂搞，速度都夠快。以我的經驗，那些「建置很慢」的產生器，效能瓶頸大多卡在層層巢狀的迴圈上。

Eleventy 在這些條件上算是過關了。它的貢獻者社群雖然很小，但 Zach 非常有毅力，也什麼風雨都經歷過了。它建置網站的速度很快，也內建了許多最佳化工具——這些工具讓我得以取代原本為 macwright.com 寫的客製化程式碼。而且和 Astro 形成鮮明對比的是，它把內部簡潔當成優先原則。不論是程式碼行數還是依賴數量，它都是個小巧的專案，也沒有依賴那種巨型套件。全新安裝的 Astro 包含246 個依賴，其中包括 Vite 和 esbuild；而 Eleventy 大約只有一半——116 個依賴，大小是 14.6MB，而不是 87.9MB。

我覺得 Eleventy 還可以更簡潔（寫這篇文章期間，我也為此提了一個小 PR），例如砍掉一些帶有不必要微型依賴的老套件。e18e 這個致力於移除與縮減依賴的專案，真的非常有必要！

靠靜態網站產生器很難養活自己

當然，還有那則消息：Eleventy 現在變成了 Build Awesome。這是繼許多類似消息之後的又一樁：

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

因為這些都是開源專案，「收購」這個詞得打個星號：通常指的是把團隊聘走，或許拿到商標，以及接收原有的業務。

Zach 因為這個決定受到不少批評。我也同意「Build Awesome」聽起來有點千禧世代的味道，Eleventy 原本是個更酷的名字。這次 rebrand 確實有點奇怪。

但整體來說，我能理解。你不可能一邊慢慢釋出重大策略與產品發布，一邊徵詢所有人的意見。Eleventy 和 Web Awesome 的其他產品其實頗為契合：圖示、Web Components，以及靜態網站建置工具。它們都是走傳統派、而非前端極繁主義路線的優秀網路工具。

我想，正如我們所見，要將底層工具變現是極其困難的，很大一部分原因是每個開發者隨時都可能因為任何理由、或根本沒有理由，只因為聽起來像是個有趣的 side project，就自己動手做一個靜態網站產生器。你可以將更高層級的內容工具變現——Kirby、Sanity 以及其他幾個帶有 CMS 功能的網站產生器就做到了，並建立起小而永續的事業。但像 Eleventy 這樣形態的工具，很難作為小型產品事業來經營。至少，你得靠提供服務才行。

所以，結果大概就這幾種：

1. 被某家大型、甚至可能是上市公司收購，作為擴大其託管／CDN 平台的一種方式。這就是 Astro、Nuxt、Gatsby、Remix，乃至在某種程度上 Begin 的命運。Jekyll 從一開始就是如此：它由 Tom Preston-Werner 在 GitHub 任職時打造，是讓 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 小得多。它也有不少自己的問題。但就像其他軟體一樣，它是一種願景與價值觀的體現，而其中很多都與我產生共鳴。我希望它是對的那種軟體，十五年後我依然會繼續使用它。

喔對了，如果你對 Build Awesome 的發布感到興奮，歡迎去 Kickstarter 登記。我大概也會贊助一點。