Why we should stop using Grunt and Gulp

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.

Make has really horrific syntax and semantics, and doesn't integrate as nicely if you're dedicated to JavaScript. I mean, the Unix philosophy is about small programs that work together, not "only use old Unix tools".

I'm reminded of https://news.ycombinator.com/item?id=5106767

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).

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.... 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... 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 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.

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.