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

gulp 是 task runner，Webpack 是 module bundler。可以這么說， Webpack 和 gulp 本身都有 95% 的功能是不能被對方替代，或者直接說和對方不重疊的。

Gulp就像是一個產品的流水線，整個產品從無到有，都要受流水線的控制，在流水線上我們可以對產品進行管理

任務定義和組織；

基于文件 stream 的構建；

插件體系；

gulp適用于任何JavaScript的場合，就類似一個大的管理框架，其中的任務，與任務需要的工具都要手動去編寫與引入，對整體的一個把控

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

按照模塊的依賴構建目標文件；

loader 體系支持不同的模塊；

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

主要從以下方面對兩種框架做一下對比

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

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

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

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

Webpack則不是這樣管理資源的，它是根據模塊的依賴關系進行靜態分析，然后將這些模塊按照指定的規則生成對應的靜態資源(如下圖)。

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

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

Webpack 的核心就是模塊化地組織，模塊化地依賴，然后模塊化地打包。相對來上，場景局限在前端模塊化打包上；雖然用 gulp + 插件的方式也能實現，但目前看 Webpack 在依賴的模塊化構建上是無人能夠替代的。

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

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

然后Webpack進入該app.js文件進行解析，app.js

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

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

概念：其實就是利用CommonJS、AMD、CMD等方式對靜態資源文件進行引入管理，然后最終發布時達成相應的模塊依賴包，就是為了將代碼進行解耦合
先來看下gulp

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

然后通過編寫task命令對 文件進行css轉譯，js壓縮/轉譯，img，html壓縮等等操作

webpack目錄

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

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

gulp還沒嘗試過，不知道相關插件能否做到，不過webpack由于社區比較活躍，對應的可視化分析插件很多，其中一個就是

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

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

npm鏈接地址

運行后生成的相關圖形化分析張這樣，相當全面的顯示了各個包的情況，簡直不能太屌

其中相關引用：
鏈接描述
鏈接描述