
Why we should stop using Grunt and Gulp - riobard
http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/
======
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...](http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/)

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

------
SeoxyS
I simply use Make for all my web projects, whether it's a Ruby JSON API, or a
React front-end. It's reliable, pre-installed everywhere, and can wrap
anything in one consistent CLI. Why have to remember whether to type _lein
repl_ , _pry_ , or _rails console_ , when _make repl_ will do everytime?
Ditto, _bundle install_ , _npm install_ , _lein deps_ => _make deps_. _make
server_ can easily wrap whatever command launches the server, _make dev_ can
easily use a filesystem watching tool to restart _make server_ on any change.
And beyond that, _make_ can be used as usual to "compile" the project, ie. run
whatever static analysis and preprocessing is necessary in the web world
(jshint, jsx etc.).

~~~
dickeytk
keep in mind that make isn't going to work on Windows. For a lot of people,
that's okay (including myself). Still, a ton of developers still work on
Windows.

~~~
pjmlp
Actually make isn't even fully portable across POSIX systems.

Unless you make sure only to use these features

[http://pubs.opengroup.org/onlinepubs/009695399/utilities/mak...](http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html)

Same thing for any external tool used in the scripts.

~~~
vidarh
Thankfully most of us can safely disregard all but a tiny subset of POSIX-like
systems.

------
xdissent
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....](https://github.com/gulpjs/plugins/blob/master/src/blackList.json)
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...](http://blog.overzealous.com/post/74121048393/why-you-shouldnt-
create-a-gulp-plugin-or-how-to) 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](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-buffer, vinyl-source-stream)
and since gulp operates on node streams (object mode) many useful npm packages
already apply.

------
Too
I found all build systems for all platforms to be a total PITA and eventually
i just resort to using a shell or python script to invoke the commands i want.
With this method you can very easily add user promting (do you want to build
debug or release?), database reporting of build and test results, source
control integration etc. Whatever i learn here can be applied and reused for
new things in the future instead of knowing all the 150 flags of whatever
build chain of the day.

This does not mean invoking compile manually on every file but you you invoke
the _smallest possible_ build file for your intended platform just for
building and absolutely nothing else. Compiling c projects without make would
otherwise take hours instead of minutes.

Really, Gradle requires you to read the first 12 chapters of the manual before
you can even begin doing something more advanced than running compile. Msbuild
likewise, it's like a completely new programming language just that it's
written in xml. Bamboo is just like imperative programming except you have to
drag and drop boxes that invokes commands or plugins (yep, another plugin
hell). CMake works kindof painlessly but it also requires a lot of black magic
when you want to add dependencies outside of the c buildchain.

The only one that actually doesn't make you cry is 'make' because it's so
simple, it's just doing one thing instead of trying to tie itself into the
entire ecosystem badly. Make also has it's problems but when you start hitting
those it's more of a sign that you are trying to add too much weird logic that
should not be in the build script to begin with.

~~~
bad_user
You cannot compare something like Maven/Gradle/SBT/Leiningen to Make.

Make doesn't do incremental building and testing, it doesn't do test coverage
reports, it doesn't download the dependencies for you, it doesn't build the
Javadoc documentation for you, it does not package and publish your signed
artifacts on Maven Central, it does not wrap your stuff in an OS specific
installer, etc, etc...

And you know, these things are standard stuff that one would like to do for
every project. It's unfathomable why anybody would want to do this manual
plumbing for each project with Make. You call Make "simple", I call it "dumb"
and it's the reason for why people end up with aberrations of nature, such as
Autotools.

> _Gradle requires you to read the first 12 chapters of the manual before you
> can even begin doing something more advanced than running compile_

You're exaggerating. Compiling a project is a hello world of a couple of
lines. What "advanced" usage are you talking about anyway?

~~~
vidarh
> Make doesn't do incremental building

Say what? That's one of the main purposes of make.

> it doesn't do test coverage reports, it doesn't download the dependencies
> for you, it doesn't build the Javadoc documentation for you, it does not
> package and publish your signed artifacts on Maven Central, it does not wrap
> your stuff in an OS specific installer, etc, etc...

... without the appropriate rule supported by whatever tools you prefer. Which
you, once you have a workflow that works for you, can put in a file and
include by reference in your makefiles going forward.

It's perfectly possible it's simpler for you to use one of the tools you list
than doing so, but the nice things about relying on basic make is that very
often people will want to tweak your assumptions about what "one would like to
do for every project":

> And you know, these things are standard stuff that one would like to do for
> every project.

Most of what you listed is stuff that I rarely want to do, and some of them
are things I've never done.

> I call it "dumb" and it's the reason for why people end up with aberrations
> of nature, such as Autotools.

The reason people end up with evil stuff like autotools is usually to (try)
handle platform API differences, not usually to handle any of the stuff you
listed. We seem to agree that Autotools is an awful mess, though.

------
Daiz
The author has a follow-up post that addresses a lot of things that are also
popping up in the comments here: [http://blog.keithcirkel.co.uk/how-to-use-
npm-as-a-build-tool...](http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-
build-tool/)

EDIT: Also a HN submission by the author himself:
[https://news.ycombinator.com/item?id=8721929](https://news.ycombinator.com/item?id=8721929)

~~~
lerouxb
Looks like he just traded grunt/gulp for browserify which is also a build tool
with lots and lots of configuration and plugins and I'd rather be using
webpack in that category.

Just switch to webpack and you don't have to bend npm or browserify to your
will either.

Relevant presentation: [http://adrianrossouw.github.io/webpack-uber-
alles/](http://adrianrossouw.github.io/webpack-uber-alles/)

------
Fannon
What NPM can't do is the async workflow of Grunt watch (or serve) and
dynamically trigger specific (sub)processes in real-time. Turns out, this is
the main way I'm using Grunt.

Also some plugins are complicated (or dynamically) to configure. His examples
were very simple, he could just put it into a batchfile aswell.

~~~
edraferi
The author addresses this issue directly in his follow up post [1]. He
describes two ways to get watch functionality when using NPM as a build tool.

First, "most tools facilitate this option themselves - and usually are much
more in tune with the intricacies of the files that should be listened for.
For example Mocha has the -w option, as does Stylus, Node-Sass, Jade, Karma,
and others." These options are simply invoked when the tool is called from
NPM.

Second, "not all tools support this, and even when they do - you might want to
compose multiple compile targets into one task which watches for changes and
runs the whole set. There are tools that watch files and execute commands when
files change, for example watch, onchange, dirwatch, or even nodemon."

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

------
joshstrange
I can fully understand not liking Grunt, it's configuration is impossible to
read and doesn't make a ton of sense to me. Gulp on the other hand is VERY
easy to read and I haven't have any issues with my colleagues adding/editing
the gulpfile.

Is running `gulp jshint` similar to running `jshint __.js`? yes but this is
not a fair comparison. First of all one of those can be run in the root of the
project while the other needs to be run in the right location (or have the
folder in the path) so that we don 't jshint libs we didn't write. Also the
author glosses over the fact that people rarely run `gulp *` and in fact will
run `gulp build` (or similarly named task) that will call ALL of the other
tasks you need to run. Also the author doesn't mention how wonderful `gulp
watch` (or similarly named task) is for watching files for changes and then
running tasks when certain files change.

I can tell you with 100% certainty that without gulp we would not be jshint-
ing our code, we probably will still be using regular CSS and not SASS (SCSS-
style), would still have a large gross master.js file instead of multiple js
files with logic cleanly separated out, etc. Could we use make? Yes but having
worked at a company that used make to build various parts of their web app I
can tell you that this get really gross really fast, feel free to disagree
with me but after seeing how bad it can get I won't touch make for web
projects again.

Gulp (I won't argue for Grunt, I don't like it at all) is easy to write and
easy to read and running the programs/tasks Gulp does for us individually
would have been a non-starter. As far as npm/make goes it would have been
harder to do everything we are doing and I'm not even sure `gulp watch`-type
features would have been possible without escalated privileges to install
other software.

------
igl
I am very comfortable with make, my coworkers however are not. Every
preprocessor comes with a command line interface, easily accessible and
understood. The only useful feature of these build tools is hot reloading.
`npm gaze` even provides a somewhat working fs.watch interface which works
good across platforms.

I am not sure if that justifies 70mb of additional dependencies and the "we
can solve that with a grunt plugin" mentality devs get. Our Gruntfile is 440
lines long :/

~~~
niklasni1
I'm a novice-ish web developer with decent UNIX knowledge. For my latest
Angular project which involved some CSS-preprocessing, I spent a few hours on
learning the and setting up one of these tools.

Then I found out what it was actually doing, and replaced it with a small
shellscript that NPM calls.

------
nmjohn
I don't understand the attention this is getting - sure, you don't need grunt
on a lot of projects, I never start a personal project with it and only a
fraction of my personal projects ever have me add it.

However for work, it saves a stupid amount of time. grunt watch - that's
enough of an argument alone for me to use it. Then add it in with a less
compiler and live reload, and less now is magically being compiled to css and
appearing in my browser a fraction of a second after I save a file.

Sure, you could write a script to do that, but by the time you've got it
working, you essentially wrote a grunt plugin, albeit one that isn't
extensible and doesn't have a community of thousands of developers writing
plugins and documentation for it.

------
zongitsrinzler
I think the use case of this author is very trivial. I don't see how I could
use npm for a much more complicated build process with different targets
(live, staging, local) or piping (coffee -> js -> min.js etc).

~~~
sehr
Not very familiar, but shouldn't those tools write to stdout?

------
zahary
I'm still waiting for the day when the JS community will discover tup [1].
Tup's greatest strength is that is can discover build dependencies
automatically by file I/O monitoring in any kind of compiler or build script.

Many source formats eventually gain the capability to include other files
(e.g. jade partials) or reference them in other ways (e.g. you can check the
size of an image while you are generating a Sprite CSS fragments) as part of
the build process and this is where Grunt or Gulp or any other naive build
system will fail immediately. Specialized build systems can handle the
dependency checking for particular build targets (e.g. Cmake for C++), but tup
makes it extremely easy to have proper minimal re-builds with any kind of
compiler.

There is also an automatic re-build mode that's triggered as soon as you save
the source file in the editor and it's a joy to use in web projects.

[1] [http://gittup.org/tup/](http://gittup.org/tup/)

------
jdub
Why don't people just use make?

~~~
pjmlp
Because it isn't portable, not even across UNIX/POSIX systems.

Each make has it own set of extensions outside of what POSIX requires.

Additionally, for almost every task you need to call out to external tools
that also have their own set of compatibility issues across UNIX/POSIX
systems.

Ideally everyone writing a Make script would need to read the POSIX standard
and only use common features, but since that isn't the case, scripts break
across systems.

This is what lead to autotools/autoconf creation.

~~~
rbanffy
> Because it isn't portable, not even across UNIX/POSIX systems.

How many realistic development choices fall in that category? Is anyone
actually doing development on IRIX or UNICOS?

~~~
pjmlp
You left out HP-UX, Aix, Tru64, Solaris, BSD, QNX, Mac OS X, IBM i, z/VM, eT-
Kernel/POSIX, LynxOS...

There are lots of POSIX systems out there.

~~~
rbanffy
I know people who develop (and use make) on BSD and OS X (I do), but,
seriously, is any OS on our lists (OS X, (Open)Solaris-derivations and *BSD
excepted) likely to be the target for the kind of software Grunt is used to
develop?

~~~
pjmlp
Most likely not, my point was just to pass the information specially to those
stuck in GNU/Linux, that it isn't as portable as many think it is.

~~~
rbanffy
GNU Make is probably available on all those platforms.

~~~
pjmlp
If it does, doesn't mean it is possible to use it.

------
ddoolin
> Of course, to get this Grunt configuration to work you'd still have to run
> grunt jshint in the terminal, which as it turns out is no shorter than
> jshint __.js.

That's only true if you're not using task arrays. I'm not sure what most
people are doing but that's covered all my bases so I run Grunt once and done.
Is installing a plugin really bloated? It's only 5 lines in the example but
they provide flexibility needed since many projects have different directory
structures and need different options.

I'd say that even if the plugin you wan't doesn't exist (and most do for
reasonably popular tools), well, make one for yourself. There's plenty of
documentation and countless examples.

It's strange that the author seemingly criticizes having to write a plugin for
yourself and then goes on to suggest something like you writing your own (if
you want dynamic options, etc you will be writing a wrapper around your
package.json).

------
TheAceOfHearts
I use Gulp to build all of our frontend dependencies and it's great. Before
that I was using Grunt, and it was alright. My only complaint was how
unbearably slow it was.

It's true that when you're just doing one-off things you probably don't need
something like Grunt or Gulp. For doing certain stuff, it's usually a lot
easier to call programs directly than trying to call it from Gulp, for
example: protractor.

What I do is I put all my tasks (some of which are Gulp tasks, others which
are just calling the executable directly) inside of the npm scripts section,
so you end up with a really nice consistent interface.

A lot of people get too caught up in small details when really most people
just wanna get their job done. Our build/dev processes are complicated enough
that using Gulp alleviates a lot of pains.

------
cnp
Being able to automate and coordinate our complex build system at work is
pretty much the only thing that keeps us all sane.... thanks to Gulp.

------
_Marak_
If you actually need to maintain well-used JavaScript projects, tools like
Gulp are extremely important and time-saving.

Here is what the build process looks like for the faker.js project:

return gulp.src('../index.js')

    
    
      .pipe(browserified)
      
      .pipe(rename('faker.js'))
      
      .pipe(gulp.dest('build/'))
      
      .pipe(gulp.dest('../examples/browser/js'))
      
      .pipe(rename({ extname: ".min.js" }))
      
      .pipe(uglify())
      
      .pipe(gulp.dest('build/'))
      
      .pipe(gulp.dest('../examples/browser/js'))
      
      .pipe(rename('../examples/browser/js/faker.min.js'));
      

});

[https://github.com/Marak/faker.js/blob/master/build/gulpfile...](https://github.com/Marak/faker.js/blob/master/build/gulpfile.js)

If you ask me, Gulp provides a pretty elegant syntax. Before using Gulp we had
a custom script to build the project. Using Gulp has been _much_ better.

His comments about the Gulp ecosystem not fully supporting streaming is true.
The onus of implementing streaming correctly in plugins is on the plugin
author. Unfortunately, there are a few plugin developers who are making bad
plugins. You have to understand which libraries you are installing before
blinding running npm install.

Something which is very interesting about Gulp is it's underlaying Virtual
File System (Vinyl)
[https://github.com/wearefractal/vinyl](https://github.com/wearefractal/vinyl)
The entire ecosystem is now improving as more Gulp plugins are being decoupled
into vinyl virtual file system adapters ( think sftp / http / ftp / webdav )

------
jeswin
I decided to code my own build library ([https://github.com/jeswin/fora-
build](https://github.com/jeswin/fora-build)) instead of Grunt. Documentation
needs to be better, so don't use this yet.

a) I wanted to use simple shell commands, like cp and mv. b) Instead of trying
to learn how to use a plugin, it's often easier to just write a few lines of
code. c) Wanted to use async goodness with generators. d)The important task
the build library does is "watching".

Couple of example build scripts:

1) [https://github.com/jeswin/fora/blob/master/server/build-
conf...](https://github.com/jeswin/fora/blob/master/server/build-config.js)

2) [https://github.com/jeswin/fora/blob/master/www-
client/build-...](https://github.com/jeswin/fora/blob/master/www-client/build-
config.js)

------
ing33k
In a project I worked recently we started using it because it was just "cool".
It only had a jshint task. but gradually as the project evolved we added lot
of tasks including minifying assets, configuring build for different API
endpoints ( prod.api/dev.api ) , creating a zip file and deploying the code .

------
likeclockwork
No. I refuse. I use CoffeeScript and SCSS and often install components via
bower. I like grunt watch+serve+livereload to drive my development server
environment. I like continuous testing with karma. Grunt helps me manage all
of this centrally. npm simply does not have the functionality to be a
legitimate replacement.

~~~
reitoei
Agreed.

------
BinaryIdiot
I've found Grunt useful as I ended up using it for a large variety of tasks
mostly related to building. However I also decided to stop using it but for a
different reason than the article.

Grunt and Gulp kinda create a siloed set of tasks that are annoying to run in-
line with the rest of the node application (different contexts). I never think
I'm going to run into it until I somehow run into a situation where I want to
run or re-run a specific task on an application that is already deployed. To
do so now I have to install grunt in a production system and restart the
application...or I simply code up my tasks into reusable bits of JavaScript
that the normal application can use plus I can use npm to run them under
normal conditions.

Honestly Grunt does help get things going really quickly but there are a lot
of immature things about it and Gulp.

------
rbanffy
I have some similar feelings about buildout
([http://www.buildout.org](http://www.buildout.org)). Both Grunt and Buildout
(and Maven and so many others) can do many things beyond running commands
based on their dependencies and that's what makes me uncomfortable with them:
they violate the do-one-thing principle. They try to do everything, be The One
Tool To Do It All.

I am myself guilty of somehow abusing make
([https://github.com/rbanffy/testable_appengine](https://github.com/rbanffy/testable_appengine))
and convince it to do things it was not really designed to do, but that's only
because make is so easy (and because it's already there on every machine I
touch - or shortly after I touch them).

------
cheshire137
Dude's big example was running a single tool with their Grunt/Gulp setup. Who
does that? I kept expecting the article to explain why using Grunt or Gulp was
a bad thing when I want to do multiple things at once without running multiple
scripts. What if I want my JavaScript to be hinted/linted, concatenated into
one file, and minified every time I save a JavaScript file, plus tests should
be run, plus I want the final JavaScript file to be saved in my build/
directory?

------
VeejayRampay
Just skimmed through the article and wanted to point out that it's a joy to
read. Clear, readable fonts, good use of spacing, great code snippets with
proper syntax highlighting, bravo to the author, I wish more technical
articles were going the extra mile like that.

------
petarb
The author's npm scripts approach is great for a small scale project needing
to run just jshint but if you start getting into something serious, running
more than one task multiple times is a serious dent in your workflow.

~~~
prottmann
I agree with that. I use npm commands for simple tasks.

And grunt/gulp for complex projects. grunt, cause it is simpler than gulp, but
only when it match the projects use case.

gulp for "live" things, like livereload or quick partial builds on
developement.

Startet now to use webpack too, it is comfortable (campared with grunt), it
does many build-stuff that you define in grunt by your own.

Like always, use the right tools to get the job done.

It exist not THE one and only tool that solve all problems in the world.

------
Kiro
This guy has obviously not built a large JS app if he thinks he can rely on
NPM for building. I actually thought he would promote Make, which would have
made much more sense.

------
santialbo
The title of the article is just a big click bait. Of course it's not worth it
using Grunt/Gulp when you are running one task at a time.

------
PSeitz
So how would I do a watch task, recompile less and minify js when files
changes? These tools are there for a good reason.

------
skrebbel
tl;dr: The author meant to say "Use Browserify instead of Grunt/Gulp" but then
got all confused and wrote some unrelated stuff about how npm has a case..esac
statement built in.

While we're at the subject, might I suggest using webpack instead of
browserify? It's roughly the same, but less buggy.

~~~
Kiro
How is Browserify/Webpack a replacement for Grunt/Gulp? Genuine question.

~~~
lerouxb
It isn't a replacement for Grunt/Gulp. It is a replacement for browserify or
perhaps require.js.

It builds your javascript and css (and images!) into one or more bundles which
does overlap with what people often use grunt for. In my experience it
generally obviates the need for grunt because what's left to do once you've
packaged and minified your js, css and images and you have your source maps,
etc.?

I suppose the rest can be done with npm scripts, but simple tasks like running
tests could even be done from bash or a makefile anyway.

Here's a good recent presentation on webpack:
[http://adrianrossouw.github.io/webpack-uber-
alles/](http://adrianrossouw.github.io/webpack-uber-alles/)

------
ilaksh
If you want something like grunt but simple you can try the thing I made which
is called 'bild'.

------
hw
i've used gulp for building frontend dependencies, as well as running
automated tests whenever a file changes. It's been working well, with the
exception that sometimes it just dies, and sometimes there's a failure and
some streams dont work properly.

------
ilaksh
My vote is for bash scripts. If you are in Windows then you can use babun or
preferably get off Windows.

~~~
Fannon
babun looks really interesting. So far I've worked with PortableGit + ConEmu
which works quite fine - just updating is not the nicest experience.

------
robodale
I found it funny that people are arguing something I've never heard about.

------
jamhan
segway -> segue

------
AustinScript
Good try I suppose. This didn't really click with me.

------
lhnz
As long as you're not trying to make the world's most complex build file do
not feel that you need to use overly complex build tools.

A better approach is to learn the basics of writing Makefiles.

Simple tools are good.

And Make is reusable.

Make also has the benefit that you can copy-paste lines into your shell to
test them. This is something that is very awkward to do with Grunt or Gulp and
it makes it a lot easier to debug problems.

Generally when I say it to people they say "but if you have a complicated
build process you need these tools!", and my response is "what business value
did your 400+ line build process create and will it be worth the inevitable
problems you will have to debug later?"

It might be unpopular advice but if you create a project with far less
dependencies then there is less that can break later on.

