我為什麼要使用Webpack?

簡單講講我與前端的故事吧。

剛接觸前端時，所有靜态資源CSS、圖檔和JS都是手動引入HTML頁面中，這并沒有什麼不好，想要什麼就引入什麼嘛。另外，所見即所得，開發好的項目檔案直接就可以上傳伺服器，很友善，是以這樣的開發方式一直持續到前不久，也就是開始正式使用Webpack之前。

漸漸地，我開始感覺到jQuery雖然很好用，但是維護起來不是很友善，就是所謂的開發一時爽，維護起來真要命。雜亂無章的代碼混在一個檔案中，想要尋找某個功能的代碼很是困難，要是分開成多個檔案引入，又會造成HTTP請求數過多的問題。

于是，我後來選擇了Vue。

使用Vue之後的一個好處就是，我不再需要手動去操作DOM了，直接可以将JS變量放到HTML頁面中，資料會自動綁定，這對于開發者來說非常友善，我們隻需要把重點放到對資料的處理上就可以了，這樣代碼也精簡了很多。

再後來，我發現有些代碼在很多地方都要用到，同一個項目中，JS我可以通過定義方法來複用，CSS可以通過定義類名來複用，可是對于HTML，我卻無能為力，隻能通過複制粘貼的方式……

是以，我選擇了Vue元件。

但是問題接着又來了，我發現Vue元件雖然解決了HTML的複用問題，但實際上隻不過是将HTML和JS組合在了一起，CSS依然遊離在外，在同一項目中确實都實作了複用，但是當其他項目要使用它時，還得把遊離在外的CSS代碼複制粘貼過去，這樣久而久之自然也是難以忍受了。

幸運的是，單檔案的Vue元件正好解決了這個問題。我們可以将HTML、CSS和JavaScript代碼放在同一個.vue檔案當中，強大的Webpack可以将這些代碼分離出來，并分别與其他同類型的代碼打包到一起。而我們不需要管Webpack内部是如何運作的，隻需要知道單檔案元件形式确實會為我們的工作帶來極大的便利性。

在CSS方面，習慣使用Less來寫CSS代碼的我，明顯體會到Less子產品化所帶來的便利性，一個Less檔案可以通過引入其他多個Less檔案，最後隻需将這一個Less檔案所編譯成的CSS檔案引入頁面即可。之前我使用的Less編譯工具一直都是koala，它是一個可視化的編譯軟體，可以進行Less代碼的編譯以及CSS和JS代碼的壓縮。正因為Less很好用，并且節省了HTTP請求數，然後我就在想，要是JS也能像Less一樣子產品化引入并且打包成一個JS檔案就好了。

正因為有着元件化、子產品化和單檔案引入的強烈需求，我開始嘗試尋找着同時具備這些功能的打包工具，而在嘗試過Grunt、Gulp、Webpack和Parcel之後，最終我選擇了Webpack。

那麼，為什麼我會在這些工具中最終選擇Webpack呢？

首先，Grunt和Gulp隻能算是建構工具，就是将一些CSS和JS檔案分别壓縮合并成單個檔案，當然也具有一些編譯功能，比如Less和Sass的編譯、ES6到ES5的編譯等等。但是Webpack不僅具有它們所具備的這些編譯壓縮合并功能，同時還具備子產品化開發群組件式開發等優點，在目前流行的前端架構React和Vue中也得到很好的支援。

然後再說說Parcel，它一度被人認為是未來最有可能替代Webpack的前端打包工具，主要原因是它幾乎零配置，而且打包入口也不僅僅隻是JS，另外其打包速度也要比Webpack快。然而，雖然Parcel相比Webpack似乎具有更多優勢，但它畢竟還不夠成熟，沒有Webpack龐大的社群，一旦遇到問題很難在網上快速找到相應解決辦法。并且最近Webpack 4.0已經釋出，配置相比之前簡化了一些，也增加了一些新功能，是以我們完全有理由相信Webpack在未來也會越來越好。

是以，在經過一番體驗和對比之後，最終我選擇了Webpack。

最後總結一下Webpack的主要優勢：

① 子產品化開發（import，require）

② 預處理（Less，Sass，ES6，TypeScript……）

③ 主流架構腳手架支援（Vue，React，Angular）

④ 龐大的社群（資源豐富，降低學習成本）

初識Webpack，如有不對之處，歡迎指正，也歡迎一起學習，一同進步！