The advantage of Gulp, in my opinion, is that it's driven by code rather than config - that is to say, in order to define your tasks you write JS code instead of JSON. That gives you a considerable advantage in cases where you want to do something outside of the scope of what the plugin developer was thinking.

Of course, that brings with it the disadvantage of needing to be able to write JS in order to configure it, and an additional point of failure (eg your own code).

I don't see how that's different from Grunt, which is also driven by code.

This is a good explanation; https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-...

I never got what's so great about Grunt in the first place, and instead stuck to makefiles. Something like `cat src/*.js | uglify > build.js` would take me a lot more effort to do with Grunt (or Gulp).

With gulp;

    var gulp = require('gulp'),
        concat = require('gulp-concat'),
        uglify = require('gulp-uglify');

    gulp.task('js', function(){
        return gulp.src(['src/**/*.js'])
            .pipe(concat('build.js'))
            .pipe(uglify())
            .pipe(gulp.dest('.'));
    });

    gulp.task('default', ['js']);

With grunt;

    module.exports = function (grunt) {
        grunt.initConfig({

            concat: {
                js: {
                    files: {'build.js': 'src/**/*.js' }
                }
            },
 
            uglify: {
                bundle: {
                    files: {'build.min.js': 'bundle.js'}
                }
            }
        });

The bash script is easier for such a trivial job. Gulp and Grunt aren't better if that's all you're doing. They come in to their own when you have a large number of tasks to run. But even then, if you (and your team) prefer make then it's better to use make.

You old curmudgeon you... ;-)

Make has it's foibles - before we talk about those we need to declare are we talking gmake, nmake, BSD make etc. - our build scripts can break in the wrong make. And how will windows users collaborate (they'll install cygwin). Etc etc

All that said though, I still find make to be lower barrier to entry.

If I need to start a watcher or something, I generally have that in my npm package.json but there's nothing stopping me having a make target to call npm start or whatever.

I forced myself to learn enough gulp to be dangerous (incidentally I see strong parallels between grunt / maven and gulp / gradle) and the faux pipes implementation is clearly influenced by make, it's just far more clunky an implementation.

So it could just be I'm wired up wrongly but I have to agree, neither grunt nor gulp moved the needle meaningfully.

Counter arguments like it's all one language don't hold much water for me, or for the designer who only really knows css.

I'm resigned to being labeled a curmudgeon in this one!

I had reservations about using make for node builds until I got berated by another curmudgeon on here, who kindly showed me all the tricks necessary to implement the rules I needed. I'm very very happy I switched to make.

I think part of the issue is that I (and I suspect many others) though I knew basically how make works, except that I had no idea about % patterns, the patsubst function, etc.

Can you share any of those tricks?

If that's all you want to do (concat, minify, convert es6/sass), then by all means, I do agree make is the simpler albeit slightly less maintainable and non-cross-platform solution. I use make for my quick static sites too.

But when you need more features like bundle splitting (app code and libraries live in separate files, for caching), cache-busting, lazy-loading, separate configs for production and development, etc. make doesn't quite cut it IMO.

Sure, cross-platform (read: supports also Windows) is a big plus for grunt, gulp and the likes.

It does seem overly complicated, for what ends up usually being not much more than a makefile or even a simple batch script.

We haven't quite come out of the cycle where everything that we already had has to be half-implemented a dozen times in JavaScript/Node...

One huge advantage is speed - Grunt relies on disc I/O and copying files to temp folders, while Gulp is based on streams and all your file transformations are done in memory.

IME, with enough dependencies in enough tasks, it can get very slow to start.

(Just a personnal feeling) Gulp commands are more standardized, while in Grunt every plugin seems to develop its own way of doing things. And Gulp tends do do things faster.

But as you said, nothing wrong with Grunt. Indeed feeling the Javascript build tool fatigue , I'm seriously hesitating to do everything in a makefile

I have large project built with Grunt and at one point I have tried to move it to Gulp. Gulp, as far as I can tell, requires much less code to do the same stuff. However, two things forced me to stick with Grunt. 1) The build scripts were working just fine. Why fix something it ain't broken? :) 2) When Sass or Coffee fails, gulp watch fails entirely. It's something I wasn't able to solve. Grunt will just pick up from it was before the error. Dunno!

This must be solved with `gulp-plumber` which is actually about a 10 line hack around fixing some underlying bugs with merging streams if memory serves.

for less it's a pretty easy fix: .pipe(less()) .on("error", function (err) { console.log(err); this.emit("end"); })

I presume, something similar will work for sass too.