一開始學webpack其實有點逼不得已，作為乙個奉行保守主義的人，對於新東西都會有一種觀望的心態，這不是重點，我不會告訴你其實是因為我懶，真的是因為gulp在簡單的專案上已經足夠好用。
gulp本身只是乙個框架，通過安裝各種外掛程式，可以實現從監聽-打包-合併-壓縮-編譯一系列流程，管道的概念在使用的過程中跟它的前身grunt比起來簡直舒服太多。（其實我也沒怎麼用過grunt……真的不是我懶，是因為出生太晚，我開始接觸這類工具時gulp已經流行起來了）
然而，在開始實踐元件化開發之後，發現乙個有點邪乎的事情：gulp很難處理較為複雜的依賴關係，各元件之間相互引入，寫配置檔案時會寫得萬念俱灰。經常哭得把我家狗狗嚇出房間……
即便是乙個最簡單的專案，也需要做出如下的路徑配置：
並且，react、vue、angular2，這三大mvvm框架都將webpack作為官方推薦的打包工具，雖然還是有點懷念gulp，但不得不追隨神的指引——去跳webpack的坑。
webpack最早只是作為乙個打包工具出現，也就是只操作js**，但由於它智慧型尋找依賴的特點，很快外掛程式數量就直追而上，就功能而言，現在基本能夠完全取代gulp，加上基於express框架開發的webpack-dev-server，讓它有了比gulp家的browser-sync更讚的熱模組替換功能，browser-sync在監聽到**修改後會過載**並重新整理頁面，而webpack的熱模組替換可以做到在不重新整理頁面的情況下替換**。
你沒有聽錯，是在不重新整理頁面的情況下替換**。
上面說的webpack可以智慧型查詢依賴，是指：無論有多少個元件匯入，它會自己尋找到對應的元件並打包在一起，不需要使用者操心。
如果是gulp，則需要像上面那樣配置一大串路徑並且挨個注入監聽才行。（怎麼注入監聽，下面會有例子）
gulp最得意的莫過於管道式的工作方式，但webpack輕而易舉地就做到了，並且書寫起來更簡潔明瞭，例如乙個最普通的sass打包函式，gulp首先要匯入sass編譯模組，配置好輸入路徑和輸出路徑，還需要將這個函式注入到監聽的服務裡：
var sass = require('sass');
gulp.task('sass', function() );
這樣一來，很有可能引入一些冗餘的**或者一些靜態檔案，而且只能寄託命運讓你在某一天醍醐灌頂突然發現這張並沒有被引用。
造成這種隱患的原因是：gulp是根據路徑打包的，不管這個檔案有沒有用到，只要它的位置在gulp的處理序列內，它就會處理！而webpack的巧妙在於，被用到的它才打包，沒用到的則是視而不見！這就是按需打包的概念。
此外，還有一處事關體驗的地方，gulp一旦檢測到報錯資訊，就會退出，也就是你寫css**的時候多打了個分號，儘管眼睛看見了，然而身體的反射神經遲鈍，手不聽使喚按了儲存，世界就毀滅了！你只能嘆息一聲，乖乖把分號刪掉，然後回到終端（控制台）重啟gulp服務。
猜猜是誰已經做過無數次這種事……
而webpack會顯示報錯資訊，但是不會宕機，等你修正了錯誤之後，它會重新編譯。有追求的工具就應該這樣！！！
上面列出了gulp處理sass的**量，相對來說，webpack就簡單多了：
// 不過這麼寫的話，css最終會被打包到js檔案裡，如果想將css單獨打包出來，還需要安裝外掛程式，最終寫成下面這樣
const extracttextplugin = require("extract-text-webpack-plugin");
module.exports = )}]
},plugins: [
new extracttextplugin('./[name].css')]};
不！！以上看到的都是表面現象！！
不信來份真的比較一下！
var gulp = require('gulp');
var browsersync = require('browser-sync').create();
var sass = require('gulp-sass');
var prefix = require('gulp-autoprefixer');
var cssmin = require('gulp-clean-css');
var htmlmin = require('gulp-htmlmin');
var imagemin = require('gulp-imagemin');
var jsmin = require('gulp-uglify');
var rename = require('gulp-rename');
var reload = browsersync.reload;
var asset =
// 啟動靜態伺服器
gulp.task('server', function() );
});gulp.task('html', function() ))
.pipe(gulp.dest('dist/'));
});gulp.task('img', function() ))
.pipe(gulp.dest('dist/images/'));
});gulp.task('js', function() ))
.pipe(gulp.dest('dist/'));
});gulp.task('sass', function() ))
.pipe(cssmin())
.pipe(gulp.dest("dist/"))
.pipe(reload());
});gulp.task('watch', function() );
// 啟動
gulp.task('default', ['sass', 'img', 'html', 'js', 'server', 'watch']);
這裡說的注入跟angular的依賴注入概念基本一樣！注入這個概念理解起來可能比較困難，換乙個詞，應該叫反轉，概念是這樣的：一般的函式形參個數都……
呃……不跑題哈~
const path = require('path');
const extracttextplugin = require("extract-text-webpack-plugin");
const htmlwebpackplugin = require('html-webpack-plugin');
module.exports = ,
output: ,
module: )},,
]},plugins: [
new extracttextplugin('./[name].css'),
new htmlwebpackplugin()]};
呃……其實也就是半斤八兩，別天真了，成熟一點：少寫幾行**並不能體現出什麼優越性……
那麼從這裡開始，態度要轉彎了……
上面說了，檔案較多的時候，配置gulp的各種路徑會萬念俱灰，那麼……配置webpack的時候會比萬念俱灰更加萬念俱灰，跟webpack相比，gulp倒是顯得挺傻瓜。其實，單純比較**量的話，webpack配置檔案的**量確實是少些，然而webpack太過於博大精深，要理解它需要付出不少努力。
學了webpack是不是就能召喚神龍？
no！！經由webpack打包出來的**可讀性很差，儘管很少人會閒著沒事去讀打包後的**，但前端近幾年迭代太快，有人詬病就會有人創新，號稱下一代打包工具的rollup已經在崛起，它進一步公升級了「按需打包」的概念，只是各類外掛程式尚不成熟，因此就目前來看，將webpack用作應用層的打包還是最合適的。
等我跳了rollup的坑再來跟各位介紹~
表示層 應用層
表示層 功能 為異種機通訊提供一種公共語言，以便能進行互操作。這種型別的服務之所以需要，是因為不同的計算機體系結構使用的資料表示法不同。例如，ibm主機使用ebcdic編碼，而大部分pc機使用的是ascii碼。在這種情況下，便需要表示層來完成這種轉換。應用層 包含了通常要使用的協議 http協議 超...
應用層協議
應用層協議定義了執行在不同端系統上的應用程式程序如何相互傳遞訊息。特別是定義了 交換的訊息型別，如請求訊息和響應訊息。各種訊息型別的語法，如訊息中的各個字段及其詳細描述。欄位的語義，即包含在字段中的資訊的含義。程序何時 如何傳送訊息及對訊息進行響應的規則。有些應用層協議是由rfc文件定義的，因此它們...
應用層協議
dns 網域名稱解析協議 http 超文字傳輸協議 ftp 文字傳輸協議 tlent internet遠端登入服務的標準協議 smtp 簡單郵件傳輸協議 snmp 簡單網路管理協議 ssh 協議 加密的安全的連線 ftp 給予tcp文字傳輸的協議 tftp 基於udp，簡單檔案傳輸協議 1.網域名稱...