寫在前面: 這文章寫於15年末,後來16年才放到segmentfault上來,看到陸續還是有瀏覽量甚至收藏,以免造成誤導還是在文章前頭稍稍提醒一下.我已經不是第一次看到這類似的話語,為數不少的人都覺得webpack是目前前端工程化完整性解決方案,打出了終於不再用糾結使用grunt或是gulp了的旗號,只要使用webpack就足夠了當時觀點放到今天難免有些打臉,就目前來說webpack已經完全佔據主流位置,連我自己的專案都很少會在開發階段用glup了.但我依然覺得webpack與glup兩者職能不同,例如把一些類似
測試任務,上線部署之類的事交給gulp這類構建工具是很自然而然的事.webpack依然是打包工具,而打包,只是構建的其中一環而已.
而事實果真如此?
首先看看webpack官網給出的解析
webpack is a module bundler.簡單來說,官方對webpack的定位是模組打包器,相比於gulp或是grunt,webpack的競爭對手應該是browserify之流
就連webpack官方也給出了webpack with gulp的一些說明
雖然webpack的確可以代替gulp的一些功能
但是非常明顯webpack和gulp/grunt就不是乙個職能的工具
所以說取代還言過其實(之前我的乙個提問)
那麼問題來了
為什麼是要構建這樣乙個工作流,首先要理清幾個問題gulp而不grunt?因為我用的是gulp - -!
就如前面所說,webpack只是乙個模組打包器,所以,交予webpack處理的應該已是經過各種lint檢查,各種編譯處理的**
而各種檢查,各種預處理就應該交給gulp之流了
最後壓縮**應該要交給webpack最後打包時再去執行
之前一直沒有注意這個問題
看看gulp的基本使用
gulp.src('client/templates/*.jade')
.pipe(jade())
.pipe(minify())
.pipe(gulp.dest('build/minified_templates'));
watcher實時檢查檔案是否更新,檢查到有更新則馬上跑相應的構建任務,但是有上面的**可以看出,gulp每次都只能通過萬用字元匹配大量的檔案,而不能就單單獲取修改過的檔案,這種情況在大型專案中每次構建都會花不少時間,更別論要在構建任務之後再加乙個webpack的打包任務
不過所幸上網找到乙個gulp-changed的外掛程式,實在棒!
之前開發時live reload都是交給gulp的,而現在gulp的構建任務並不是在任務鏈的最後端,由gulp來實現顯然不再合適
基於上面的思考,我做了個嘗試專案
做些簡單的說明,上面的專案只有簡單的幾個構建任務
gulp.task('js', function() ))
.pipe($.eslint())
.pipe($.eslint.format())
.pipe(gulp.dest('build'));
});
gulp.task('css', function() );這裡要說明一下在這個示例專案中其實並沒有實際編寫任何css或scss,因為專案中的todo應用實際是從redux todo直接拷貝的 = =!
gulp.task('html', function() );如果是使用其他模板引擎就可以在這裡進行編譯
而live reload應該怎麼做呢?
參考了一下react-transform-boilerplate和redux todo(其實還是直接拷貝的= =)
gulp.task('default', ['clean', 'js', 'css', 'html', 'watch'], function() else
});});
devserver
修改檔案時,gulp就會從src->build進行構建,而webpack則是檢測著build資料夾是否有更新來進行增量編譯,同時實現live reload
至此,已經把腦中想法基本實現了出來(其實並沒有,bug多多的說)
再來說說實踐過後的想法
webpack果真是業界殺雞用牛刀的最佳代言人好吧,可能是我接觸webpack不久
在如此小的應用上,使用webpack真是一點都體會不出它的好處
(唯一一點可能就是es6的import語法而已,不過要使用import還是react或redux等等庫的坑)
在大型專案使用可有成功案例,希望大家不吝指教一下^ ^~
另外一點,我還看過幾篇比較gulp和webpack的博文(國內外都有)
大意其實都差不多,就是說,如果用gulp,你要寫多很多**,你將會有非常多的開發依賴balabala....
而用webpack,你就可以通過少量的**解決這些問題等等等等的,
且不論**多少的問題,這點我並沒有實踐過
但是再一次表明我的看法
webpack和gulp/grunt就不是至於何為乙個職能的工具,談何取代?至於**多少的問題
有沒有想過,
**少就真的一定好嗎?我認為,
gulp/grunt或是browserify/webpack等等工具的面世,其實都是為了解決前端的工程化問題在
工程化問題面前,難道追求的真的是write less, do more嗎?舉個例子,各種
mv**的設計模式,真的有讓大家少寫很多**嗎?起碼我並不覺得有那麼一回事我認為,付出適當的代價,組合使用各種工具,使用合適的工作流,才能真正起到管理前端工程的作用
適當,何為合適,依然需要探索 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 側...