This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
Grunt, Gulp, NPM… No, they aren’t sound effects found in the pages of your favorite comic book, but in the world of development what are they? Whether a sound effect or acronym these 3 examples are known as task runners and are becoming widely popular in front-end development
Task Runners are exactly that, a way to automate basic tasks that you would normally do within your front-end development projects like minification, linting, sass compiling, etc. These tasks are written in JavaScript and typically use modules from node (NPM) in order to complete them. While the tasks themselves typically use node modules, they also can just as easily use JavaScript with no modules at all. Each of these task runners typically have two files. One is a “package” file which is a simple JSON file to tell the script which modules it needs to download to complete the tasks; the other is a JS file that contains the tasks to run. Each task runner has its own flavor and handles the process a bit differently.
Grunt was one of the first widely used task runners and because of that has a large library of prebuilt tasks available to it. Grunt is pretty much as easy to use as finding one of the prebuilt tasks, reading the documentation, then installing it and configuring it for your project. Challenges with grunt include projects with a large amount of tasks can get very difficult to maintain and because of the way they are executed, it is not always clear what task gets called before another.
Gulp is the “new kid on the block” when it comes to task runners and build management. It has been able to take cues from the pain points of its predecessors in order to fix those problems for itself. Gulp is like Grunt in the sense that it relies on node plugins for most of its tasks and that it also takes advantage of the fact that these plugins are and have been, available. Gulp also fixes the non-declarative task running issue that Grunt had so it is much easier to know the order that your tasks are running. Another benefit is that Gulp uses Node streams to read files and pipe through functions in order to transform these into output that will then get written to the disk. This means that Gulp is a lot lighter processing wise than Grunt as well.
I saved this one for last because in my opinion this is the “Purist’s” approach. Where Grunt or Gulp may use some NPM modules or in the case of Gulp use Node to pipe through data, NPM is the underlying code being used. The great thing about NPM is all you really need is a package.json file and you are ready to go. Add in your tasks and run it. Like Gulp, this does not read/write from the disk at the time of building, this utilizes the pipe operator to do the file manipulation prior to writing the actual file to the disk saving valuable CPU processing power. NPM is not without its disadvantages though. NPM runs CLI tools and its Bash commands directly, which is great if you are a UNIX user but not so great if you are trying to run in a Windows environment.
So there you have it, a breakdown of the most popular task managers at the time of this writing as well as some pros and cons to each approach. I hope you can see how task managers can be a valuable tool for optimizing your workflow. Gone are the days of manually running each of your build tasks for a production deployment. Welcome to the future of build task automation. As with anything in the Front-End Development world new technologies are constantly coming out and there could be a new task runner being built as I write this very article. Have no fear though, I’ll be the first to let you know when POW! ZIP! or BANG! comes out.