無建構工具宣言：不用打包工具直接發布

以下並非要您放棄建構工具的論述，而是對放棄後實際結果的測量。

blakecrosley.com 運行 FastAPI + Jinja2 + HTMX + Alpine.js + 純 CSS。沒有 webpack、沒有 Vite、沒有 Rollup、沒有 TypeScript 編譯器、沒有 Babel、沒有 PostCSS、沒有 Tailwind、沒有 package.json、沒有 node_modules/。網站提供 33 篇部落格文章、14 個互動式 JavaScript 元件、20 份指南、九種語言翻譯，並在 Lighthouse 上取得 100/100/100/100 的滿分。

摘要

HTMX 社群不缺倡導，缺的是證據。這裡的數據來自一個具備大量內容、互動功能和國際化支援的生產環境網站，而且完全沒有使用任何建構工具。取捨是誠實的，結論也是限縮的：對於內容導向、由個人開發者或小團隊維護的網站，建構工具解決的是您沒有的問題，同時製造了您確實會有的問題。對於擁有共用元件庫和設計系統套件的大型團隊，建構工具的複雜性是值得的。這條界線比社群討論中暗示的更加清晰。

技術堆疊

Backend:    FastAPI + Jinja2 (server-rendered HTML)
Frontend:   HTMX + Alpine.js + Bootstrap 5 (CDN)
Styles:     Plain CSS with custom properties
JavaScript: Vanilla JS, IIFE-scoped per component
Deployment: Railway (git push → live)
CDN:        Cloudflare (caching, Workers, D1)

沒有轉譯、沒有 tree shaking、沒有熱模組替換、沒有 source maps。您寫的 JavaScript 就是最終交付的 JavaScript。

實際數據

以下是真實指標，不是估算：

這 18 個 Python 套件包含 FastAPI、Jinja2、Pydantic、SQLAlchemy 及其他 14 個。沒有任何一個是建構工具、編譯器或打包工具。²

您放棄了什麼

誠實要求列出真實的代價，而它們確實存在。

沒有 TypeScript。 這個專案中的每個 .js 檔案都是原生 JavaScript。測試和 Claude Code 的分析負責捕捉型別錯誤，而非編譯器。這種做法對個人開發者有效，但對 10 人團隊在模組間共用元件介面的情境下不適用。

沒有熱模組替換。 當我修改 CSS 檔案時，我手動重新整理瀏覽器。HTMX 的 hx-boost 讓導航足夠快，全頁重新整理是可以忍受的。在每 30 秒就需要迭代視覺細節的專案中，HMR 確實能節省可觀的時間。

沒有 Tree Shaking。 我寫的每一個位元組的 JavaScript 都會送到瀏覽器。我無法從工具函式庫中只匯入單一函式而不送出整個檔案。這個限制迫使養成紀律：用小而專注的檔案取代大型工具模組。14 個互動元件平均各 300-700 行，因為它們必須自給自足。³

沒有來自 npm 的元件庫。 沒有 Radix、沒有 shadcn/ui、沒有 Headless UI。每個互動元素（Boids 模擬、漢明碼視覺化器、共識模擬器）都是手工打造的。這種做法之所以可行，是因為互動元件服務於特定的教學目的，而非通用的 UI 模式。

沒有來自 npm 的設計系統 Token。 我的設計系統完全存在於 CSS 自訂屬性中。我無法將它作為套件匯入到其他專案。對於單一網站的系統，這個限制是可以接受的；對於多產品組織來說則不然。

這五項取捨對於一個由單一開發者維護的內容導向網站是可以接受的。對於一個擁有 15 人工程團隊的 SaaS 產品則不可接受。

您獲得了什麼

零建構失敗。 部署流程就是 git push。不會有 npm install 因為 peer dependency 衝突而失敗。不會有 next build 因為某個我沒碰過的檔案中的 TypeScript 錯誤而失敗。不會有 Dependabot PR 升級了一個間接相依套件然後破壞建構。⁴

用「檢視原始碼」來除錯。 在瀏覽器中執行的 JavaScript 就是我寫的 JavaScript。不需要 source maps。不需要從編譯輸出反向對應到原始碼。當生產環境出現 bug 時，我直接閱讀部署的檔案。

瞬間本地啟動。 uvicorn app.main:app --reload 在 2 秒內啟動。不需要先安裝、編譯、打包才能看到頁面的 npm run dev。

零 Dependabot 噪音。 沒有 package-lock.json 意味著沒有每週更新 semver、ansi-regex 或 glob-parent 的 PR——這些是我從未直接匯入、卻深藏在相依樹三層之下的套件。

面向未來。 這個網站 10 年後仍然能運作。HTML 就是 HTML。CSS 就是 CSS。JavaScript 就是 JavaScript。不需要 Webpack 4 → 5 遷移、不會遇到 Create React App 棄用、不需要 Next.js App Router 遷移。平台本身就是標準。⁵

HTMX 作為架構

HTMX 的討論焦點集中在語法：hx-get、hx-swap、hx-target。這是錯誤的視角。架構上的洞見在於伺服器渲染的 HTML 本身就是 API。

在傳統 SPA 中：

Browser → fetch('/api/users') → JSON → React renders HTML → DOM update

使用 HTMX：

Browser → GET /users (hx-get) → Server renders HTML fragment → DOM swap

伺服器回傳的是最終呈現。沒有客戶端狀態管理、沒有序列化/反序列化、沒有 hydration。Jinja2 模板就是元件。FastAPI 端點就是 API。一層，而非三層。⁶

這種模式直接對應複合工程原則：每一塊基礎設施只做一件事，且各部分組合時互不干擾。模板渲染 HTML、路由回傳它、HTMX 將它替換進 DOM。不需要建構步驟來協調這些部分，因為根本不需要協調。

純 CSS 就夠了

我的設計系統使用 10 個顏色 token、13 個字體大小層級和 8 個間距值——全部都是 CSS 自訂屬性：

:root {
  --color-bg-dark:        #000000;
  --color-text-primary:   #ffffff;
  --color-text-secondary: rgba(255,255,255,0.65);
  --spacing-sm:           1rem;
  --spacing-md:           1.5rem;
  --font-size-lg:         1.25rem;
}

沒有 Sass 編譯步驟。沒有 Tailwind 設定檔產生工具類別。沒有 PostCSS 外掛程式轉換自訂語法。瀏覽器直接讀取這些值。⁷

這個網站的美學與粗獷主義風格（白字在純黑底上搭配四階不透明度）正是從限制中產生的。當您無法使用色彩調色盤時，字體排版承擔起層級。當您無法使用元件陰影時，留白創造結構。限制本身就是設計。⁸

CLS 之旅

Lighthouse 之旅揭露了無建構工具的一個真實代價：關鍵 CSS 擷取需要一個自訂 Python 腳本。在 Next.js 專案中，框架會自動處理這件事。

具體的問題：一個行動裝置媒體查詢覆寫了一個 CSS 自訂屬性（--gutter: 48px → --gutter: 24px）。關鍵 CSS 包含了桌面版的值，卻沒有包含行動裝置的覆寫。在行動裝置上，主視覺區域先以 48px 內距渲染，然後在完整樣式表載入後切換為 24px，產生了 0.493 的 CLS。

修復只花了 12 行 Python。調查花了三小時。建構工具本可以自動處理這個問題。

誠實的核算：建構工具自動化的是您可以手動完成的事情，但手動版本在出問題時需要付出除錯時間。問題在於自動化的成本（複雜性、相依套件、建構失敗、遷移變動）是否超過手動的成本（偶爾的除錯時段）。

對這個網站而言，手動成本一直較低。三年間，一個 CLS bug，三小時的除錯。另一種選擇（維護建構流水線）在相依套件更新、破壞性變更和設定維護上會消耗更多累積時間。

何時不該採用此方法

無建構工具的做法在以下情境是錯誤的：

大型團隊。 TypeScript 的價值隨團隊規模而擴大。⁹當 10 位開發者共用元件介面時，編譯時期型別檢查可以防止那些執行時期測試發現得太遲的整合錯誤。個人開發者能在腦中掌握整個系統，團隊做不到。

設計系統套件。 如果多個產品使用您的設計系統，它就需要是一個具備適當版本控制、tree shaking 和建構流水線的 npm 套件。單一樣式表中的 CSS 自訂屬性無法跨儲存庫組合使用。

複雜的客戶端狀態。 如果您的應用程式具有豐富的客戶端狀態（拖放介面、即時協作、離線優先資料），React 或 Svelte 等框架的複雜性是值得的。HTMX 用伺服器往返取代客戶端狀態，在延遲成為問題之前都是有效的。

npm 生態系統函式庫。 如果您需要 Radix 基本元件、Framer Motion 或 TanStack Query，您就需要建構流水線。這三者都假設有打包工具存在。在沒有打包工具的情況下使用它們，從困難到不可能都有。

界線比社群討論中暗示的更簡單：如果您的應用程式主要是由伺服器渲染的內容，建構工具就是額外負擔；如果您的應用程式主要是由客戶端管理的狀態，建構工具就是基礎設施。

重點總結

對於個人開發者和小型團隊：

• 證據是網站本身，不是論述。 blakecrosley.com 以零建構工具和完美 Lighthouse 分數提供 33 篇文章、14 個互動元件、20 份指南和九種語言。這些數據可供驗證。

• 無建構工具的真實代價是偶爾的除錯。 CLS bug 花了三小時修復，建構工具本可以自動處理。三年來，累積的除錯時間遠低於建構流水線所需的累積維護時間。

• 限制造就設計。 沒有顏色迫使字體排版承擔層級。沒有建構工具迫使 JavaScript 保持簡單且自給自足。最好的限制是您在需要之前就選擇的限制。

對於評估技術堆疊的團隊主管：

• 建構工具解決的是團隊規模的問題。 TypeScript、tree shaking 和元件庫在多位開發者共用介面時才值得其複雜性。建構內容導向網站的個人開發者並不存在這些問題。

• HTMX 的真正貢獻在於架構。 伺服器渲染的 HTML 作為 API，消除了客戶端狀態管理、序列化和 hydration。語法是次要的，洞見才是重點。

本文橫跨部落格的設計和工程分類。設計決策見美學與粗獷主義、新創公司的設計系統和字體大小系統。工程測量數據見 Lighthouse 滿分和複合工程。Vibe Coding 一文探討了這套理念在 AI 輔助開發中的適用之處。