Javascript五十問——從源頭細說Webpack與Gulp

前言：Webpack 與 gulp是目前圈子內比較活躍的前端構建工具。網上有不少兩者比較的文章，面試中也會常常遇到 gulp，Webpack的區別這樣的問題。對於初學者來講，對這兩者每每容易認識不清，今天，就從事件的源頭，說清楚Webpack與gulp。

Gulp

那是2014年，雖然JQuery風光多年，可是前端卻暗流涌動；MVVM剛剛提出不久，Angular快速成長，而React和Vue也剛剛開源不到一年，尚屬於冷門小語種。那個時候，前端工做者面臨的主要矛盾在於日益增加的業務複雜化的需求同落後低效率的前端部署。開發工做者爲了發佈一個網站，每每會重複的進行一些與開發無關的工做，手動完成這些工做會帶來很大的挫敗感。這個時候，自動化構建工具及應運而生，gulp就是在大浪淘沙中的勝利者。

Gulp是基於流的前端構建工具，nodejs的stream操做來讀取和操做數據；能夠實現文件的轉換，壓縮，合併，監聽，自動部署等功能。gulp擁有強大的插件庫，基本上知足開發需求，並且開發人員也能夠根據本身的需求開發自定義插件。可貴是，gulp只有五個api，容易上手。

const gulp = require('gulp');
const sass = require("gulp-sass")

gulp.task("sassStyle",function() {
    gulp.src("style/*.scss")
        .pipe(sass())
        .pipe(gulp.dest("style"))
})

上面就是一個基本的gulpfile配置文件，實現了scss文件到css文件的轉換；在終端輸入gulp sassStyle就可以進行文件處理了。
對於gulp而言，會有一個task，這個task只會作一件事，好比將sass格式的文檔轉換成css文件；對於一個task而言，會有一個入口文件，即gulp.src，最會有一個目標文件，即gulp.dest；一入一出，能夠將gulp理解爲 一元函數，輸入一個x，根據funcion產出一個y。

Gulp簡單，快速，自動化的構建方案，收穫了不少開發者的喜好。可是怎樣的機遇，讓webpack佔據了前端工程化的半壁江山呢？

Webpack

解決方案永遠是緊跟需求的腳步的。隨着React與Vue份額愈來愈大，spa開發模式應用在愈來愈多的領域中，而ES6 Module語法的提出與大規模應用，模塊化開發方式愈來愈受人們的青睞。導致前端文件之間的依賴性愈來愈高，這時候就須要一個工具可以解析這些依賴，而且將它們有條理的打包起來，優化請求，最好順便可以解析成瀏覽器能夠識別的語言——這正是webpack所承擔的工做;而不少開發者，也是從react或者vue的項目入手webpack的。

圖片來源於互聯網，侵刪

Webpack 是前端資源模塊化 管理和打包工具。它能夠將許多鬆散的模塊按照依賴和規則打包成符合生產環境部署的前端資源。還能夠將按需加載的模塊進行代碼分割，等到實際須要的時候再異步加載——來自Webpack官方網站。
因此Webpack只完成兩件事：按需加載，打包。

module.exports = {
  // 入口文件，是模塊構建的起點，同時每個入口文件對應最後生成的一個 chunk。
  entry: {
    bundle: [
      'webpack/hot/dev-server',
      'webpack-dev-server/client?http://localhost:8080',
      path.resolve(__dirname, 'app/app.js')
    ]
  },
  // 文件路徑指向(可加快打包過程)。
  resolve: {
    alias: {
      'react': pathToReact
    }
  },
  // 生成文件，是模塊構建的終點，包括輸出文件與輸出路徑。
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: '[name].js'
  },
  // 這裏配置了處理各模塊的 loader ，包括 css 預處理 loader ，es6 編譯 loader，圖片處理 loader。
  module: {
    loaders: [
      {
        test: /\.js$/,
        loader: 'babel',
        query: {
          presets: ['es2015', 'react']
        }
      }
    ],
    noParse: [pathToReact]
  },
  // webpack 各插件對象，在 webpack 的事件流中執行對應的方法。
  plugins: [
    new webpack.HotModuleReplacementPlugin()
  ]
};

上面是比較簡單的webpack配置文件 webpack.config.js,若是說gulp是一個一元函數，那麼，webpack就是一個多元函數或者是加工廠；webpack從入口文件開始，遞歸找出全部依賴的代碼塊，再將代碼塊按照loader解析成新內容，而在webpack會在各個特定的時期廣播對應事件，插件會監聽這些事件，在某個事件中進行特定的操做。通俗一點來講，webpack自己來遞歸找到各個文件之間的依賴關係，在這個過程當中，使用loaders對文件進行解析，最後，在各個不一樣的事件階段，插件能夠對文件進行一個統一的處理。

webpack.config文件會包括如下幾部分：

1.entry:入口，webpack問此文件入手迭代。
2.output: 打包後造成的文件出口。
3.module: 模塊，在webpack中一個模塊對應一個文件。webpack會從entry開始，遞歸找出全部依賴的模塊
4.loaders:文件解析的各類轉換器
5.plugin:拓展插件

webpack的配置文件和構建方式比較複雜，這裏再也不贅述，感興趣的同窗能夠參考我列出來的參考文獻第三篇文章，或者能夠關注個人專欄，後期我會出一篇關於webpack的學習筆記。

比較

因此，咱們能夠看出來，雖然Webpack與gulp都是前端工程化的管理工具，可是兩者的側重點不一樣——gulp更加關注的是自動化的構建工具，你把代碼寫好了，gulp會幫你編譯、壓縮、解析。而Webpack關注的是在模塊化背景下的打包工做；它側重的仍是如何將依賴的文件合理的組織起來，而且實現按需加載。

總結

總的來講，雖然webpack以打包起家，可是gulp可以實現的功能，Webpack也能作；那麼，是否是咱們之後都要惟webpack馬首是瞻呢？非也，非也！webpack功能強大，可是它的缺點也來自於此；webpack並不是一個輕量級的工具，學習曲線也非gulp那般平緩。曾經，gulp爲了彌補js打包方面的不足，也有gulp-webpack插件的出現；可是webpack強大如斯，若是僅僅只是解析es6文件，未免有大馬拉小車之感。
根據個人項目實踐經驗，若是你要構建一個複雜的項目，項目使用vue或者react，模塊化引領，那麼請選擇Webpack，Webpack天生模塊化，更加適合於SPA的應用場景，而gulp在SPA下明顯後力不足。若是你只是開發一個工具，請選擇gulp，至於js打包這種工做，有更加專注的rollup。畢竟，若是隻是寫一個年會抽獎工具活躍氣氛，就不須要webpack火種送碳了。

總結下來：gulp與Webapck是各有所長，並不存在東風壓倒西風，而在前端工程化的大旗下，並不是只有Webpack與gulp，咱們還能看到rollup與browserify的一席之地。所以，在真正的工做中，仍是要結合項目自己特色，切忌人云亦云。

參考文獻

一、JavaScript開發者的工具箱 很是實用
二、Gulp官網
三、超級詳細的Webpack解讀—五星推薦
四、端構建工具之爭——Webpack vs Gulp 誰會被拍死在沙灘上—五星推薦