Why we should stop using Grunt and Gulp(blog.keithcirkel.co.uk)
blog.keithcirkel.co.uk
Why we should stop using Grunt and Gulp
http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/
107 comments
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.
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.
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
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
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.
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.
I also use grunt-shell a great deal rather than find/write a new plugin, pretty decent way to call out to bash.
Show me one task in your Gruntfile that is complex.
grunt-shell also just wraps child_process.spawn which is already trivial.
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.
Not saying it's better than make or something else, but it's easy for everyone on the team to use & modify.
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.
What you instead could have had was a simple script running the tools with the proper command line arguments.
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?
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?
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.
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.
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.
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.
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.
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.
I agree, I'm just not buying his idea as a real alternative for projects at scale.
I just feel sorry for anyone who has to deal with '13 other things' in their build.
[deleted]
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.).
We default to Make too since we're all (all two of us) running a *nix OS. I'm currently sub-contracting for an agency with devs all running Windows so I'm hoping `npm run` works well enough. If I had it my way I'd just tell them to install MinGW but they might take that as me telling them to go fuck themselves.
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.
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...
Same thing for any external tool used in the scripts.
Unless you make sure only to use these features
http://pubs.opengroup.org/onlinepubs/009695399/utilities/mak...
Same thing for any external tool used in the scripts.
Thankfully most of us can safely disregard all but a tiny subset of POSIX-like systems.
And its different for Windows users who want to use Grunt, how exactly?
It's different in the way that it's trivial to use npm to install grunt and run builds on Windows, but not trivial to get a Makefile to run (if you don't want to resort to running cygwin bashs all the time).
You can't use make to install grunt on Windows?
You have to install make some how. That's the problem. You're tying all these cross platform tools together with something that isn't cross platform. Grats.
You can make your life difficult if you so desire, but you can also simply install Cygwin and be happy.
my recollection from my windows times, is that cygwin is a pain to install and slow too, so there is no free lunch.
> is a pain to install
They have a setup.exe that downloads the components you select. I gather it's not as painless as "apt-get install cygwin" would be, but it's as painless as installing Windows software is.
> and slow too
They are painting a Linux-environment on top of a Windows OS. That's no small feat. In return you get a sensible file space, a decent command line and all the development tools you'd need on Linux. It's slower than a Linux box running on the metal, but it's as fast as a VM would be and has direct access to the host operating system (and, for me, a working Python environment where I can simply say "pip install ipython" and everything just works. I would not even consider working from Windows without it.
They have a setup.exe that downloads the components you select. I gather it's not as painless as "apt-get install cygwin" would be, but it's as painless as installing Windows software is.
> and slow too
They are painting a Linux-environment on top of a Windows OS. That's no small feat. In return you get a sensible file space, a decent command line and all the development tools you'd need on Linux. It's slower than a Linux box running on the metal, but it's as fast as a VM would be and has direct access to the host operating system (and, for me, a working Python environment where I can simply say "pip install ipython" and everything just works. I would not even consider working from Windows without it.
Make works great in cygwin.
> Why have to remember whether to type lein repl, pry, or rails console, when make repl will do everytime?
This is why I don't think the CLI is a very efficient interface for operating the computer. There are more commands than you can remember so, you're forced to take the commands that you can't remember or be bothered to type in and stick them into a file, thereby creating new commands that must be identified, understood and remembered by the next developer who should really only use them if they know all of the original commands in the file.
This is why I don't think the CLI is a very efficient interface for operating the computer. There are more commands than you can remember so, you're forced to take the commands that you can't remember or be bothered to type in and stick them into a file, thereby creating new commands that must be identified, understood and remembered by the next developer who should really only use them if they know all of the original commands in the file.
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.
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.
Hmm, I don't think not fully understanding existing tools and not wanting to read documentation is a good reason.
You can easily add prompting with maven, gradle etc, test result reporting, source control integration is all built in.
The 150 flags you mention provide flexibility, you dont need to know them all to get started. With your custom build process, instead of finding a flag that does what you need, you need to implement what you need from scratch, and document it for future developers.
If you use a standard build tool its also easier to hire someone who already knows it, plus understanding them will help you fit into new teams easier.
Unless maybe this is for personal projects, in which case I think its probably less of an issue
The 150 flags you mention provide flexibility, you dont need to know them all to get started. With your custom build process, instead of finding a flag that does what you need, you need to implement what you need from scratch, and document it for future developers.
If you use a standard build tool its also easier to hire someone who already knows it, plus understanding them will help you fit into new teams easier.
Unless maybe this is for personal projects, in which case I think its probably less of an issue
> The only one that actually doesn't make you cry is 'make' because it's so simple,
I imagine you never wrote Make scripts that had to be portable.
I imagine you never wrote Make scripts that had to be portable.
> Gradle requires you to read the first 12 chapters of the manual before you can even begin doing something more advanced than running compile
The purpose of Gradle, like other products in the Groovy echosystem, is to sell consulting fees and conference seats for their backers, in this case Gradleware. Hence providing easy-to-use doco would defeat the point of the product.
The purpose of Gradle, like other products in the Groovy echosystem, is to sell consulting fees and conference seats for their backers, in this case Gradleware. Hence providing easy-to-use doco would defeat the point of the product.
You still have to get all tools to all build environments (developer computers, build servers). For javascript you can write the build script in javascript without Gulp, Broccoli or Grunt, it works great. But you still want some tools to be installed and then you probably start to use NPM anyway.
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?
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?
> 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.
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.
>And you know, these things are standard stuff that one would like to do for every project
And its totally stupid, and the stupid persists, because 'its standard' now. This is how stupid stuff becomes standard - people say "hey, this stupid stuff - its standard now".
You're using the argument that its a good thing to have to do all of that stuff with one tool .. really? (Besides, Make can do all of that - you just have to configure it to do so, like any other tool..)
And its totally stupid, and the stupid persists, because 'its standard' now. This is how stupid stuff becomes standard - people say "hey, this stupid stuff - its standard now".
You're using the argument that its a good thing to have to do all of that stuff with one tool .. really? (Besides, Make can do all of that - you just have to configure it to do so, like any other tool..)
It's interesting to watch the commentors to your post say the way to fix the problems with tools is with a tool to fix the tool which is at least one of the issues outlined in the article.
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...
EDIT: Also a HN submission by the author himself: https://news.ycombinator.com/item?id=8721929
EDIT: Also a HN submission by the author himself: https://news.ycombinator.com/item?id=8721929
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/
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/
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.
Also some plugins are complicated (or dynamically) to configure. His examples were very simple, he could just put it into a batchfile aswell.
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...
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...
I think Broccoli looks great for simple watch things.
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.
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.
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 :/
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 :/
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.
Then I found out what it was actually doing, and replaced it with a small shellscript that NPM calls.
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.
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.
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).
Not very familiar, but shouldn't those tools write to stdout?
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/
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/
Why don't people just use make?
It's hell for those of us outside of the Unix ecosystem. I have MSYS on my Windows machine and make works only half of the time.
Also the learning curve is just not as easy, nor the files as readable. With Gulp and Grunt you are exploiting the fact that almost everyone can write a couple of lines of JavaScript. The only thing you are adding is an api composed of three to four functions.
If you look at make on the other hand, you'll need to learn quite a lot.
http://www.gnu.org/software/make/manual/make.html
Also the learning curve is just not as easy, nor the files as readable. With Gulp and Grunt you are exploiting the fact that almost everyone can write a couple of lines of JavaScript. The only thing you are adding is an api composed of three to four functions.
If you look at make on the other hand, you'll need to learn quite a lot.
http://www.gnu.org/software/make/manual/make.html
Yes I'm on windows and already had the case of a npm package I would have liked to contribute but the build process was using make, couldn't make it work...
It's a bit disapointing when you have a very good multiplatform ecosystem to see stuff like that, sometimes it's people "forgetting" there's also windows (and I can get that), but some other times it's just a big "fuck you windows user".
It's a bit disapointing when you have a very good multiplatform ecosystem to see stuff like that, sometimes it's people "forgetting" there's also windows (and I can get that), but some other times it's just a big "fuck you windows user".
The general sentiment has been "fuck you linux user" for so long now, it's funny to see how things have changed in the last 15 years or so.
I'm not sure what precisly you're referring to (proprietary software/drivers?), I love linux, used it almost exclusively for 5 years before my current .NET job.
I'm talking here about pure javascript npm packages, something you can legitimatly expect to be able to build on windows and yet some people make childish judgements on windows users and choose tools which exclude a part of the community (not always the case or the reason but it happens).
On a similar subject, I stopped counting the times I've seen someone get told to get a Mac when discussing a problem on cross platform tools.
I'm talking here about pure javascript npm packages, something you can legitimatly expect to be able to build on windows and yet some people make childish judgements on windows users and choose tools which exclude a part of the community (not always the case or the reason but it happens).
On a similar subject, I stopped counting the times I've seen someone get told to get a Mac when discussing a problem on cross platform tools.
One reason might be so that contributors on Windows don't have to install cygwin and nobody has to worry about the differences between various flavors of make. If you want things to work cross-platform, it's easier to start with a portable language.
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.
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.
But autotools/autoconf solve a whole set of different cross-platform problems to "make runs and does things". The make syntax doesn't change across platforms; nor does the sh syntax. What you execute might change, but I'm not sure that's too much of a problem for the usual web pipeline use case.
> 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?
How many realistic development choices fall in that category? Is anyone actually doing development on IRIX or UNICOS?
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.
There are lots of POSIX systems out there.
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?
People are scared of significant whitespace or old software or something.
I'm not sure how serious your comment is but this was one of the reasons for the invention of Apache Ant.
For years, the front page of Ant had a rant towards Makefiles on it, including this highly unprofessional quote: '"Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times.'
https://web.archive.org/web/20100203102803/http://ant.apache...
They only removed it in 2010 with the release of 1.8.0.
For years, the front page of Ant had a rant towards Makefiles on it, including this highly unprofessional quote: '"Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times.'
https://web.archive.org/web/20100203102803/http://ant.apache...
They only removed it in 2010 with the release of 1.8.0.
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'm reminded of https://news.ycombinator.com/item?id=5106767
The "horrific syntax and semantics" claim seems pretty drive-by, the variables and some function names might be arcane, but newer releases have nicer aliases for those who care for them. I don't know what is so horrific about the semantics though, they are pretty straightforward. A Makefile is a set of rules, each rule being a target file, its dependencies, and the recipe to turn the dependencies into the target. Make can figure out which steps need to actually run based on the states of the targets and dependencies (prereqs in Make terms). It's a really powerful way to describe the relationships and transformation steps for files, and you get partial builds for free! Not that make is without problems (the initiative behind DJB's redo addresses them at length) but unsubstantiated FUD isn't necessary.
> unsubstantiated FUD isn't necessary
Sure.
...but to be fair, regardless of the make syntax, you've also got to look at the history of make, and what it's designed to achieve.
Make is for executing shell commands on file patterns with dependency rules.
It's not designed to use an ecosystem of plugins or have long running processes (eg. to run a local server or watch for file changes). It's not designed to be a scripting language (although it can be, since it's technically turing complete).
Now, when you look at other things which have come along to replace make as a build tool: cmake, grunt, gulp, ant, rake, maven, scons, premake, etc.
I think it's probably a little bit superscillious to suggest that all the people building these tools were just too retarded to realize how good make was.
More likely, they had specific needs that make didn't address.
Rust, for example, just recently had a reasonable make based solution, but they decided to depreciate it in favour of cargo, because it was simply too difficult to support in an appropriate cross platform manner.
Make isn't a bad tool; for very doing some specific things. Specifically building c code on unix-ish systems.
Is it the right tool for fetching the dependencies of and invoking a large set of ruby/javascript/python scripts and plugins to build the assets for a website, running a local development server and watching file changes and pushing livereload changes to the browser as the files change?
No. Make is absolutely rubbish at doing those things.
...not because make is rubbish, but because it's not for doing those sorts of things.
Sure.
...but to be fair, regardless of the make syntax, you've also got to look at the history of make, and what it's designed to achieve.
Make is for executing shell commands on file patterns with dependency rules.
It's not designed to use an ecosystem of plugins or have long running processes (eg. to run a local server or watch for file changes). It's not designed to be a scripting language (although it can be, since it's technically turing complete).
Now, when you look at other things which have come along to replace make as a build tool: cmake, grunt, gulp, ant, rake, maven, scons, premake, etc.
I think it's probably a little bit superscillious to suggest that all the people building these tools were just too retarded to realize how good make was.
More likely, they had specific needs that make didn't address.
Rust, for example, just recently had a reasonable make based solution, but they decided to depreciate it in favour of cargo, because it was simply too difficult to support in an appropriate cross platform manner.
Make isn't a bad tool; for very doing some specific things. Specifically building c code on unix-ish systems.
Is it the right tool for fetching the dependencies of and invoking a large set of ruby/javascript/python scripts and plugins to build the assets for a website, running a local development server and watching file changes and pushing livereload changes to the browser as the files change?
No. Make is absolutely rubbish at doing those things.
...not because make is rubbish, but because it's not for doing those sorts of things.
> Make is for executing shell commands on file patterns with dependency rules.
Yep absolutely. Make is a system for generating files from other files, it is that simple. Compiling templates and code, generating source maps, concatenating, minifying -- many of these tasks all fall under that umbrella.
> It's not designed to use an ecosystem of plugins or have long running processes (eg. to run a local server or watch for file changes).
You're right, I wouldn't advocate that either. Procfiles and tools like foreman (and it's various reimplementations, like honcho) are for managing those processes: development servers, file watchers, etc. That's actually my own personal approach, I go for the Makefile/Procfile combo and run `foreman start` to boot up the a server and any other processes that project might need. Works pretty well for me.
> Make isn't a bad tool; for very doing some specific things. Specifically building c code on unix-ish systems.
That's a pretty narrow view, like I said earlier, it's good for any application where you're generating files from other files. Building an ebook, managing unwieldy SSH configurations (smdh at lack of include directive in SSH config), etc.
So yeah I agree make is no good at being an all-in-one everything-and-the-kitchen-sink suite. And that's great. It has one job and does it well enough, and is even better complemented by other tools. Some people like the suite approach better, but I wouldn't disparage make for something it wasn't intended to do to begin with.
Yep absolutely. Make is a system for generating files from other files, it is that simple. Compiling templates and code, generating source maps, concatenating, minifying -- many of these tasks all fall under that umbrella.
> It's not designed to use an ecosystem of plugins or have long running processes (eg. to run a local server or watch for file changes).
You're right, I wouldn't advocate that either. Procfiles and tools like foreman (and it's various reimplementations, like honcho) are for managing those processes: development servers, file watchers, etc. That's actually my own personal approach, I go for the Makefile/Procfile combo and run `foreman start` to boot up the a server and any other processes that project might need. Works pretty well for me.
> Make isn't a bad tool; for very doing some specific things. Specifically building c code on unix-ish systems.
That's a pretty narrow view, like I said earlier, it's good for any application where you're generating files from other files. Building an ebook, managing unwieldy SSH configurations (smdh at lack of include directive in SSH config), etc.
So yeah I agree make is no good at being an all-in-one everything-and-the-kitchen-sink suite. And that's great. It has one job and does it well enough, and is even better complemented by other tools. Some people like the suite approach better, but I wouldn't disparage make for something it wasn't intended to do to begin with.
Great explanation of limitations of make. Regarding when someone says make i availible everywhere and forgets Windows I think we can start saying Javascript/Node is everywhere (not preinstalled but easily availible). It is probably more true.
FWIW, I do use make. I could not deal with gulp’s issues[1], so I wrote a little thing of my own, just to quickly whip up websites for my projects[2].
[1]: https://github.com/gulpjs/gulp/issues/651
[2]: https://cannot.mietek.io
[1]: https://github.com/gulpjs/gulp/issues/651
[2]: https://cannot.mietek.io
Is there a way to do a filewatch -> sass -> livereload with make? That was the primary reason for me using grunt.
I wouldn't use make for file watching and live reloading. I would express the Sass and CSS dependencies in a Makefile, and then describe the dev server, file watching[1], and live reloading[2] processes in a Procfile, using something like foreman[0].
[0]: http://ddollar.github.io/foreman/ [1]: http://entrproject.org/ [2]: https://www.npmjs.org/package/livereload
[0]: http://ddollar.github.io/foreman/ [1]: http://entrproject.org/ [2]: https://www.npmjs.org/package/livereload
Jake is pretty nice.
http://jakejs.com/
http://jakejs.com/
Because it's not the new cool thing obviously.
> 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).
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).
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.
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.
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.
Here is what the build process looks like for the faker.js project:
return gulp.src('../index.js')
https://github.com/Marak/faker.js/blob/master/build/gulpfile...
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 The entire ecosystem is now improving as more Gulp plugins are being decoupled into vinyl virtual file system adapters ( think sftp / http / ftp / webdav )
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...
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 The entire ecosystem is now improving as more Gulp plugins are being decoupled into vinyl virtual file system adapters ( think sftp / http / ftp / webdav )
I decided to code my own build library (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...
2) https://github.com/jeswin/fora/blob/master/www-client/build-...
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...
2) https://github.com/jeswin/fora/blob/master/www-client/build-...
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 .
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.
Agreed.
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.
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.
I have some similar feelings about buildout (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) 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).
I am myself guilty of somehow abusing make (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).
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?
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.
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.
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.
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.
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's not worth it using Grunt/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 "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.
While we're at the subject, might I suggest using webpack instead of browserify? It's roughly the same, but less buggy.
How is Browserify/Webpack a replacement for Grunt/Gulp? Genuine question.
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/
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/
They have their own plugin/watching systems, I'm trying webpack on a project and I'm just starting it with a "npm run" command.
What are the most serious bugs in browserify?
If you want something like grunt but simple you can try the thing I made which is called 'bild'.
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.
I found it funny that people are arguing something I've never heard about.
segway -> segue
Good try I suppose. This didn't really click with me.
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.
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.