Parcel Vs Webpack

愛折騰的前端圈時常會有新輪子誕生，只要是好東西就能快速得到大量關注，資歷再好的大哥只要不如新人也很快會被替代。

橫空出世的 Parcel 近日成爲了前端圈的又一大熱點，在短短几周內就得到了 13K 的 Star。

做爲前端構建工具新人的 Parcel 爲何能在短時間內得到這麼多贊同？他和老大哥 Webpack 比起來到底有什麼優點呢？

我花了 6 個月的時間寫了一本全面介紹 Webpack 的圖書《深刻淺出 Webpack》近日剛出版，感受被新出的Parcel給腰斬了。

但本文將本着公平公正的心態來詳細對比一下他兩，讓你能明白他們直接的異同和優缺點對比，好決定是選 Parcel 仍是 Webpack。

爲了對比他兩，咱們從實際出發舉一個實戰項目爲例子，分別用 Parcel 和 Webpack 去實現，實戰項目要求以下：

• 項目採用TypeScript + React + SCSS；
• 項目採用了 Antd UI 組件庫，但要作到按需加載只用到了的組件，而不是全部組件都打包進去；
• 項目使用了 Lodash 庫，用於檢查構建是否有剔除無用代碼的能力( TreeShaking )；
• 構建須要支持模塊熱替換功能，以提升開發效率；
• 支持 SourceMap ，以方便調試；
• 對比他們的首次啓動速度和監聽變化時的構建速度；
• 在生成環境下須要壓縮 JS、CSS，CSS 須要提取到單獨到文件，並對比他們在生產環境下構建出文件大小；
• 須要生成自動會加載對應資源的 HTML 文件；

Parcel 讓人眼前一亮

在用了好久 Webpack 後用 Parcel 的感受就像用了好久 Android 機後用 iPhone，不用再去操心細節和配置，大多數時候 Parcel 剛剛夠用並且用的很舒服。

用 Parcel 去完成以上項目的要求，我只是專心去寫項目頁面所必須的代碼，Parcel 智能快速的幫我構建出了能正常運行的結果。

如下是 Parcel 讓我心動的點：

• Parcel 能作到無配置完成以上項目構建要求；
• Parcel 內置了常見場景的構建方案及其依賴，無需再安裝各類依賴；
• Parcel 能以 HTML 爲入口，自動檢測和打包依賴資源；
• Parcel 默認支持模塊熱替換，真正的開箱即用；

而反觀 Webpack，比 Parcel 要麻煩不少：

• 須要寫一堆配置；
• 須要再安裝一堆依賴；
• 不能簡單的自動生成 HTML；

這個項目我用 Parcel 時花在構建配置上的時間不到一分鐘，而用 Webpack 構建時花了 5 分鐘去配置。

Parcel 還須要時間去打磨

經過以上項目實踐，發現 Parcel 目前有以下明顯的缺點：

• 不支持 SourceMap ：在開發模式下，Parcel 也不會輸出 SourceMap，目前只能去調試可讀性極低的代碼；
• 不支持剔除無效代碼 ( TreeShaking )：不少時候咱們只用到了庫中的一個函數，結果 Parcel 把整個庫都打包了進來；
• 一些依賴會 讓Parcel 出錯：當你的項目依賴了一些 Npm 上的模塊時，有些 Npm 模塊會讓 Parcel 運行錯誤；

Parcel 須要爲零配置付出代價

零配置實際上是把各類常見的場景作爲默認值來實現的，這雖然能節省不少工做量，快速上手，但這同時會帶來一些問題：

• 不守規矩的 node_module ：有些依賴的庫在發佈到 Npm 上時可能不當心把.babelrc postcss.config.js tsconfig.json這些配置文件也一塊兒發佈上去了

因爲目前 Parcel 只要在目錄中發現這些配置文件就會認爲該項目中的代碼須要被處理。例如 mini-store 這個庫中就把.babelrc文件發佈到了 Npm 上，項目依賴的原本是 lib 中已經編譯成了 ES5 的 JS 代碼了，但 Parcel 還會去用 Babel 處理一遍。

Npm官方並無規定發佈到 Npm 上的包須要符合哪些規範，這會讓 Parcel 很爲難。

• 不靈活的配置：零配置的 Parcel 關閉了不少配置項，在一些須要的配置的場景下沒法改變。例如：

  • 沒法控制對部分文件的特殊處理，以實現諸如按需加載這樣的需求；
  • 沒法控制輸出文件名的 Hash 值和名稱；
  • 沒法控制構建輸出目錄結構；
  • 沒法映射路徑以縮短導入語句；
  • HTTP 開發服務器不支持 HistoryApi ；

Parcel 使用場景受限

目前 Parcel 只能用來構建用於運行在瀏覽器中的網頁，這也是他的出發點和專一點。

在軟件行業不可能存在即便用簡單又能夠適應各類場景的方案，就算所謂的人工智能也許能解決這個問題，但人工智能不能保證 100% 的正確性。

反觀 Webpack 除了用於構建網頁，還能夠作：

• 打包發佈到 Npm 上的庫
• 構建 Node.js 應用 ( 同構應用 )
• 構建 Electron 應用
• 構建離線應用 ( ServiceWorkers )

構建速度和輸出文件大小對比

分別去用 Parcel 和 Webpack 構建以上項目，收集的數據以下：

數據項	Parcel	Webpack
生成環境構建時間	8.310s	9.58s
開發環境啓動時間	5.42s	8.06s
監聽變化構建時間	3.17s	2.87s
生成環境輸出 JS 文件大小	544K	274K
生成環境輸出 CSS 文件大小	23K	23K

從以上數據能夠看出： Parcel 構建速度快，但 Parcel 輸出文件大

致使 Parcel 構建速度快的緣由和 iOS 比 Android 用起來更流暢的緣由相似：

• Parcel 由於一體化內置，因此集成和優化的更好，而 Webpack 經過插件和 Loader 機制去讓第三方擴展這會拉低性能；
• Parcel 內置多進程並行構建，而 Webpack 默認是單進程構建 ( Webpack 也支持多進程 )；

致使 Parcel 輸出 JS 文件大的緣由在於：

• 不支持 TreeShaking
• 構建出的 JS 中出現了全部文件的名稱，如圖：
  

以上 項目完整源碼可下載

總結

現階段的 Parcel 就像 beta 版的 iPhone，看上去很美好但還不能用於生成環境，若是你如今就把 Parcel 用於生成環境，相信我你必定會踩不少坑。

踩坑沒關係，要命的是沒法在網上找到解決方法以快速解決問題。

我不是不鼓勵你們使用 Parcel，歷史總須要先驅去推進，就像喬布斯義無反顧的引領了一個時代，咱們也須要去實踐 Parcel，坑都是一個個填平的，因此我鼓勵你們在一些我的小項目中使用 Parcel。

若是 Parcel 能解決上面提到的這些問題，我會堅決果斷的在個人下一個項目中使用他。

閱讀原文