初尝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吧。

---

同时发布于个人博客，两边同步更新。