摘要：是通過加載器和插件對(duì)資源進(jìn)行處理的。另外我們知道是對(duì)整個(gè)過程進(jìn)行控制，所以在其配置文件中配置的每一個(gè)對(duì)項(xiàng)目中該配置路徑下所有的資源都可以管理。

gulp 是 task runner，Webpack 是 module bundler?？梢赃@么說， Webpack 和 gulp 本身都有 95% 的功能是不能被對(duì)方替代，或者直接說和對(duì)方不重疊的。

Gulp就像是一個(gè)產(chǎn)品的流水線，整個(gè)產(chǎn)品從無到有，都要受流水線的控制，在流水線上我們可以對(duì)產(chǎn)品進(jìn)行管理

任務(wù)定義和組織；

基于文件 stream 的構(gòu)建；

插件體系；

gulp適用于任何JavaScript的場(chǎng)合，就類似一個(gè)大的管理框架，其中的任務(wù)，與任務(wù)需要的工具都要手動(dòng)去編寫與引入，對(duì)整體的一個(gè)把控

Webpack類似于一個(gè)模塊打包機(jī) 可以將許多松散的模塊按照依賴和規(guī)則打包成符合生產(chǎn)環(huán)境部署的前端資源。體現(xiàn)出的意義就是：一切皆模塊 通過 loader的轉(zhuǎn)換，任何形式的資源都可以視作模塊，比如 CommonJs 模塊、AMD 模塊、ES6 模塊、CSS、圖片、JSON、Coffeescript、LESS 等。

按照模塊的依賴構(gòu)建目標(biāo)文件；

loader 體系支持不同的模塊；

插件體系提供更多額外的功能；

主要從以下方面對(duì)兩種框架做一下對(duì)比

Gulp側(cè)重于前端開發(fā)的整個(gè)過程的控制管理（像是流水線），我們可以通過給gulp配置不通的task（通過Gulp中的gulp.task()方法配置，比如啟動(dòng)server、sass/less預(yù)編譯、文件的合并壓縮等等）來讓gulp實(shí)現(xiàn)不同的功能，從而構(gòu)建整個(gè)前端開發(fā)流程。

Webpack有人也稱之為模塊打包機(jī)，由此也可以看出Webpack更側(cè)重于模塊打包，當(dāng)然我們可以把開發(fā)中的所有資源（圖片、js文件、css文件等）都可以看成模塊，最初Webpack本身就是為前端JS代碼打包而設(shè)計(jì)的，后來被擴(kuò)展到其他資源的打包處理。Webpack是通過loader（加載器）和plugins（插件）對(duì)資源進(jìn)行處理的。

另外我們知道Gulp是對(duì)整個(gè)過程進(jìn)行控制，所以在其配置文件（gulpfile.js）中配置的每一個(gè)task對(duì)項(xiàng)目中該task配置路徑下所有的資源都可以管理。
比如，對(duì)sass文件進(jìn)行預(yù)編譯的task可以對(duì)其配置路徑下的所有sass文件進(jìn)行預(yù)編譯處理：

gulp.task("sass",function(){
    gulp.src("src/styles/*.scss")
    .pipe(sass().on("error",sass.logError))
    .pipe(gulp.dest("./build/prd/styles/"));//編譯后的輸出路徑
});

Webpack則不是這樣管理資源的，它是根據(jù)模塊的依賴關(guān)系進(jìn)行靜態(tài)分析，然后將這些模塊按照指定的規(guī)則生成對(duì)應(yīng)的靜態(tài)資源(如下圖)。

需要把各種資源（js/ts/css/html/ejs/img/fonts等等）都看成 module；

module之間必須是互相依賴的，在 js 里 import 模板、圖片、樣式文件等等，樣式文件通過 url()和圖片字體關(guān)聯(lián)；這種依賴關(guān)系必須是 webpack 既定的或者是通過插件可以理解的關(guān)系。

Webpack 的核心就是模塊化地組織，模塊化地依賴，然后模塊化地打包。相對(duì)來上，場(chǎng)景局限在前端模塊化打包上；雖然用 gulp + 插件的方式也能實(shí)現(xiàn)，但目前看 Webpack 在依賴的模塊化構(gòu)建上是無人能夠替代的。

通俗的說，Webpack就是需要通過其配置文件（webpack.config.js）中entry配置的一個(gè)入口文件（JS文件）

 entry: {
      app:__dirname + "/src/scripts/app.js",
}

然后Webpack進(jìn)入該app.js文件進(jìn)行解析，app.js

//引入scss文件
   import "../style/app.scss";
    
   //引入依賴模塊
   var greeter = require("./Greeter.js");
   document.getElementById("root").appendChild(greeter());

解析過程中，發(fā)現(xiàn)一個(gè)app.scss文件，然后根據(jù)webpack.config.js配置文件中的module.loaders屬性去查找處理.scss文件的loader進(jìn)行處理，處理app.scss文件過程中，如果發(fā)現(xiàn)該文件還有其他依賴文件，則繼續(xù)處理app.scss文件的依賴文件，直至處理完成該“鏈路”上的依賴文件，然后又遇到一個(gè)Greeter.js模塊，于是像之前一樣繼續(xù)去查找對(duì)應(yīng)的loader去處理...
所以，Webpack中對(duì)資源文件的處理是通過入口文件產(chǎn)生的依賴形成的，不會(huì)像Gulp那樣，配置好路徑后，該路徑下所有規(guī)定的文件都會(huì)受影響。

概念：其實(shí)就是利用CommonJS、AMD、CMD等方式對(duì)靜態(tài)資源文件進(jìn)行引入管理，然后最終發(fā)布時(shí)達(dá)成相應(yīng)的模塊依賴包，就是為了將代碼進(jìn)行解耦合
先來看下gulp

Gulp
   |——dist:  項(xiàng)目輸出路徑
   |    |——module:  開發(fā)模塊（遵循就近依賴原則）
   |        |——index: 首頁(yè)模塊
   |        |——my: 我的模塊
   |——commons:  公用靜態(tài)文件
   |——src: 工作目錄
   |    |——module:  開發(fā)模塊（遵循就近依賴原則）
   |        |——index: 首頁(yè)模塊
   |            |——action_.js: 開發(fā)js（es6語法）
   |            |——**.scss: sass模板語言
   |            |——vue**.js: vue模板
   |        |——my: 我的模塊
   |——gulpfile.js: gulp的配置文件
   |——index.html: 主頁(yè)html文件
   |——package.json: npm包管理配置文件

然后通過編寫task命令對(duì) 文件進(jìn)行css轉(zhuǎn)譯，js壓縮/轉(zhuǎn)譯，img，html壓縮等等操作

webpack目錄

主要對(duì)entry入口文件中所有的依賴以及后續(xù)依賴進(jìn)行分析，對(duì)公共文件進(jìn)行抽取分離壓縮打包

gulp中大部分靜態(tài)文件都是已經(jīng)標(biāo)簽化插入好的（如果js文件中使用import和require的es6語法，打包還要另外加入插件plugin和browserify，與其這樣像webpack靠攏不如直接拿來webpack配置各司其職，相互配合，這也是一種gulp+webpack的模式）
webpack 可以隨用隨插，按需加載（gulp中目前我使用的是require--采用強(qiáng)依賴模式已經(jīng)把需要的模塊提前注入好了）和打包
所以就方便程度和學(xué)習(xí)成本來說，webpack更勝一籌

gulp還沒嘗試過，不知道相關(guān)插件能否做到，不過webpack由于社區(qū)比較活躍，對(duì)應(yīng)的可視化分析插件很多，其中一個(gè)就是

npm install --save-dev webpack-bundle-analyzer

var BundleAnalyzerPlugin = require("webpack-bundle-analyzer").BundleAnalyzerPlugin;
 
// ...
plugins: [new BundleAnalyzerPlugin()]
// ...

npm鏈接地址

運(yùn)行后生成的相關(guān)圖形化分析張這樣，相當(dāng)全面的顯示了各個(gè)包的情況，簡(jiǎn)直不能太屌

其中相關(guān)引用：
鏈接描述
鏈接描述