Parcel Vs Webpack

AD：美團成都研發中心正在招聘大量 Web 前端、iOS、Android、Java 後端、QA，技術牛、待遇好、發展前景大、生活溫馨，有意者請郵件 gwuhaolin@icloud.com

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

橫空出世的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能解決上面提到的這些問題，我會堅決果斷的在個人下一個項目中使用他。

閱讀原文