gulp

It hasn't been officially deprecated or anything like that, and it still works fine for the most part [1]. However it hasn't received a lot of active development in the last couple of years. I do think the whole concept behind Gulp, of creating processing streams through which files are fed to transform them, before writing to disk, is less useful than it used to be. This is because a lot of that functionality can now be handled by bundlers which understand the inter-dependencies between modules rather than just taking the input as a set of files. Also Node/JS's own async functionality is much more ergonomic to use than it needs to be, so additional async abstractions on top are less useful than they were. [1] I'm aware of some issues related to file watching. See https://github.com/gulpjs/gulp/issues/2654

I'm not quite sure they are underused, but that's a relative judgment. Streams took a while to get right in node, and even now they're a little bit clunky. Not terrible, but not "pick it right up and run with it" easy. (If you want to use them, you probably should look at Mississippi https://www.npmjs.com/package/mississippi because that simplifies a lot of common tasks.) AFAICT there used to be more energy in the community for them. Gulp.js was conceived as more powerful build pipeline that used streams (https://github.com/gulpjs/gulp), and that's the last time I remember anybody getting psyched about streams as "more elegant" than a nonstream version (in that case, Grunt). Now, I think people tend to reach for streams when there's a performance-based reason for it, since streams can do things like faster time-to-first-byte, and less mem

FWIW, I do use make. I could not deal with gulp’s issues[1], so I wrote a little thing of my own, just to quickly whip up websites for my projects[2]. [1]: https://github.com/gulpjs/gulp/issues/651 [2]: https://cannot.mietek.io

Regarding plugin dependencies, gulp maintains a blacklist of plugins that are not recommended for various reasons (bloat, poor design, unnecessary, etc): https://github.com/gulpjs/plugins/blob/master/src/blackList.... They also link to an article about why you should resist the urge to create gulp plugins on their wiki: http://blog.overzealous.com/post/74121048393/why-you-shouldn... Additionally, they maintain a collection of examples of common use cases that tend to send people searching for plugins unnecessarily: https://github.com/gulpjs/gulp/tree/master/docs/recipes Other popular projects also recommend against plugins for integration into gulp, such as browserify and karma test runner. There are a number of great support packages for gulp that handle the handful of special file stream manipulations that you may need to perform (vinyl

* https://github.com/gulpjs/gulp/blob/master/docs/recipes/brow...

Looking at the current state of Javascript toolchains (RequireJS, browserify, Gulp, Grunt, and all the millions of plugins that come with these tools) I feel like there has been a toolchain explosion that's getting out of control. Looking at any one example of a Javascript build script I find references to dozens of other tools all of which needs to be pulled down with the current FOTM package manager... It feels like a collection of russian dolls just trying to get my head around it. Just as an example here is the first build script I found navigating from the Gulp site: https://github.com/gulpjs/gulp/blob/master/docs/recipes/browserify-uglify-sourcema… So. Many. Moving. Parts. It's not normal for a toolchain to be this complicated. Do you think it's getting out of hand? For those of us building real-world projects that are still goi

I think you are talking about this[1], indeed you are right. However, task dependencies allows sequential tasks execution, but that's not very handy as you may want a same task to be executed in two different sequences. Let's see a simple example on which I honestly struggle to reproduce with Gulp: [Lint, Test] -> Concatenation -> Minification Watch -> [Lint, Test] -> LiveReload How would you do such a setup without having a redundancy in your tasks declaration? [1]: https://github.com/gulpjs/gulp/blob/master/docs/recipes/runn...

Make uses disk I/O, which is really slow, and for complex projects become difficult to maintain. Also, why not use a proper programming language to define the build process? Well, a modern tool like Gulp[1] does that. It's streaming/asynchronous and scripts are written in JavaScript. I don't see why one would prefer Make over it. 1. https://github.com/gulpjs/gulp

You can see the new gulp.watch syntax here. https://github.com/gulpjs/gulp/blob/master/docs/API.md#gulpw...

I think by now most of you are familiar with Gulp.js, the new and shiny JavaScript task runner on the block, but I just came across another build tool that’s surprisingly similar called James.js which has been around for longer then Gulp. What’s the story behind James.js and why didn’t it get the attention that Gulp got? Gulp.js: https://github.com/gulpjs/gulp James.js: https://github.com/leonidas/james.js

There has been added a lot of new features to the browser, but the core language (EcmaScript) has not evolved much for a while. * Overview: https://rawgithub.com/whatwg/html-differences/master/Overvie... The next thing is JavaScript "next" or Ecma Script 6 * http://wiki.ecmascript.org/doku.php?id=harmony:proposals You can use Traceur if you want to try out ES6 features today More info: https://github.com/google/traceur-compiler These days there is a lot of things going on in the tooling section Build: * Grunt: http://gruntjs.com/ - a lot of grunt- tasks at http://npmjs.org/ * Newest kid in town: https://github.com/gulpjs/gulp Modulization and dependency management: * http://en.wikipedia.org/wiki/CommonJS * http://browserify.org/

I wonder what the pros/cons are for Fez, compared to Gulp: https://github.com/gulpjs/gulp