為什麼 Vanilla JavaScript 很重要

為什麼 Vanilla JavaScript 很重要

核心論點：Vanilla JavaScript 仍是大多數專案的最佳選擇

Vanilla JavaScript——純粹、無框架的程式碼——仍是構建 Web 介面的最有效方式，因為它避免了庫與框架所帶來的執行時成本、套件大小以及鎖定效應。

消除不必要的額外負擔

結論： 使用 Vanilla JavaScript 可移除框架帶來的額外 JavaScript 負載，從而加快頁面載入速度並降低頻寬消耗。

  • 現代瀏覽器原生支援 DOM 操作、事件處理以及透過 Fetch API 的 AJAX。這些功能已不再需要 polyfill 或抽象層。
  • 一個典型的 React 或 Vue 套件在代碼分割前會增加 30 KB–150 KB 的 gzip 後 JavaScript。相比之下，可比的 Vanilla 實作可低於 10 KB。
  • 更快的載入時間可提升 Core Web Vitals，尤其是 Largest Contentful Paint (LCP) 與 First Input Delay (FID)，這直接影響 SEO 與使用者留存率。

性能提升可量化

結論： 基準測試一再顯示，對於簡單的 UI 互動，Vanilla 實作的表現優於框架等價方案。

  • 2023 年 Web.dev 的案例研究顯示，將一個小型 React 小部件替換為 Vanilla 程式碼，可將 JavaScript 執行時間減少 45 %。
  • 由於沒有虛擬 DOM diff 步驟，更新直接作用於真實 DOM，消除了協調的開銷。
  • 缺少框架執行時可降低記憶體使用量，這對低階裝置與嵌入式瀏覽器尤為關鍵。

降低相依風險

結論： 依賴 Vanilla JavaScript 可消除第三方函式庫可能被拋棄或出現安全漏洞的維護負擔。

  • 框架遵循的發佈週期可能帶來破壞性變更；使用 Vanilla 程式碼則只需關注瀏覽器規範的演進。
  • 安全修補僅限於瀏覽器本身，且會自動更新；而函式庫則需要手動升級版本。
  • 避免外部相依的專案可免於「相依地獄」——傳遞相依、版本衝突與供應鏈攻擊。

透過標準未來保證

結論： 隨著 Web 平台的演進，新標準直接加入瀏覽器，使得 Vanilla 程式碼越來越強大。

  • Custom Elements、Shadow DOM 與 ResizeObserver API 現已原生支援，無需元件庫。
  • Intl 與 Temporal API 提供強大的國際化與日期時間處理，無需外部套件。
  • 漸進增強鼓勵先以 Vanilla JavaScript 建構核心功能，再逐層加入可選的增強功能。

框架仍有其合理性時機

結論： 對於需要結構化架構、狀態管理以及大型開發團隊的複雜大型應用，框架是合理的選擇。

  • 框架強制執行慣例（路由、狀態容器、元件生命週期），有助於在多位貢獻者之間保持一致性。
  • 生態系工具——如熱模組替換、型別安全的 props 與豐富的 UI 元件庫——可加速功能豐富產品的開發。
  • 決策應基於專案規模、團隊專業能力與性能需求，而非流行趨勢。

採用 Vanilla JavaScript 的實務步驟

結論： 當開發者遵循幾項自律的做法時，轉向 Vanilla JavaScript 是相當直接的。

  1. 從瀏覽器 API 開始 – 在使用函式庫前，先使用 document.querySelector、addEventListener 與 fetch。
  2. 使用 ES Modules 模組化 – 將程式碼拆分為可重用的 .js 檔案，並以原生 import 語句匯入。
  3. 適度使用建置工具 – 僅使用最小的 bundler（例如 esbuild 或 vite 的 library‑mode）來為舊版瀏覽器轉譯，而非為整個框架填充 polyfill。
  4. 撰寫測試 – 使用 Jest 與 jsdom 等工具對 DOM 互動進行單元測試，以在程式碼基礎成長時保持信心。
  5. 文件化模式 – 為常見任務（例如元件建立、狀態處理）建立共享的風格指南，確保程式碼庫的一致性。

結論

Vanilla JavaScript 提供更佳的效能、較低的維護負擔，且與不斷演進的 Web 標準高度契合，除非專案的複雜度需要完整的框架，否則它應成為大多數 Web 開發任務的預設選擇。

Sources