[Nemcue]

Not often I see tools announced with such a thoroughly researched article. Great stuff!

I guess the problem these build tools are facing is the amount that people have invested in Grunt. There are just /so/ many grunt tasks at this point.

[_puk]

I've also been playing around with gulp, and whilst still in the 'trying to use it like grunt' kind of mindset, I have seen some merit in using these stream based build tools.

Have to wonder why this all requires new build tools to achieve though.

It's obviously technically possible (npm shows grunt-gulp which does exactly what you'd think), so is the grunt architecture so firmly rooted in files that streams could not be leveraged, or is it something that will come in time?

Personally managed to get a nigh on perfect build process using grunt-watch, so no rush to move away.

Nice to see build tools still moving forward though.

[tracker1]

I think the irksome point of grunt is simply that you tend to have many temporary directories for various states of files... especially if you use CoffeeScript or other intermediate languages, not to mention merge/minify actions and their temporary spaces.

[AdrianRossouw]

grunt takes an almost entirely declarative approach, which becomes really hard to reconcile with situations that the order of execution really matters. because you are basically trying to map a flat(ish) array of commands onto a tree-like structure to trick the grunt internals to work the way you need them to.

You can either do this explicitly (by setting up aliased), or implicitly (by all the temporary file watch jiggery and pokery).

It's unlikely that I will start any new projects with grunt, even though I know it a lot better than gulp right now.

[iamstef]

ya, grunt tends to suffer from an massive explosion of complexity

[imjared]

Yep- a search on npmjs shows not quite a dozen tasks for Broccoli while Grunt has hundreds of results. Not that quantity necessarily == quality but when it comes to a task runner, I need to, you know, run tasks.

Definitely awesome that people are trying to optimize in the devops space but just not sure I could be convinced to switch to something that isn't at least somewhat mature.

[tracker1]

I think the trouble comes in that 3/4 or more of Grunt plugins are things that really have very little reason to be plugins in the first place. Given how flexible node really is, and how npm tasks work, I'm more an more inclined to simply having a ./scripts/ directory with a file per task registered in package.json, so I can simply `npm run taskname` and have it correlate to `./scripts/taskname.js|coffee` ...

With node.js as a host environment, it's easy enough to do pretty much whatever you want as a script/task, and is pretty much cross platform, and works well. Shell scripts come close, but ignore the elephant in the room (Windows).

For the record, I'm biased as all hell, like node.js and JavaScript in general.

[camus2]

> Shell scripts come close, but ignore the elephant in the room (Windows).

I use mingw and make, never had a problem on windows and it's not like mingw is heavy to download. Most people use git and git comes with a bash on windows too, so 0 excuses to learn shell scripts.

[virtualwhys]

Agreed, Grunt has served me well, much like Bootstrap up to v2.3.2 has, so am in no rush to go looking for the hat on my head.

Hands full server-side anyway, client-side moves way too quickly to keep pace with the latest and greatest...

[shadowmint]

yep.

Honestly half the battle is having a great easy to use plugin style that gets lots of people making plugins, and given the incredibly brief mention of plugins which makes them seem quite complex, I'd be quite wary of broccoli at this point.

[Kiro]

Can you give some examples of your Grunt tasks?