Why we should stop using Grunt and Gulp

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.

I simply use Make for all my web projects, whether it&#x27;s a Ruby JSON API, or a React front-end. It&#x27;s reliable, pre-installed everywhere, and can wrap anything in one consistent CLI. Why have to remember whether to type <i>lein repl</i>, <i>pry</i>, or <i>rails console</i>, when <i>make repl</i> will do everytime? Ditto, <i>bundle install</i>, <i>npm install</i>, <i>lein deps</i> =&gt; <i>make deps</i>. <i>make server</i> can easily wrap whatever command launches the server, <i>make dev</i> can easily use a filesystem watching tool to restart <i>make server</i> on any change. And beyond that, <i>make</i> can be used as usual to &quot;compile&quot; the project, ie. run whatever static analysis and preprocessing is necessary in the web world (jshint, jsx etc.).

Regarding plugin dependencies, gulp maintains a blacklist of plugins that are not recommended for various reasons (bloat, poor design, unnecessary, etc): <a href="https://github.com/gulpjs/plugins/blob/master/src/blackList.json" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gulpjs&#x2F;plugins&#x2F;blob&#x2F;master&#x2F;src&#x2F;blackList....</a> They also link to an article about why you should resist the urge to create gulp plugins on their wiki: <a href="http://blog.overzealous.com/post/74121048393/why-you-shouldnt-create-a-gulp-plugin-or-how-to" rel="nofollow">http:&#x2F;&#x2F;blog.overzealous.com&#x2F;post&#x2F;74121048393&#x2F;why-you-shouldn...</a> Additionally, they maintain a collection of examples of common use cases that tend to send people searching for plugins unnecessarily: <a href="https://github.com/gulpjs/gulp/tree/master/docs/recipes" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gulpjs&#x2F;gulp&#x2F;tree&#x2F;master&#x2F;docs&#x2F;recipes</a> 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.

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.<p>This does not mean invoking compile manually on every file but you you invoke the <i>smallest possible</i> 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.<p>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&#x27;s like a completely new programming language just that it&#x27;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.<p>The only one that actually doesn&#x27;t make you cry is &#x27;make&#x27; because it&#x27;s so simple, it&#x27;s just doing one thing instead of trying to tie itself into the entire ecosystem badly. Make also has it&#x27;s problems but when you start hitting those it&#x27;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.

The author has a follow-up post that addresses a lot of things that are also popping up in the comments here: <a href="http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/" rel="nofollow">http:&#x2F;&#x2F;blog.keithcirkel.co.uk&#x2F;how-to-use-npm-as-a-build-tool...</a><p>EDIT: Also a HN submission by the author himself: <a href="https://news.ycombinator.com/item?id=8721929" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8721929</a>

What NPM can&#x27;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&#x27;m using Grunt.<p>Also some plugins are complicated (or dynamically) to configure. His examples were very simple, he could just put it into a batchfile aswell.

I can fully understand not liking Grunt, it&#x27;s configuration is impossible to read and doesn&#x27;t make a ton of sense to me. Gulp on the other hand is VERY easy to read and I haven&#x27;t have any issues with my colleagues adding&#x2F;editing the gulpfile.<p>Is running `gulp jshint` similar to running `jshint <i></i>.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&#x27;t jshint libs we didn&#x27;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&#x27;t mention how wonderful `gulp watch` (or similarly named task) is for watching files for changes and then running tasks when certain files change.<p>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&#x27;t touch make for web projects again.<p>Gulp (I won&#x27;t argue for Grunt, I don&#x27;t like it at all) is easy to write and easy to read and running the programs&#x2F;tasks Gulp does for us individually would have been a non-starter. As far as npm&#x2F;make goes it would have been harder to do everything we are doing and I&#x27;m not even sure `gulp watch`-type features would have been possible without escalated privileges to install other software.

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.<p>I am not sure if that justifies 70mb of additional dependencies and the &quot;we can solve that with a grunt plugin&quot; mentality devs get. Our Gruntfile is 440 lines long :&#x2F;

I don&#x27;t understand the attention this is getting - sure, you don&#x27;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.<p>However for work, it saves a stupid amount of time. grunt watch - that&#x27;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.<p>Sure, you could write a script to do that, but by the time you&#x27;ve got it working, you essentially wrote a grunt plugin, albeit one that isn&#x27;t extensible and doesn&#x27;t have a community of thousands of developers writing plugins and documentation for it.

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

I&#x27;m still waiting for the day when the JS community will discover tup [1]. Tup&#x27;s greatest strength is that is can discover build dependencies automatically by file I&#x2F;O monitoring in any kind of compiler or build script.<p>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.<p>There is also an automatic re-build mode that&#x27;s triggered as soon as you save the source file in the editor and it&#x27;s a joy to use in web projects.<p>[1] <a href="http://gittup.org/tup/" rel="nofollow">http:&#x2F;&#x2F;gittup.org&#x2F;tup&#x2F;</a>

Why don&#x27;t people just use make?

&gt; Of course, to get this Grunt configuration to work you&#x27;d still have to run grunt jshint in the terminal, which as it turns out is no shorter than jshint <i></i>.js.<p>That&#x27;s only true if you&#x27;re not using task arrays. I&#x27;m not sure what most people are doing but that&#x27;s covered all my bases so I run Grunt once and done. Is installing a plugin really bloated? It&#x27;s only 5 lines in the example but they provide flexibility needed since many projects have different directory structures and need different options.<p>I&#x27;d say that even if the plugin you wan&#x27;t doesn&#x27;t exist (and most do for reasonably popular tools), well, make one for yourself. There&#x27;s plenty of documentation and countless examples.<p>It&#x27;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).

I use Gulp to build all of our frontend dependencies and it&#x27;s great. Before that I was using Grunt, and it was alright. My only complaint was how unbearably slow it was.<p>It&#x27;s true that when you&#x27;re just doing one-off things you probably don&#x27;t need something like Grunt or Gulp. For doing certain stuff, it&#x27;s usually a lot easier to call programs directly than trying to call it from Gulp, for example: protractor.<p>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.<p>A lot of people get too caught up in small details when really most people just wanna get their job done. Our build&#x2F;dev processes are complicated enough that using Gulp alleviates a lot of pains.

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.

If you actually need to maintain well-used JavaScript projects, tools like Gulp are extremely important and time-saving.<p>Here is what the build process looks like for the faker.js project:<p>return gulp.src(&#x27;..&#x2F;index.js&#x27;)<p><pre><code> .pipe(browserified) .pipe(rename(&#x27;faker.js&#x27;)) .pipe(gulp.dest(&#x27;build&#x2F;&#x27;)) .pipe(gulp.dest(&#x27;..&#x2F;examples&#x2F;browser&#x2F;js&#x27;)) .pipe(rename({ extname: &quot;.min.js&quot; })) .pipe(uglify()) .pipe(gulp.dest(&#x27;build&#x2F;&#x27;)) .pipe(gulp.dest(&#x27;..&#x2F;examples&#x2F;browser&#x2F;js&#x27;)) .pipe(rename(&#x27;..&#x2F;examples&#x2F;browser&#x2F;js&#x2F;faker.min.js&#x27;)); </code></pre> });<p><a href="https://github.com/Marak/faker.js/blob/master/build/gulpfile.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Marak&#x2F;faker.js&#x2F;blob&#x2F;master&#x2F;build&#x2F;gulpfile...</a><p>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 <i>much</i> better.<p>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.<p>Something which is very interesting about Gulp is it&#x27;s underlaying Virtual File System (Vinyl) <a href="https://github.com/wearefractal/vinyl" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wearefractal&#x2F;vinyl</a> The entire ecosystem is now improving as more Gulp plugins are being decoupled into vinyl virtual file system adapters ( think sftp &#x2F; http &#x2F; ftp &#x2F; webdav )

I decided to code my own build library (<a href="https://github.com/jeswin/fora-build" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jeswin&#x2F;fora-build</a>) instead of Grunt. Documentation needs to be better, so don&#x27;t use this yet.<p>a) I wanted to use simple shell commands, like cp and mv. b) Instead of trying to learn how to use a plugin, it&#x27;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 &quot;watching&quot;.<p>Couple of example build scripts:<p>1) <a href="https://github.com/jeswin/fora/blob/master/server/build-config.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jeswin&#x2F;fora&#x2F;blob&#x2F;master&#x2F;server&#x2F;build-conf...</a><p>2) <a href="https://github.com/jeswin/fora/blob/master/www-client/build-config.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jeswin&#x2F;fora&#x2F;blob&#x2F;master&#x2F;www-client&#x2F;build-...</a>

In a project I worked recently we started using it because it was just &quot;cool&quot;. 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&#x2F;dev.api ) , creating a zip file and deploying the code .

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.

I&#x27;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.<p>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&#x27;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.<p>Honestly Grunt does help get things going really quickly but there are a lot of immature things about it and Gulp.

I have some similar feelings about buildout (<a href="http://www.buildout.org" rel="nofollow">http:&#x2F;&#x2F;www.buildout.org</a>). Both Grunt and Buildout (and Maven and so many others) can do many things beyond running commands based on their dependencies and that&#x27;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.<p>I am myself guilty of somehow abusing make (<a href="https://github.com/rbanffy/testable_appengine" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rbanffy&#x2F;testable_appengine</a>) and convince it to do things it was not really designed to do, but that&#x27;s only because make is so easy (and because it&#x27;s already there on every machine I touch - or shortly after I touch them).

Dude&#x27;s big example was running a single tool with their Grunt&#x2F;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&#x2F;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&#x2F; directory?

Just skimmed through the article and wanted to point out that it&#x27;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.

The author&#x27;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.

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.

The title of the article is just a big click bait. Of course it&#x27;s not worth it using Grunt&#x2F;Gulp when you are running one task at a time.

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

tl;dr: The author meant to say &quot;Use Browserify instead of Grunt&#x2F;Gulp&quot; but then got all confused and wrote some unrelated stuff about how npm has a case..esac statement built in.<p>While we&#x27;re at the subject, might I suggest using webpack instead of browserify? It&#x27;s roughly the same, but less buggy.

If you want something like grunt but simple you can try the thing I made which is called &#x27;bild&#x27;.

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

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

I found it funny that people are arguing something I&#x27;ve never heard about.

segway -&gt; segue

Good try I suppose. This didn&#x27;t really click with me.

As long as you&#x27;re not trying to make the world&#x27;s most complex build file do not feel that you need to use overly complex build tools.<p>A better approach is to learn the basics of writing Makefiles.<p>Simple tools are good.<p>And Make is reusable.<p>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.<p>Generally when I say it to people they say &quot;but if you have a complicated build process you need these tools!&quot;, and my response is &quot;what business value did your 400+ line build process create and will it be worth the inevitable problems you will have to debug later?&quot;<p>It might be unpopular advice but if you create a project with far less dependencies then there is less that can break later on.