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上時可能不小心把.babelrcpostcss.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能解決上面提到的這些問題，我會毫不猶豫的在我的下一個項目中使用他。

---

在 Github 上討論

原文連接http://wuhaolin.cn/2017/12/27/Parcel%20Vs%20Webpack/