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要麻煩很多：
這個專案我用Parcel時花在構建配置上的時間不到一分鐘，而用Webpack構建時花了5分鐘去配置。
Parcel還需要時間去打磨
通過以上專案實踐，發現Parcel目前有如下明顯的缺點：
- 不支援SourceMap：在開發模式下，Parcel也不會輸出SourceMap，目前只能去除錯可讀性極低的程式碼；
- 不支援剔除無效程式碼(TreeShaking)：很多時候我們只用到了庫中的一個函式，結果Parcel把整個庫都打包了進來；
- 一些依賴會讓Parcel出錯：當你的專案依賴了一些Npm上的模組時，有些Npm模組會讓Parcel執行錯誤；
Parcel需要為零配置付出代價
零配置其實是把各種常見的場景做為預設值來實現的，這雖然能節省很多工作量，快速上手，但這同時會帶來一些問題：
- 不守規矩的node_module：有些依賴的庫在釋出到Npm上時可能不小心把
.babelrcpostcss.config.jstsconfig.json這些配置檔案也一起釋出上去了， 由於目前Parcel只要在目錄中發現這些配置檔案就會認為該專案中的程式碼需要被處理。例如mini-store這個庫中就把.babelrc檔案釋出到了Npm上，專案依賴的本來是lib中已經編譯成了ES5的JS程式碼了，但Parcel還會去用Babel處理一遍。 Npm官方並沒有規定釋出到Npm上的包需要符合哪些規範，這會讓Parcel很為難。 - 不靈活的配置：零配置的Parcel關閉了很多配置項，在一些需要的配置的場景下無法改變。例如：
- 無法控制對部分檔案的特殊處理，以實現諸如按需載入這樣的需求；
- 無法控制輸出檔名的Hash值和名稱；
- 無法控制構建輸出目錄結構；
- 無法對映路徑以縮短匯入語句；
- HTTP開發伺服器不支援HistoryApi；
Parcel使用場景受限
目前Parcel只能用來構建用於執行在瀏覽器中的網頁，這也是他的出發點和專注點。 在軟體行業不可能存在即使用簡單又可以適應各種場景的方案，就算所謂的人工智慧也許能解決這個問題，但人工智慧不能保證100%的正確性。
反觀Webpack除了用於構建網頁，還可以做：
構建速度和輸出檔案大小對比
分別去用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能解決上面提到的這些問題，我會毫不猶豫的在我的下一個專案中使用他。