gulp 的定位是 task runner, 就是用來跑乙個乙個任務的。
放在以前比如我想用sass寫css, coffee寫js, 我必須手動的用相應的compiler去編譯各自的檔案，然後各自minify。這時候designer給你了兩張新，好嘞，接著用自己的小工具手動去壓縮。
後來前端人不能忍了，搞出個自動化這個流程的 grunt/gulp, 比如你寫完**後要想發布production版本，用一句gulp build就可以
rm掉 dist資料夾中以前的舊檔案
自動把sass編譯成css, coffee編譯成js
壓縮各自的檔案，壓縮，生成sprite
拷貝minified/uglified 檔案到 dist 資料夾
但是它沒發解決的是 js module 的問題，是你寫**時候如何組織**結構的問題.
之前大家可以用 require.js, sea.js 來 require dependency, 後來出了乙個 webpack 說 我們能不能把所有的檔案(css, image, js) 都用 js 來 生成依賴，最後生成乙個bundle呢？ 所以webpack 也叫做file bundler.
同時 webpack 為了解決可以 require 不同檔案的需求引入了loader, 比如面對sass檔案有
sass-loader, 把sass 轉換成 css
css-loader, 讓 webpack 能識別處理 css
style-loader, 把識別後的 css 插入到 html style中
類似的識別es6 有babel-loader
本來這就是 webpack 的初衷，require everything, bundle everything. 一開始 webpack 剛出來的時候大家都是把它結合著 gulp 一起用的， gulp 裡面有個 gulp-webpack，就是讓 webpack 專門去做module dependency的事情, 生成乙個bundle.js檔案，然後再用 gulp 去做一些其他雜七雜八minify, uglify的事情。 後來人們發現 webpack 有個plugins的選項， 可以用來進一步處理經過loader 生成的bundle.js，於是有人寫了對應的外掛程式， 所以minify/uglify, 生成hash的工作也可以轉移到webpack本身了，擠掉了gulp這部分的市場份額。 再後來大家有發現 npm/package.json 裡面的scripts 原來好好用啊，呼叫任務的時候就直接寫乙個簡單的命令，因為 gulp 也不就是各種外掛程式命令的組合呀，大部分情況下越來越不需要 gulp/grunt 之類的了 ref. 所以你現在看到的很多新專案都是package.json裡面scripts 寫了一堆，外部只需要乙個webpack就夠了。
所以 lz 一開始就模仿其他專案用 npm scripts + webpack 就好了，當你發現有哪些任務你沒法用 webpack 或者npm scripts 解決起來麻煩， 這個時候再引入task runner 也不遲
gulp與webpack的區別
常有人拿gulp與webpack來比較，知道這兩個構建工具功能上有重疊的地方，可單用，也可一起用，但本質的區別就沒有那麼清晰。gulp gulp強調的是前端開發的工作流程，我們可以通過配置一系列的task，定義task處理的事務 例如檔案壓縮合併 雪碧圖 啟動server 版本控制等 然後定義執行順...
gulp與webpack的區別
常有人拿gulp與webpack來比較，知道這兩個構建工具功能上有重疊的地方，可單用，也可一起用，但本質的區別就沒有那麼清晰。gulp gulp強調的是前端開發的工作流程，我們可以通過配置一系列的task，定義task處理的事務 例如檔案壓縮合併 雪碧圖 啟動server 版本控制等 然後定義執行順...
webpack與gulp的區別
gulp 強調的是前端開發的流程，通過配置一系列的task，定義task處理的事務 例如 檔案壓縮合併，啟動server 然後定義執行順序，來讓gulp執行task，從而構建其前端專案的流程。合併後仍然是你寫的 只是區域性變數名被替換，一些語法做了轉換而已，整體內容並沒有發生改變。webpack 側...