今年年初，我終于決定將自己的網站從基于 php 的 CMS 移植到基于 JAVAScript 的靜態網站生成器（SSG）了。原因如下：

1. 雖然一開始我是“全棧”開發人員，但現在我只負責前端工作：如果我需要編寫自定義功能，那么能用 JavaScript 編寫的代碼我就不想用 PHP 來寫。
2. 我不需要抽象層或 CMS 的復雜性——我最喜歡用 markdown 文件編寫內容，并且希望永遠不要再碰 MySQL 數據庫或所見即所得編輯器。
3. 我想提高網站的性能：靜態 html 文件在 99% 的時候都比動態頁面更快。
4. 最后還有成本優勢：LAMP stack 服務器得按月付費；Netlify 的免費套餐（每月構建 300 分鐘）應該可以輕松覆蓋零成本個人博客的需求。

當我決定使用靜態站點生成器和 JavaScript（排除了 Jekyll 和 Hugo）后，就只剩下兩個差別頗大的選項了。

“我聽說 Gatsby 很好用”

根據官方網站的說法，“Gatsby 是一個基于 React 的免費開源框架，可幫助開發人員構建速度飛快的網站和應用”。它有一個由 GraphQL 支持的數據層，并將所有內容輸出到靜態文件，使你可以在幾乎任何地方托管它。

當我第一次聽說我可以編寫 React 并使用這個很酷的 GraphQL 新玩意兒，同時還能輸出不需要 JavaScript 的靜態頁面時，我很想嘗試它一下。我是這么想的：“這聽起來像是漸進增強，但用不著什么投入”。不幸的是，就像大多數聽起來過于美好的事情一樣，經過一些調查我發現它就是個坑。用戶首次訪問 Gatsby 網站時會發生這些事情：

1. 用戶請求一個頁面。
2. 服務器將靜態生成的 HTML 文檔發送到用戶的瀏覽器，然后瀏覽器開始渲染頁面。
3. HTML 文檔到達后，JavaScript 包（包括 React 庫和渲染頁面所需的其他 JavaScript）開始在后臺下載、解析和編譯。
4. JavaScript 已準備就緒，可以運行——整個 DOM 通過 React 組件“被水化”（hydrated）。

這里就有些不對勁——Gatsby 需要你以 React 組件的形式再加載一次頁面；在完成多出來的這一步之前，所有需要 JavaScript 的元素（例如按鈕、菜單、自定義輸入）實際上都不能交互。

哪怕你的網站沒有任何互動元素（鏈接除外，即使沒有 Gatsby，它們也無需 JavaScript 即可工作），你的用戶也必須下載這部分 JavaScript，僅僅是為了將你的網站變成單頁應用程序（SPA）；SPA 是有自己的缺點的，我們稍后再提。

這種多出來的操作看來是違背我轉向 SSG 的初衷（提高頁面速度）的。華麗的 Gatsby 網站在 2,000 美元的 macBook 上可能很快，但對于使用 3G 連接和廉價智能手機的用戶來說，它顯示是能顯示出來，但是沒有響應；用戶等待加載 JavaScript 的過程要持續 15 秒。電池和數據流量也得跟著往下掉了。

如果瀏覽器需要解析 296kb 的 JavaScript 代碼才能顯示出博客文章的列表，這就不是什么"漸進增強”，而是用錯了工具。從網站 /Web 應用的大致區別來看，React 是用于構建 Web 應用的，這種應用需要有響應用戶輸入或實時獲取數據的交互式 UI；而博客只是一個網站而已。

單頁應用程序中的可訪問性

單頁應用程序這種網站放棄了傳統的 Web 導航方法，即通過加載新的 HTML 文檔來加載新內容；相反，它使用 AJAX 和 History API 之類的 JavaScript 特性來切換到新內容上，而不會觸發頁面加載。它的目標是提高感知的性能，并使網站看起來更像“原生”應用（從應用商店下載的那種）。不再需要整頁重新加載的問題在于，瀏覽器和輔助技術將頁面加載用作觸發某些有用行為的信號，包括宣布新頁面的標題或將鍵盤焦點重置到文檔的開頭。

如果你在開發關注可訪問性的單頁應用程序，那么你可能會試著使用 JavaScript 來模擬瀏覽器的行為。Gatsby 試圖通過包含一個 RouteAnnouncer 組件來為你解決這個問題。它使用一個 ARIA live region 來宣布頁面的 title 或 h1，以對使用屏幕閱讀器軟件的用戶提示頁面跳轉行為。但這種方法也存在問題：它在配置和本地化方面仍然存在很多未解決的 issue。

我們已經看到，單頁應用程序在導航方面存在固有的可訪問性問題，但要注意的是，使用前端框架也會在其他方面帶來可訪問性問題。在 2020 年 2 月對 100 萬個首頁的調查中，WebAIM 發現使用 React 的網頁的可訪問性錯誤比平均水平高 5.7％；而使用 Vue 的網頁則高出 25％。這并不一定意味著框架一定會導致這些錯誤，但是更多的 JavaScript 與更差的可訪問性之間存在很強的相關性。

博客真的需要 JavaScript 嗎？

很有可能，你構建的第一個網頁的性能要比之后構建的許多頁面都要好得多——它由一個 HTML 文件和一些 css 組成，也許還有一些未優化的圖像，但它們并不會阻止頁面加載。如果你也有我這樣的經歷，那么開始添加 JavaScript 的那一刻，你的網頁性能就開始急劇下降了。并非所有字節都是一樣的：與同等大小的 JavaScript 文件解析、編譯和執行所需的時間相比，圖像解碼和渲染到屏幕所需的時間要少得多。

JavaScript 是一種強大的語言，可以完成一些令人難以置信的事情，但是在開發中你很容易過早開始使用它，其實本來用 HTML 和 CSS 就夠了。應該看看最小功能原則：在你充分利用功能較弱的語言（HTML）之前，請不要使用功能更強大的語言（JavaScript）。在我看來，將博客變成 JavaScript 單頁應用程序會帶來不必要的復雜性。

這篇文章并不是要批判 Gatsby 而寫的。它的背后有一些聰明的頭腦，他們已經承認了本文中提到的許多問題，并試圖解決它們。靜態渲染和水化的頁面還是比完全客戶端渲染的 React 應用（如 create-react-App 生成的頁面）要好得多，后者沒有 JavaScript 就沒法用。我確實不太滿意 Gatsby 的宣傳手法，他們說 Gatsby 適合任何類型的網站。客戶端 JavaScript 是有成本的，開發人員應該意識到這一點。

用更少的 JavaScript 構建 Gatsby 網站

這使我陷入了一個兩難境地：使用 Gatsby 開發網站是絕妙的體驗；但是開發體驗（DX）應該永遠排在用戶體驗（UX）之后。那么如何在構建 Gatsby 網站時避免那些因為大量使用 JS 而帶來的固有問題呢？當然，我們應該盡量刪掉那些 JavaScript。所幸 Gatsby 社區內做出了很多努力來構建更、，更輕量級的網站：

首先，使用 gatsby-plugin-preact 將 React 換成 Preact 可以節省幾千字節。我在 Component Gallery 上用了它，立刻將 JavaScript 負載減少了約 30kb。

如果你想用更激進的方法，可以使用一個插件來從你的 Gatsby 網站刪除所有 Gatsby JavaScript。

你可以繼續編寫 react 組件和 GraphQL，甚至可以使用 CSS-in-JS 庫（只要它輸出 CSS 或內聯樣式），而無需向瀏覽器發送任何 JavaScript。只要扔掉所有客戶端 JavaScript 就可以解決 Gatsby 的大多數問題。Gatsby Starter Low Tech 博客使用 no-javascript 插件和其他一些技術（包括將所有圖像轉換為灰度），來幫助你創建一個輕量且節能的博客。

用 Eleventy 從頭開始

這時候我感覺有點不對勁——使用一個會大量推送客戶端 JavaScript 的框架，卻要刪除所有 JavaScript 代碼，這似乎是一種很復雜的網站構建方式。我想看看是否可以不用客戶端 JavaScript 來構建功能完善的博客，這樣就用不著什么插件來刪除它了。于是我轉向了另一個選項：

Eleventy 鼓勵你按照自己的意愿構建網站。你可以使用自己最熟悉的技術，它只負責生成頁面。Eleventy 為你提供了十種可以任意搭配的模板語言選項，包括 markdown、nunjucks 和 liquid；這意味著我可以從 Craft 中復制并粘貼舊的模板，更改文件擴展名，并做一些細微的調整就能運行在 Eleventy 中。用不著針對什么新的打包器來調整前端構建流程，我只需放入現有的 webpack 文件和 src 文件夾即可。使用并發包，我可以在 Eleventy 的 serve 過程中同時運行構建腳本。

像 Gatsby 一樣，Eleventy 也有一個插件生態系統（雖然很小，但增長迅速）。我挑選了一些不需要添加客戶端 JavaScript 也能添加功能的插件：

在帖子中顯示代碼段時，通常會包含特定于語言的語法高亮顯示。有一些 JavaScript 庫可以做到這一點，其中最流行的似乎是 Prism——你可以在客戶端中運行它，但由于我們使用的是 JavaScript SSG，因此可以在構建時運行它，并將語法高亮顯示所需的 HTML 元素和 CSS 類直接烘焙到文檔中——這樣就無需在瀏覽器中下載這個庫了。

eleventy-plugin-embed-tweet 也可以在構建時而非客戶端運行 JavaScript。Twitter 的默認嵌入代碼迫使用戶下載大量 JavaScript 才能顯示一條推文。這個插件可以在構建時獲取并渲染推文，這樣只需少量 HTML 和 CSS 即可，根本不需要額外的 JavaScript。

與其他新技術一樣，Eleventy 缺少某些更加成熟的工具所提供的功能。例如，在 Eleventy 中沒有一種優雅的方法來生成響應式圖像。相比之下，Gatsby 中出色的 gatsby-image 插件可以生成延遲加載和響應式的圖片元素，并能在加載全分辨率文件后在低分辨率或 SVG 版本的圖像間平滑切換。Eleventry 還有一些讓我感到困惑的事情：我有一陣子一直搞不懂它的分頁功能，認為它只是將帖子分頁到指定大小的一些組中，之后才意識到它可以動態生成全新的頁面；我還發現自己在同一文件中混用了模板語言：你可以隨意在 markdown 文件中包含 nunjucks 標簽，或將基于 yaml 的 frontmatter 換成 JavaScript，但這會破壞語法高亮顯示、linting 和自動格式化。

結論

如果你還是選擇了 Gatsby，我也不會怪你——有時候使用一個 opinionated 的框架也不錯，并且如果你想要快速完成工作，這是一個可靠的解決方案。只是要注意它的性能成本，以及所有與 JavaScript 相關的潛在可訪問性問題。

我選擇使用 Eleventy 來構建自己的網站，但我知道這種方法并不適合所有人——完全按照自己的意愿來構建某些東西可能是很麻煩的事情。但你也用不著完全學我——與 Gatsby 類似，Eleventy 也有許多入門項目可以用作基礎。其中一些工具，例如 Andy Bell 的 Hylia 入門套件可以在幾分鐘內搞定一個網站。它甚至預配置了 Netlify CMS，因此你無需編寫任何代碼即可編輯網站內容。

我學到了什么呢？使用 Eleventy 可以輕松構建不帶 JavaScript 的博客，但總會有一些功能需要客戶端 JavaScript 的：

• 我的網站拿掉了 google Analytics，但它對用戶來說沒什么用途，所以我也不在乎——我會在另一篇文章中介紹它的服務端替代品。
• 我使用了 loading="lazy"屬性來延遲加載圖片，但它的瀏覽器支持不夠完整，并且在原生瀏覽器實現改進之前，它無法在加載圖片時淡入淡出。
• 黑暗模式切換——雖然我可以只用 CSS 來實現，無需訪問 cookies 或本地存儲，但我沒辦法在頁面之間保持設定的值。

我是否會在不久的將來在網站上加入 JavaScript 呢？答案可能是否定的：我上面列出的功能并不是那么重要的。我并不是推薦大家都刪除自己網站上的所有 JavaScript 文件，但從現在開始，在構建網站時我會嘗試將 JavaScript 視為可選的額外功能，而不是體驗的基本組成部分。我鼓勵你也這樣做。