我曾撰文討論如何使用 LLM（Lots of Little HTML pages，意即大量的 HTML 小頁面）來建置網站，我認為現在是時候對這種方法進行檢討了：

我對原始文章中的一些做法進行了調整，但核心理念仍然相同，我會將其描述為：

避免使用需要 JavaScript 的頁內互動，轉而採用依賴 HTML 的多頁面導航，並透過 CSS 視圖轉換（以及酌情使用少量 JavaScript）來增強。

舉例來說，在我的部落格上，有一個「選單」。它不會像使用 JavaScript 那樣「展開」、「滑出」或「彈出」。相反地，它會導航到一個完全專注於網站選單選項的新頁面。

我說「導航」是因為它只是一個連結 — `<a href="/menu/">` — 它的功能就像一個連結，但導航互動透過 CSS 視圖轉換來增強。

擁有較新的裝置和現代瀏覽器？太棒了，你會獲得更流暢的效果。

擁有較舊的裝置、較舊的瀏覽器，或禁用 JavaScript 等？它仍然會正常運作。

如果你能點擊連結 — 這是瀏覽器最基本的功能 — 它就會奏效。

那麼，這一切在底層是如何運作的呢？本質上，所有頁面都有一個指向選單的連結（選單頁面除外）。當你導航到選單頁面時，該連結會變成一個「X」，用來「關閉」選單。這個關閉動作仍然只是一個連結（返回 `/`），但它透過 JavaScript 進行了增強，以便在瀏覽器歷史記錄中執行「返回」操作。這樣一來，「開啟/關閉」選單就不會為你的瀏覽器歷史記錄增加一個條目。

作為一個簡化的範例，程式碼看起來像這樣：

`document.referrer` 檢查我們是透過導航（最可能是從部落格內部）來到這個頁面的，還是透過直接訪問（例如，有人在 URL 列輸入）而來的，這就是我判斷是否有有意義的 `history.back()` 執行的依據。

如果你喜歡看影片，這裡有一個展示所有功能運作方式的影片：

雖然這個解決方案看似簡單，但要達到這個結果並不容易。我花了很多時間思考導航的本質是什麼，這種互動如何在多個頁面之間運作，以及如何確保頁面大小保持較小，以便互動既快速又穩健，同時保持直觀易用。

換句話說，這種方法塑造了設計。

結果發現，如果你有一個網站，並且將瀏覽器視為導航文件的工具 — 而不是執行任意程式碼、獲取、編譯和呈現它們的運行環境 — 那麼事情可以比我們的工具通常讓我們認為的要簡單得多。