Build tools are an essential part of every developer’s toolkit that lets you focus on efficient development without getting caught up in the small details that can distract you from the code at hand. One such popular build tool is Grunt.
We recently looked at how to use Gulp for WordPress development. Gulp is a fantastic tool that optimizes your theme’s images, concatenate your JS files, and processes your Sass/LESS code automatically.
While Grunt is similar to Gulp, there are some differences. In this post, I’ll walk you through what Grunt has to offer, how to use it, and how it’s different from Gulp.
Continue reading, or jump ahead using these links:
- An Introduction to Build Tools
- Getting Started With Grunt
- Creating Tasks
- Minifying Files
- Gulp and Grunt Compared
- Choosing Between Gulp And Grunt
An Introduction to Build Tools
A build tool is basically an automation tool that does menial tasks for you quickly and easily. You can create one file from many, convert documentation written in Markdown to HTML and do all sorts of other neat things, too.
In my recent Gulp article, I explained what a build system is, how you can use two different methods of organizing your files and a bunch of other basic stuff. I highly recommend you read that article before continuing to read this post. Apart from the syntax, the basic principles and the philosophy for both Gulp and Grunt is exactly the same.
Getting Started With Grunt
As with Gulp, you’ll need Node to run Gulp. If you don’t have it handy, head over to nodejs.org and grab the installer. Node will be installed, along with npm (node package manager), which can be used to install Node packages like Grunt.
Next we’ll install Grunt globally. You can do this by opening the terminal or command prompt in Windows (I will call both of them terminal from now on) and issuing the following command:
Next we’ll need to create two files: package.json and Gruntfile.js. Let’s start with package.json, which is a standard Node package file. We’ll only add a little bit of information, take a look at the npm docs for more.
The package file names our package and gives it a version number. What we’re really looking for here is the devDependencies section. This lists all the dependencies we’ll be using. For now, we just require Grunt itself – we’ll be adding more before long!
The Gruntfile.js is similar to the Gulpfile from Gulp – it tells Grunt what we want it to do and which commands we want it to respond to.
The initConfig() function is where we’ll write all our task contents. We’ll then register tasks below, which will tell grunt which ones it should run when we give it specific commands. I’ve created an empty default task for now.
Creating Tasks
The methodology of creating a task is similar to what we did for Gulp:
- Install the package
- Include the package
- Use it in the Gulpfile
Let’s begin with Sass, like we did in the other post. First, install the package:
Next, require the module in the Gruntfile.
All done! We can now write a task that will convert our Sass to CSS. Here’s the full code with an explanation below:
First order of business is including the module, which you can see just above the initConfig() function. Within said function I placed a task named sass. The options tell Grunt what the current working directory is (cwd), the source file for processing, the destination directory, and the file extension.
Finally, I’ve added the task to be run with the default command. Running grunt from the terminal will result in the styles/styles.scss being processed and output to styles.css in the main directory.
I think that it is apparent from this short example that Gulp is much less readable and logical than Gulp – at least to my taste. More on this later!
Minifying Files
If you want to minify those resulting CSS files you’ll need the grunt-contrib-cssmin module. Install it using the npm install grunt-contrib-cssmin --save-dev command and add it as a requirement by placing grunt.loadNpmTasks('grunt-contrib-cssmin'); in your Gruntfile.
Once all that is done, let’s do the actual minification. Here’s how:
As you can see it’s the similar idea as before. In addition to all that, I’ve added the task to my default command: grunt.registerTask('default', ['sass', 'cssmin'] );.
Gulp and Grunt Compared
If you’ve read the Gulp article and got this far in this article you should be able to figure out other methods I explain in the previous article. It’s a matter of installing the module and adding the task to your file. All packages have great documentation and example usage so you should have no problem implementing.
What you may be interested in, however, is what the differences between Gulp and Grunt are and when to use them.
The biggest difference between the two systems is task structure. The nutshell version is that Gulp is a lot easier to read but can be more confusing to write because the piping mechanism can lead to spaghetti coding within your tasks.
Personally, I prefer Gulp because I’d like my code to be readable so I know what the heck I wanted to do with it a year from now, just by glancing at it. If you’re working in a large team or on a huge project you might want to favour Grunt because of its stricter approach.
Another important factor is speed. Gulp is a lot faster because it handles everything in memory. Grunt uses intermediary files. Disk IO operations are way more time consuming than memory operations, making Grunt about twice as slow as Gulp.
That said, this isn’t a huge consideration for most. Does it really matter if a task takes 0.04 seconds or 0.08? On large scales this may become an issue but for a vast majority of us, we’ll never notice.
One thing I have noticed is that tasks, which aren’t very well-written, can cause instability within Gulp. This may well have been my idiocy, but I have seen some cases where Gulp froze on me for a second or two. I feel that this is a result of the fact that it uses memory, disk operations – in the case of Grunt – would not have this issue. This is completely unscientific, if any of you have some more in-depth experience with this, let us know!
For a while Grunt had a larger community since it was an older project. Recently Gulp has taken over, easily leaving Grunt in the dust. At this time, both solutions have sizable and active communities.
Choosing Between Gulp And Grunt
I’ve already weighed in on my preference– I go with Gulp every time. I find the way it is written and read a lot cleaner, the piping mechanism seems more logical to my mind. I think that this is actually the most important factor.
Since both systems are roughly the same it comes down to personal preference. Do you prefer Grunt because you like the style it provides better? Awesome, go for it.
There are only two cases I would suggest picking one over the other. If you’re already using one of them for most of your projects it’s probably a good idea to keep using the same solution. Despite Gulp’s speed advantage, I wouldn’t say it’s sooo much better that you should throw Grunt out the window.
The other case is if you really are handling a huge-huge list of tasks and a bunch of files. In theory, Gulp would serve you better but my recommendation is to write a couple of tasks using both systems and see which one works out better speed-wise.
Both Gulp and Grunt are great. They solve a huge number of issues, making our lives better every day. Whether you’re working on a WordPress project or something else, building tools are always a good idea.
Tags:
