[thesnider]

This article seems super weird -- do people actually use Grunt/Gulp to run a single command at a time? Most uses that I've encountered are along the lines of 'we've got this huge build process involving compass, sass, uglify, ng-annotate, and 13 other things', and Grunt/Gulp allow you to do the whole thing, automatically re-running on file changes, with a single command.

[plingamp]

No, like you said Grunt/Gulp is useful when you are automating multiple tasks that are done repeatedly. The title of this article is total click bait.

[edraferi]

The author's argument is actually "NPM is a better build tool than Grunt or Gulp."

He followed up with an extensive tutorial on how to do complex builds with NPM [1]. The tutorial concludes with an example where NPM is used to:

* Take my JS and lint, test & compile it into 1 versioned file (with a separate sourcemap) and upload it to S3

* Compile Stylus into CSS, down to a single, versioned file (with separate sourcemap), upload it to S3

* Add watchers for testing and compilation

* Add a static file server to see my single page app in a web browser

* Add livereload for CSS and JS

* Have a task that combines all these files so I can type one command and spin up an environment

* For bonus points, open a browser window automagically pointing to my website

He accomplishes this with ~20 lines in the "script" object of package.json. The whole process is initiated with a single npm run dev command. He asserts that "to do the equivalent in Grunt, it'd take a Gruntfile of a few hundred lines, plus (my finger in the air estimate) around 10 extra dependencies."

[1] http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...

[2] https://github.com/keithamus/npm-scripts-example

[yeskia]

Agreed, the ability to watch for changes and react to them is one of the better features. Plus, allowing the standardisation of practices through a team (build process, testing process) and the codification of the application's dependencies.

[dahdum]

Same here, a bunch of complex & dependent tasks all boiled down to a few commands run often, and a bunch more less so.

I also use grunt-shell a great deal rather than find/write a new plugin, pretty decent way to call out to bash.

[igl]

Show me one task in your Gruntfile that is complex. grunt-shell also just wraps child_process.spawn which is already trivial.

[dahdum]

If it's more than several lines, I write it out in a separate bash/js script and use grunt to call it, via shell or require() depending.

Not saying it's better than make or something else, but it's easy for everyone on the team to use & modify.

[maaaats]

You (and the rest of the comments to your post) miss the point: Now you need grunt, a gruntfile, the tools for the build process and grunt specific wrappers.

What you instead could have had was a simple script running the tools with the proper command line arguments.

[jaredklewis]

Are you also against make, cmake, mvn, rake, etc...?

Those tools could also be replaced with custom scripts, but programmers in every language seem to agree that build tools make the job easier.

I don't think grunt or gulp are perfect, but do think they make writing, organizing, and reusing build tasks easier.

So are just against gulp/grunt, or really are opposed to the whole idea of a JavaScript build tool?

[matsemann]

Strawman... I'm neither against build tools nor the idea of a js build tool.

Make would basically just run CLI in this instance, so it's exactly what I like. I like maven, but I hate when I need a special maven plugin for the tool I want to use. All these tools expose a nice CLI that can be used, no need to complicate it by adding more abstractions. If it weren't for how Grunt can watch files, I would have scrapped it for our project. Because the config Gruntfile for our build process is impossible to understand and maintain, but the end results are just some simple commands to various tools.

[ivanmilles]

No, you're right. The use case for Grunt/Gulp is in the name: task runners, to automate the running of tasks, to stabilise and formalise the build process to the point of repeatability across a team.

It's a bit strange to have him bash on the Grunt/Gulp ecosystem's plugin dependence and SemVer configs, and then go on to recommend using npm instead, which is also dependent on node and its ecosystem.

That said, the npm solution looks attractive for simpler build flows, but hook in a fat custom plugin to a watch task on a subset of files and I'm sure you'll get the same complexity in package.json.

[wetmore]

Yeah last time I saw this article that's pretty much what people were saying.

It's like saying you shouldn't use a web framework, and using as an example a website where you type a word into a textbox and it alerts whatever you typed. Yeah, of course that's a simple project so there is no need for higher organization, but it's hardly an argument to stop using frameworks altogether.

[demarq]

I agree, I'm just not buying his idea as a real alternative for projects at scale.

[twfarland]

I just feel sorry for anyone who has to deal with '13 other things' in their build.