為什麼前端這麼需要 Project Builder？

你覺得前端跟後端差異在哪？

前端只需要做畫面不需要做邏輯？

還是前端只需要碰瀏覽器不需要碰伺服器？

還是前端只要關心使用者看到的不需要關心使用者看不到的？

前端有超多邏輯，除了資料邏輯還有使用者的 UI 邏輯，量也絕對不會少。

前端現在 Server Site Render 流行，基本上伺服器一堆問題你也都要處理。

除了介面外，前端很需要花時間建構工具來維持專案品質。

前端跟後端的差別，其實只在服務的對象

這些就問題曾經我都有不同的答案，但最後我發現本質就是「軟體工程師」，沒有什麼你不需要學的東西。唯一的差別在，前端服務的是畫面呈現的一切和使用者操作的體驗，後端服務的是資料的儲存與提供和核心的商業邏輯。

那為什麼只有前端要又轉譯又打包？

但說回主題，為什麼前端需要這些工具？又要轉譯又要打包，各種預處理工具。後端都不需要這些麻煩的東西，基本上就是環境建置能跑程式語言和重要的工具程式就行，前端卻要搞那麼複雜？

從一支破萬行的 HTML 開始

早起前端運行方式就是寫「HTML」，把各種結構、樣式、程式通通塞在那個檔案，這時你會發現你的程式越寫越長，所以動輒破萬行程式碼的畫面就這樣誕生了。這時元件的概念誕生了，透過後端程式語言預先渲染，把不同的程式組裝起來變成 HTML，進而成為模板系統。

CSS 破萬行是基本的，所以有了預處理器

緊接著還有CSS的份量非常肥大、語法冗長的問題。不要講上萬行，CSS 破萬行根本就是「基本的」，你要找也是大海撈針，所以才有預處理器，如 sass, less, postcss。但CSS 也有全域污染的問題，你也很難去管理別人命名，所以才有 CSS Module系統。

上百張圖片與檔案，於是有了綑綁打包

還有資源的儲存，一個前端應用程式動輒上百張圖片，這些圖片的分類、路徑、資源管理都是問題，還有一堆 JavaScript 、CSS 的檔案，各種檔案造成資料夾肥大、分類不易，這時誕生了「綑綁打包」的概念。

前端就是一不小心檔案和專案就會變得「超級巨大」！所以就開始各種工具程式去拆分，組合又能自動化，讓開發者體驗更好。但隨著時間流逝和產品的成長，前端一直無法再去拆分，一樣是一個單頁應用程式在成長，專案就隨之巨大。

後端可以拆成微服務，前端拆不了

以後端來說，每個服務和工具都可以按照極小的單位去劃分，只要用網路或系統通道的方式就可以溝通，不需要強行劃分使用的框架、語言、工具，基本上都可以獨立佈署運行。所以後端是可以把元件獨立成一個服務，需要時動態配置，這就是微服務。

但前端大部分的東西是 UI，所以要能運行起來前提是先把元件讀進瀏覽器，然後才能把畫面與功能組裝起來。正因為這件事，所以前端很難做分散式部署，加上現在都是單頁式應用，所以大部分的情況一個畫面就是一整包的程式碼。

這些就是前端的問題與複雜性，要管理龐大的檔案、元件、專案變成前端開發很頭疼的問題。就因為這樣，許多前端工程師努力解決這些問題，因而產生了這些工具。隨之而來的就是讓人感到這些工具怎麼那麼多而複雜，一堆工具，有種學不完的錯覺。但也拜現在那麼多建置工具所賜，這件事其實也沒有那麼困擾，很多時候靠建置工作就省去搞各種設定。

今天廢話多了一點⋯⋯哈哈哈哈～