前端建構工具 (build tool) 是什麼? 為什麼要用?

對現代前端開發來說，建構工具 (build tool) 是相當重要的一個要素。從過去常聽到的 Webpack，到後來竄起的 Vite，都是建構工具，但這類工具究竟在做什麼?

要往資深前端工程師邁進，不能只會寫程式碼，還需要對各種工具有足夠掌握，而建構工具就是其中需要掌握的。因此，在這篇文章，我們要來談什麼是建構工具、為什麼要用建構工具，以及具體來說建構工具做了什麼。

建構工具是什麼? 與打包工具有什麼區別?

在最開始，想先區分比較容易搞混的兩個名詞，一個是這篇文章會著重的建構工具 (build tool)，另一個是可能大家也很常聽到的打包工具 (bundler)。

這兩個詞之所以容易搞混，是因為在社群中頗熱門的選項 Webpack，最早從打包工具起家，後來逐漸進化成建構工具，所以 Webpack 在有些脈絡會被叫打包工具，在另一些脈絡被叫建構工具，因此可能讓人感到困惑。

另外，社群中也很熱門的 esbuild，名字當中有一個 build，但其本質會更貼近打包工具。事實上，esbuild 官網中的副標題就是 An extremely fast bundler for the web (一個為網頁而生的極速打包工具)。

所以建構工具與打包工具，兩者的區別究竟是什麼?

建構工具是完整的工具箱

要用比喻來說的話，建構工具就像一個完整的工具箱，裡面有各類的不同工具，而其中一個就是打包工具。以前端目前社群中最熱門的建構工具 Vite 來說，Vite 本身做很多事，其中的打包則是透過 esbuild 與 Rollup 來處理 (未來會改成由 Rolldown 處理)。

具體來說，打包工具在做的，是把多個不同的檔案，打包成最終被使用的結果。以目前社群最熱門的 React 來說，在一個大型的 React 程式碼庫，可能有上千個元件，與近百個頁面；但是當使用者進到某一個頁面時，不需要這整個程式碼庫中所有的程式碼，而打包工具做的事情，就是把這些上千個不同的檔案，處理成某幾個最佳化後的檔案，讓使用者進到頁面後，瀏覽器只需要下載那幾個優化過的檔案。

具體來說，打包工具會透過樹搖晃 (tree shaking)，把程式碼中冗餘的部分處理掉。例如有些程式碼庫中的程式碼，明明沒被用，但維護者自己沒把不用的程式碼移除，這時如果沒有移除，就等於白白佔空間。與此同時，打包工具也會做程式碼分割 (code splitting)，讓某個頁面，只加載該頁面會用到的程式碼，避免讓一堆用不到的程式碼被瀏覽器下載。

因此，概略上來看，打包就是先去釐清眾多的原始程式碼彼此的關係，然後去除不需要的程式碼 (樹搖晃)，然後把彼此相關的程式碼放在同一個包 (程式碼分割)，最後產出最佳化的包。

但是建構工具，除了打包外，還會做更多事。

以上面提到的 Vite，除了做上面這些 Rollup 會幫忙處理的事之外，還可以透過插件，在建構過程完成其他任務。舉例來說，假如今天在建構的過程中，如果想把專案中的圖片最佳化，Rollup 本身沒做這件事；但是在 Vite 可以透過 vite-plugin-image-optimizer 插件 (連結)，來優化讓圖片大小降低，這樣使用者進到頁面後，圖片能更快被加載出來。

又或者社群中另一個熱門的建構工具 Rsbuild，除了會用 Rspack 來打包外，還可以搭配 Rsdoctor 去分析建構後的產物，進一步協助團隊優化效能；這個額外的分析，就是 Rspack 這個打包工具本身沒有做的。

建構工具可以開箱即用

除了提供額外功能外，現代前端的建構工具，在開發者體驗 (DX) 上，還提供了額外的好處，其中最大的好處就是開箱即用。

在 Vite 成為最熱門的建構工具之前，Webpack 曾經是社群中最熱門的選項。前面有提到 Webpack 本身是打包起家，不過因為 Webpack 的加載器 (loader) 設計，讓 Webpack 可以掛載上許多不同的功能，逐漸地讓 Webpack 成為一個完整的建構工具。

但是 Webpack 之所以後來逐漸沒落，以及 Vite 之所以興起，其中的關鍵除了 Vite 的效能更好外，關鍵點還是開箱即用的開發者體驗。過去 Webpack 最為人詬病的就是配置的上手門檻很高，但是相對的 Vite 就把難配置的部分處理掉，讓新手也能快速入門。

除了 Vite 外，上面有提到的 Rsbuild 這個建構工具，當初之所以會被開發，是因為 Rspack 團隊想確保 Rspack 這個打包工具的底層穩定性，但這點意味著團隊不能隨著不同前端框架的演進去做大量修改，在這個前提下要做到讓開發者能開箱即用，會有一點困難。

因此，Rspack 團隊才又額外做了 Rsbuild 這個建構工具，底層是使用 Rspack，但與此同時在 Rsbuild 這層處理對各個框架的對接，讓各個框架的開發者，不需要煩惱配置的問題，能輕鬆開箱即用。

以上概略性地介紹了建構工具與打包工具的不同，在這篇文章的後半段，我們會著重在建構工具的討論；在這系列的下一篇文章，會更詳細來談打包工具。

前端程式碼一定要建構嗎?

在基本了解建構工具在做什麼後，相信大家可能會有個問題，那就是「前端程式碼一定要建構嗎?」。

顯然這個問題的回答是「不一定要」。舉例來說，下面這個 HTML 檔案，中間帶有一個 <script> 完全可以直接在瀏覽器上面跑。

<html>
  <head>
    <title>ExplainThis</title>
  </head>
  <body>
    <div id="root" />
    <script type="text/javascript">
      document.getElementById("root").innerText = "ExplainThis nicely!";
    </script>
  </body>
</html>

事實上，目前社群中仍是有人抱持反對使用建構工具的觀點。最有名的莫過於 Ruby on Rails 的作者 DHH。

在 DHH 的觀點中，因為現代瀏覽器足夠強大，即使不用建構工具，純粹的 HTML、CSS，搭配少許的 JavaScript，也能夠開發出足夠好的網頁應用程式。與此同時，因為不用建構工具，直接用最香草 (vanilla) 的方式，在開發完後，就能夠省去那些繁瑣的步驟，讓部署變得簡單輕鬆。

為什麼現代前端往建構的路線靠齊?

假如不用建構也可以在瀏覽器上面跑前端程式碼，且有 DHH 這般的主張，那為什麼現代前端還是往建構路線靠齊，且各類工具 (例如 Webpack、Vite、Rspack) 百花齊放?

最主要的原因是要兼顧開發者體驗 (DX)。

什麼意思呢? 假如去看目前業界多數前端團隊在開發時，幾乎不太有團隊用香草的 HTML、CSS 與 JavaScript (DHH 的團隊是非常特殊的例外)。

舉例來說，現代前端多數專案都會選用前端框架 (例如 React/Next、Vue/Nuxt、Svelte/SvelteKit)。另外，為了確保能在開發階段就先辨別出型別相關的問題，多數團隊會用 TypeScript。除此之外，為了在開發時，不用一直手動重新整理畫面，多數團隊會選擇用熱模組更新 (HMR) 的方式，改好某段程式碼，直接能反應不用手動重新整理。

但問題是，瀏覽器可以認得香草的 HTML、CSS 與 JavaScript ，但沒辦法直接處理 React 或 Vue 的程式碼，也沒辦法跑 TypeScript。與此同時，寫香草的 JavaScript 也不會自動獲得熱模組更新。甚至即使退一步，純粹寫 JavaScript，許多比較舊版本的瀏覽器，是沒有支援最新的 ECMAScript 語法；這會導致假如想用最新的語法寫 (因為這樣的開發者體驗比較好)，程式碼如果被用在舊一點的瀏覽器就會出問題。

而前端建構工具，就是用來解決上面這些問題的。透過建構工具中做的事情，讓開發者寫的 React/Vue、TypeScript、最新的 ECMAScript 語法，能被轉成任何瀏覽器都能支援的語法。因此會說，建構工具之所以必要，是因為現代前端開發要兼顧開發體驗，但寫出來的東西又要能跑在瀏覽器上，而建構工具就是兩者中間的橋樑。

如果更進一步說，前面談到的讓樹搖晃、程式碼分割等方式，能夠讓更少量的資料被傳到瀏覽器端，這不僅讓傳輸的速度變快，也會讓瀏覽器需要解析更少的程式碼，讓整體的速度提升。

綜上所述，不論從開發者體驗，或者從效能的角度看，建構工具都帶給現代前端專案非常大的幫助，這也是為什麼現代前端會往建構工具靠齊。