前端構建工具 Gulp / browserify/ webpack / npm ?

01-05

現在前端的構建工具好多，感覺Gulp / Grunt 是一類，Browserify是一類，感覺 webpack像是Browserify又加上了Gulp的功能。
這兩天看 Vue ，看到 vuejs/vue-browserify-example · GitHub 和 vuejs/vue-webpack-example · GitHub 中都是用 npm run 的方式構建項目。沒有 Gulp 的影子。是不是現在Gulp也不適合時代了？或者說 npm + webpack 的方式完全可以代替 Gulp呢

簡單的說，Grunt / Gulp 和 browserify / webpack 不是一回事。

1）Gulp / Grunt 可以理解為幫助前端自動化的工具，用於優化前端工作流程。比如自動刷新頁面、combo、壓縮css、js、編譯less等等。二者的區別可以自行百度，個人推薦Gulp。

2）browserify / webpack 提供的是一個前端模塊化的方案，和requirejs類似但又有不同。

requirejs是一種在線"編譯" 模塊的方案，相當於在頁面上載入一個AMD 解釋器，以便於覽器能夠識別 define、exports、module，而這些東西就是用於模塊化的關鍵。

而browserify / webpack，則是一個預編譯模塊的方案。它是預編譯的，不需要在瀏覽器中載入解釋器。

因此完全可以gulp+webpack 或者gulp+browserify這樣的方式搭配使用，甚至，只使用webpack，由於其強大的插件支持，也能滿足絕大多數需求了。

叫什麼不重要，重要的是你要知道它能做什麼。

大致說一下，（如有誤望指正）：

- node , 是javascript語言的環境和平台，

- npm , bower, yarn 是一類，包管理，

- webpack , browserify , rollup, babel 是一類，javascript模塊編譯打包方案(工具+插件)，

- requirejs , seajs , 是一類, 基於commonjs，amd，cmd，umd 之類的模塊類包載入方案的框架，

- grunt , gulp , 前端工具，合併、壓縮、編譯 sass/less，browser 自動載入資源，

- react , angular , vue , backbone , 是一類，mvc , mvvm , mvp 之類的前端框架，

- jquery , zepto , prototype , 是一類，前端 DOM , BOM 類庫，

- ext , yui , kissy , dojo , 是一類，前端應用組件，

- lodash , underscore , 函數式編程庫。

然後，找喜歡的上。

另：

在wappalyzer可以看到web項目的大部分技術組成，推薦用firefox/chrome+其插件：

根據自己的需要和項目的特點來取捨吧，grunt是前端工程化的先驅，是yeoman重要的一環，跟gulp類似都是任務執行器，只是gulp提供了更自然基於流的方式連接不同的任務。作為任務執行器理論上可以做跟自動化相關的任何事情，只是在前端用的多些，而且現成的工具也比較多。webpack更專註於前端的通用解決方案，定義了前端構建的標準模式，同時提供了良好的擴展機制，社區發現良好。國內百度也有一套開源的解決方案，叫fis，個人感覺語法比較清晰，也很方便定製，通過生成資源表和提供的載入框架在做細粒度的優化上比webpack靈活些(畢竟是國內的，社區就沒有webpack那麼活躍了，主要是百度的工程師在維護)。總體對於單純前端構建來說，小項目差別不大，什麼熟用什麼吧，大項目用webpack和fis這種後期維護會省力很多

個人更喜歡gulp，基於stream，速度快，簡單易懂，親和力強。gulp也可以和webpack一塊用啊。關於gulp分享一下。 https://github.com/Platform-CUF/use-gulp

2年前的項目用grunt

1年前的項目用gulp

現在的項目用npm + webpack

明年的項目，還沒發明出來呢...

npm + webpack基本可以替代gulp，但是對於已有項目從一種方式替換到另外一種我是覺得沒有太有必要的

gulp和webpack兩者功能有重複,但不是完全的替代關係,可以混用的.

建議還是用 gulp 。

我們現在就要用 npm 封裝底層的

gulp+webpack

es7+npm

webpack

fis3 等四種方案。

運行 npm start ，一鍵搭建開發環境。

webpack 可以自己試用，但沒必要大範圍推廣，這個工具不成熟，感覺一年內應該有革命掉它的工具出現。

============ 2017年7月補充 ===========

真是被打臉啊，webpack 都出了 3，而且市場上也沒有其他影響力的競品出現。

說說自己的理解。

webpack 最大的優點是一切皆模塊，這是最大亮點，但可能也是它最大的限制。

作為 fis1、fis2、fis3 用戶，感覺 webpack 跟 fis 的定位越來越重合了。但 fis 的定位是前端集成解決方案，webpack 的定位則是 module bundler。

實際上，從 webpack 1.x 開始，就已經開始處理 module bundler 外的問題了，到了 2.x、3.x 愈發明顯了。也就是說，webpack 在不斷擴大關注點。一旦軟體的定位逐漸擴大，所需考慮的問題集也會相應擴大，原有的模型對於解決新問題極易發生衝突。這時要麼技術架構整體推到重做，要麼不得已使用 tricky 的方案，但會顯得格格不入。這就是我說不成熟的主要考慮。

PS: webpack 的 loader 一直不改成 transformer 啊。

這裡只有強烈安利一下我這個項目了

GitHub - bodyno/react-starter-kit: 完美使用 React, Redux, and React-Router!

用了之後你就會發現你什麼都懂了

這幾樣除了 Grunt，你都搞懂了就知道該在哪些場景用用什麼最合適了。Grunt 適合那些非 Node 程序員或者從其他語言轉過來的開發者。這些工具我只能說各有特點，我在不同類型的項目中都用過。但是基於本能我會對那些過於「功能豐富」的抱有戒心，例如 Webpack。

還有一些強迫症認為 npm scripts 就夠了，增加對 gulp 的依賴沒必要，這也不是絕對的。因為稍微複雜一些的控制還是要寫 Shell 或者其他 JS 程序來幫助你，否則更麻煩。

不過，考慮到實際工作中要創建大量的實驗項目，那麼用 Gulp 更多，前端會和 Browserify 配合。但是寫 React-Native 的時候往往會再配合 Webpack(讓 React Native 更多地利用 Node.JS 的資產)，因為 Browserify 在這塊還沒人研究好。最近寫了好幾個 Yeoman Generator 來加速實驗項目的創建，生成的腳手架也是以 Gulp 為主。

還有一個最重要的，Gulp 是基於 Node Stream 創建的，Node Stream 是 Node.JS 中及其重要的設計模式，天生就具有良好的互操作性，這是 Webpack 比不了的（但同時也是很多不熟悉 Node Stream 的人不願意用 Gulp 的原因）。

而 Webpack 的優勢在於對於複雜的依賴樹進行重新批分，以便於前端多頁面的復用，這是唯一的優勢。但是其自身的 Require 實現也是對目前 Node.JS 的模塊系統的一種污染。

試用了下gulpman，基於gulp比較靈活，配置和使用相對簡單，都一次搞定，不用折騰了，裝完就能直接用：GitHub - xunuoi/gulpman

僅通過一個配置文件就能完成絕大多數的配置，整合了react、es6、 karma測試等。

另外也推薦下webpack，目前大家用的也比較多了。

還是要以具體項目和所在團隊來選擇構建工具。

小項目，零散頁，歷史項目，結構不複雜，維護難度相對低，模塊化要求低，用gulp/grunt上手快，任務流清晰易懂。

webpack設置複雜，更多關注項目整體的配置，因為require everywhere的理念，使得靜態資源也變得容易維護，模塊化組件化更是爽到飛起。中大型項目的利器。

但

學習成本初期比較陡峭，各種loader坑很多，api含糊不清(文檔不知道寫給誰看的)，需要有一定外語基礎才能google到答案，但一旦越過學習曲線爬升期，會豁然開朗，愛不釋手，形成自己的workflow，稍加修改就可應用到不同項目內。

反正我自己是統統webpack啦...

ps：如果是僅僅打包js，再安利一下rollup。

我更傾向於gulp一些，更加簡單、易用，性能好，能很容易定製自己的前端項目方案。

出了題主說的這些，還有FIS也不錯。FIS的模塊化理念很好，方便資源定位和模塊維護，但是FIS本身確實過於龐大，需要整合服務端代碼，門檻有點高~

這裡推薦下基於gulp的輕量級解決方案：gulpman

基於 gulp ，簡單、靈活，容易擴展和修改，懂點 gulp 的童鞋都可以自己修改、使用、組合。

不需要任何服務端的整合工作，這個與 FIS 有很大不同，不需要修改服務端代碼來適配，就像正常的 html 一樣，去引用你的 js 、 css 、 img 、 fonts 等資源，無侵入。

整合 SCSS ES6 Browserify|cssnano|uglify|imagmein|rev 等前端常用套件，同時有監視文件變動功能(watch)，可配置的發布目錄、資源目錄、 CDN 等，方便開發，簡單易用，一站式搞定。

安裝就是 npm install gulpman --save-dev

安裝完後，無需任何配置、整合，直接執行 gulp gm:init 就能立刻初始化項目，通過 gulp gm:publish 就可以立刻發布資源了。 gulp 的插件都可以隨意組合進去，沒有學習門檻。

詳細使用可以看下教程： Gulpan-簡單靈活的模塊化前端解決方案!

附上 github ： GitHub - xunuoi/gulpman: 基於gulp的前端模塊化解決方案，比FIS簡單、靈活、可控, 集成ES6、Babel、Browserify等特性組件

用過gulp，最近在琢磨webpack。

感覺兩者理念不太同：

gulp是將一系列常規的task按部就班的自動執行，比如scripts和less各自的compile-minify-transfer等等，它從使用者的角度出發，做的還是那些大家手動會去做的事，只不過自動化了，通過一個腳本來執行，grunt類似；

而webpack則把scripts和static files均視為module，通過loader（比如babel-loaderless-loader，分別用以把es6轉為es5和less轉為css）的處理，將之轉化為項目所需的所謂的assets。它從項目的角度出發，通過配置（webpack.config.js）實現，因此更加省心（理論上，因為不用考慮腳本的邏輯，當然，看起來可配置的項還是挺複雜的，不過這些都是死的吧，而且常用的就那幾項）。

webpack嚇我一大蹦的地方在於，一執行命令，就只需引入一個bundle.js，樣式腳本啥啥啥的都有了，哭。

個人拙見，歡迎指正。

webpack好用，但是簡不簡單各有各的看法。

如果只是做個玩具，或者寫一些很純粹的組件或者第三方庫，確實簡單。隨便google一下就可以找到能用的配置文件。

但是如果做項目，webpack的配置不但不簡單，反而還挺複雜。

第一webpack本身的配置和文檔很多需要花很多時間看，關鍵是文檔質量不高。

第二webpack插件多也要花時間看文檔，這點很重要一不小心就被坑到了。

這不昨天就被一個配置煩到凌晨，css打包連接的fonts和圖片資源路徑不對，後來把插件配置多加了一行就好了。這麼簡單個需求，我google半天都沒找到。

Webpack的好處不言而喻，一切資源都可以模塊化，這個思路寫代碼的時候確實方便。

當你的Webpack配置最好終於成功跑起來的時候，這個時候你就會默默地把自己寫的gulpfile任務加一堆gulp插件給刪了。

好吧，gulp+rollup來了，233

rollup.js

一直在用gulp，都挺好用，沒發現有什麼不足

webpack好用又省事，真不知道有啥理由不用