[mixonic]

> In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing.

This may be true for a codebase of trivial size. With a sizable codebase and many build steps (defeaturefy, babel, es6 modules, es3recast, jshint, jscs) you quickly see grunt and gulp fall flat.

Gulp and Grunt absolutely have a simpler API for blindly chaining tasks. And they have the ability (as task runners) to define multiple tasks and compose them.

Broccoli is tricky to learn. In Ember-CLI we go out of our way to make it invisible to devs who shouldn't need to care what tool is running the internals. For the internals however, it is definitely the correct tool.

[pfooti]

For what it's worth, my gulp build handles both ES6 and Coffee files (although coffee is being phased out it is still present) on both the front (angular) and back (node) ends. It then takes the built files, merges the two streams (as well as any passed-through content from bower etc), and conditionally on development / beta / production sends them through sourcemap, angular-annotate, cat, minify and md5-rev (for cache busting) layers. It also handles injecting correct filenames into index.html and my karma.conf, sorting angular angular files so they're catted in dependency order, livereload, restarting the backend server, catching build errors, and quite a bit more. Plus sass, of course. It does this with a live asset server for development or building to static files for production. As a bonus, I also can use gulp to run various other important tasks like my ersatz database migration (rolled my own with node and some raw SQL fles) process.

I'd say: I ended up building all the features I wanted in broccoli as part of a gulp build system. It did not "fall flat", rather, at the time (about eight months ago), I found broccoli had fallen flat- it didn't handle what I wanted, and even when it did it was impossible to do incremental rebuilds (say) of files - change one thing and the whole system rebuilt itself leading to a livereload on * rather than a single changed file. On top of everything else, it was dog-slow on medium-to-large codebases. I understand that this has changed since, but the frustration I had originally getting it to do what I want coupled with the length of time it took to run rebuilds (nobody wants 10k msec builds when the same process elsewhere takes 300msec) made me transition to gulp. I'm sure broccoli is just fine nowadays, and my read of the emails (I still am watching the repo) seems to indicate that Stefan ironed out a lot of the performance issues around watching and rebuilding (symlinks on OSX, IIRC, were a dog).

As I said the first time around: you can do just about anything with gulp or grunt, you just have to DIY. If you happen to enjoy spending some time really getting to know your toolchain, they all end up doing about the same thing, and with grunt and gulp it's marginally easier to configure certain aspects of the process.

[spiralganglion]

"defeaturefy" is a Googlewhackblatt (only result is this thread). Care to explain what this term means? My curiosity is piqued.

[jannes]

I guess he/she meant https://github.com/thomasboyt/defeatureify but forgot an I in the name.