初嘗Gulp

Gulp自出世起，熱度就很高。它利用了Node的Stream機制，速度很快；函數式的寫法也很便於閱讀。這兩大優點讓它一躍成爲最受歡迎的批處理工具，幾乎佔據了半壁江山（2015前端工具普查）。

我以前一直用Grunt，爲了避免落後於時代，前幾天在一個業餘項目中試用了一下Gulp，如下是個人感覺。

確實好讀

雖然沒法獲得證明，不過我相信Grunt的設計中有不少都是借鑑Ant得來的——在沒有Grunt以前，我曾經用Ant腳本 + Google Closer Compiler + Google Closer Stylesheets 壓縮代碼——好比，它的配置是JSON格式的，跟XML很是相像。Grunt的問題也在這裏：聲明任務須要寫JSON配置文件，不一樣的任務須要寫在一塊兒，而後經過registerTask('task', ['task1', 'task2:js', 'task3', ....])來組織。這樣先後脫節，確實既很差寫，也很差讀。個把月回來徹底看不懂也不算意外……

而Gulp的設計則更加自由，它充分利用JavaScript的函數式寫法，一個任務就處理一批文件，從上往下看，結構很是清晰：

gulp.task('js', function () {
      gulp.src(['js/'])
        .pipe(concat())
        .pipe(replace('@version@', version))
        .pipe(uglify())
        .pipe(gulp.dest('dist/js/app.js'));
    });

勝者：Gulp

速度快，然無卵

Gulp受推崇的另外一大緣由就是速度快，通常的任務都是毫秒級。

不過，這對於我來講意義不大。做爲一名人民幣玩家，哥的慣用IDE是WebStorm和PHPStorm，均支持文件實時編譯和自動刷新等經常使用功能。因此我只須要批處理工具幫我壓縮文件和打包便可。

這個回合：打平。

Stream VS Native，異步 VS 同步

前面提到，Gulp利用了Node的Stream機制，它的內部是處理文檔流。這方面Grunt比較保守，仍然是把文件讀進內存，而後進行字符串操做。兩者的機制不一樣很差對比，不過做爲從頁面仔成長起來的前端工程師，不得不認可我對流的理解並不深入，對文件讀取和二進制操做也不甚了了，因此在理解兩者和開發業務插件的時候，我寧肯選擇Grunt。

另外，Gulp的任務是異步的，因此在個人使用場景中——先clean目錄，而後各類壓縮，最後打包成zip——就很難搞（因此我以爲不少人用Gulp只是爲了實時編譯預處理文件）。後來用了sequence插件才搞定。

這方面我以爲Grunt雖然保守，可是更接近前端開發者的知識結構，學習成本更低。

勝者：Grunt

雜項

Gulp的團隊應該是有代碼潔癖的，好比，他們有一個官方插件倉庫，這很正常；可是他們居然還有一個Gulp插件黑名單……簡直匪夷所思……

因此Gulp團隊顯然不肯意重複發明輪子，好比簡單的clean目錄，他們就不肯意作，並且也不讓別人作，由於已經有不少工具能夠實現這個功能了……可是對於初學者好比我來講，就會在插件引擎中找半天，最後仍是Google到相關指引才獲得正確的作法。

這方面Grunt團隊作的很好。Grunt插件中有一組是官方提供的，以grunt-contrib爲命名空間，基本上，使用這套組件就能夠完成我全部的平常工做了。

勝者：Grunt

---

總結

大趨勢上，Gulp的確勢頭迅猛。可是從實際體驗中，我以爲Grunt目前更成熟，也能知足工做所需。

我並不想說Gulp很差，只是如今的我用起來不太順手。若是哪天我有時間好好搞搞後端，搞搞Node開發，把Stream概念搞清楚，也許我也會轉投Gulp。不過目前，仍是繼續用Grunt吧。

---

同時發佈於個人博客，兩邊同步更新。