

The streaming build system - stevewilhelm
http://gulpjs.com/

======
jdlshore
Gulp is an interesting idea, but I'm skeptical of its long-term viability. As
Wintamute said in another thread, large projects have a lot of needs, and
streaming isn't enough for all (most?) of them. Gulp's creators were pretty
adamant about not supporting other use cases when this came up on Twitter. [1]

Another issue with Gulp is that it's highly concurrent. Although that seems
like a nice idea for speed, I suspect it will lead to a lot of hard-to-write
and hard-to-debug edge cases. I've already heard reports of people getting
strange behavior from their Gulpfiles [2].

At this point, I'd take a "wait and see" approach with Gulp unless you like
playing with build tools or if you really need its focus on speed. If you're
looking for a good build tool for that lets you "just run JavaScript," I'd
check out Jake [3] instead. And of course, Grunt [4] is the current leader for
JS builds, thanks to its immense plugin library.

If you're interested in a more in-depth review of Gulp, I have one here: [5]

[1] The Twitter thread:
[https://twitter.com/funkytek/status/423762923421302784](https://twitter.com/funkytek/status/423762923421302784)

[2] Somebody runs into strange behavior from Gulp:
[http://www.reddit.com/r/javascript/comments/1v4tez/bottom_li...](http://www.reddit.com/r/javascript/comments/1v4tez/bottom_line_right_now_gulp_is_too_focused_on_its/cep25ac)

[3] Jake: [https://github.com/mde/jake](https://github.com/mde/jake)

[4] Grunt: [http://gruntjs.com/](http://gruntjs.com/)

[5] My Gulp review:
[http://www.letscodejavascript.com/v3/comments/lab/1#comment-...](http://www.letscodejavascript.com/v3/comments/lab/1#comment-1197581116)

------
spullara
Developers seem to be separated into two camps, those that want scripting in
their build system and those that work on large projects.

~~~
timothyb89
I'm a bit curious, why would those goals be at odds? Is there a specific
reason build systems like this don't scale well? I'm genuinely curious, not
having had much experience with larger projects.

I'm not certain how use of a "proper scripting language" is much different
than using automake, cmake, ant / maven ... in what ways are these necessarily
different from something like gulp.js, other than syntax? Does the
introduction of extra language features have a negative impact in scalability
implicitly?

~~~
Wintamute
In a large complex project build scripts tend to take on many tasks, and some
of them will not necessarily fit into the pattern of taking in a stream of
file globs, modifying them and piping them on into the next task. For example
your script might manage a Git repo, deploy an app to Heroku, rsync some files
somewhere, run some tests in a headless browser etc. So a build system that's
optimised around streams, and one that you have to script by hand, might be
very well suited for small streamlined projects but once things get varied and
complex it might better be better to define your tasks via configuration
instead of code, i.e. Grunt.

------
bevacqua
Check out this article for a comparison with Grunt and npm run.

[http://blog.ponyfoo.com/2014/01/09/gulp-grunt-
whatever](http://blog.ponyfoo.com/2014/01/09/gulp-grunt-whatever)

------
integricho
it reminds me of grunt, with a couple of plugins, or I didn't get the point.

~~~
nailer
Yes, Gulp performs the same tasks as grunt. However I switched to gulp after
trying it because:

Gulp's simpler - my old 47 line grunt file became a 23 line gulp file.

Also you don't expose useless targets, eg in grunt I have 'grunt less', but I
have to tell people not to run that task , as I also use auto prefixer and
can't make grunt less automatically run auto prefixer - if they run 'grunt
less', they'll produce unusable code.

There are other reasons too - gulp was developed after grunt, so it does some
things similarly and other things much differently
[http://slid.es/contra/gulp](http://slid.es/contra/gulp)

