Zero-Build 哲學：為什麼我刻意不用 webpack / vite

我做這個工作室前 10 年都活在 webpack / Vite / esbuild 的世界。每個專案都有 build step、有 npm install 的等待、有「為什麼 production 跑不起來但 dev 可以」的悶。一年前我做了一個實驗：能不能完全不用 build tool 做出 production 級的網站？這篇是答案。

什麼是 zero-build

定義：原始碼直接就是部署到 server 的內容。沒有 transpile、沒有 bundle、沒有 minify、沒有 npm install。

本站（hao0321.com）就是這樣。每個 HTML 檔案是手寫的、所有 CSS 寫在同一個 <style> 區塊、JS 直接 inline。整個工作室官網沒有 package.json。

失去什麼

1. 模組化

不能 import。所有跨檔案共用程式碼要靠 <script> 標籤的全域變數。本站的解法：每頁都複製貼上同一份 CSS（醜但穩）。

2. TypeScript

只能寫 vanilla JS。但實際上：

VS Code 會根據 JSDoc 註解推導型別
用 // @ts-check 開啟檢查
單檔規模 < 1000 行時，TypeScript 的價值很有限

3. CSS preprocessor

沒有 Sass、Less、Tailwind compile。但 CSS variables 已經涵蓋 80% 我以前用 Sass 變數的場景。Nesting 也可以用原生 CSS。

4. Hot reload

沒有 dev server 自動重新整理。但用 VS Code 的 Live Server 擴充功能就有相同效果，不需要 build pipeline。

得到什麼

1. 啟動時間 = 0

打開檔案就能看效果。不需要 npm run dev 等 30 秒。心理上「想到 → 看到」的距離壓到最短。

2. 部署時間 = 上傳時間

沒有 CI build。Cloudflare Pages 收到檔案直接吐給 CDN。Hao0321 從 push 到 production 約 30 秒。

3. Bundle size = 真實 size

沒有 framework runtime overhead。本站首頁 JS 約 5KB（gzipped），這對任何 SPA 都是不可能的數字。

4. 三年後還能跑

這是最大的勝利。沒有依賴鏈意味著沒有 npm 套件升級的痛苦、沒有 deprecated API、沒有「為什麼新版 Node 跑不起來」。HTML/CSS/JS 是 web 三大支柱，向後相容性近乎永遠。

5. 任何人都能 contribute

不需要先讀懂 Vite config、不需要懂 Webpack alias、不需要設定 node_modules。打開 .html 檔就懂。

不適合 zero-build 的場景

場景	為什麼
大型 SPA（> 50 個畫面）	沒有 routing 框架會痛苦
需要 SSR / SSG 的內容站	純 HTML 已經是 SSG，但動態內容生成需要 build step
團隊 > 3 人	缺乏編輯器型別檢查的協作風險高
SaaS 後台（高互動）	狀態管理很快會超出 vanilla JS 能輕鬆處理的規模
需要 npm 套件的核心邏輯	例如 Stripe SDK、認證套件，必須 bundle

適合 zero-build 的場景

作品集 / 個人網站：頁面數量有限、視覺優先
內容站：blog、產品說明、使用條款
單頁應用工具：計算機、轉換器、視覺化
瀏覽器小遊戲：單檔 HTML 易發布到任何平台
Demo / Prototype：快速試做想法

混合策略：部分 build

本站的妥協：主站 zero-build，但遊戲大廳的個別遊戲用 React via Babel（在瀏覽器即時轉譯）。這樣大部分頁面 zero-build，需要狀態管理的個別遊戲還能用 React。

// play.html 動態載入 .jsx
fetch('cat-battle.jsx')
  .then(r => r.text())
  .then(raw => {
    const transformed = Babel.transform(raw, { presets: ['react'] }).code;
    eval(transformed);
  });

缺點：每次切換遊戲多 100ms 轉譯時間。優點：依然沒有 build step。

反面論點：build 不是問題，是工具進化

誠實地講：Vite 比 webpack 快 10 倍、esbuild 比 Vite 又快 10 倍。「build 慢」這個問題在 2024 年之後幾乎不存在了。zero-build 的價值不是「快」，是「少一層複雜度」。

對個人專案，少一層複雜度的價值極高。對企業專案，多一層工具帶來的能力（型別、模組、樹搖優化）通常勝過簡潔。

給想試試的人的建議

從新專案開始，不要把現有 Vite 專案硬轉
先設定 Live Server，把開發體驗補齊
用 CSS variables 取代 Sass 變數
用 ES modules（<script type="module">）取代 import 語法（限現代瀏覽器）
JSDoc + // @ts-check 取代 TypeScript
用 Cloudflare Pages 部署（不需要設定 build command）

結語

Zero-build 不是反潮流，是對「不必要複雜度」的抗議。對於規模適合的專案，省下的時間與心智能量足以做出更好的內容。一年下來我沒有想念過 webpack。

有想實驗 zero-build 但卡住的朋友，歡迎寄信 lo246179268@gmail.com。