There will probably never be any build tool that gains more mass than what already exists as just a bash or a make script. And really nothing needs to. Healthy-sized communities have been built up around different build tool options where those that used it liked the style, it fit their platform, and they found it useful. Grunt feels like it’s on track to become a highlight build tool in the Js community. There are many using it already and more on the way.
Declarative vs. Procedural
Which style of project configuration is better? Declarative or procedural? Wars have been started with lesser words. I don’t feel like it’s a question of better. It’s just a matter of style. There are pros and cons. Where you do the many of same things as everyone else, declarative works just fine. When you have to do new, original things, you have to write code to support that. You might wrap that in a grunt plugin to encapsulate it then write declarative options to feed it. But, you still own the plugin implementation.
One of the main sellings points for NodeJs is that it is built from the ground up for using in asychronous environments and problems. Build scripts aren’t generally asynchronous. Usually, it’s quite the opposite. Step 1 leads to step 2 and so on. You can’t skip, and future steps rely upon completion of the previous.
In this way, NodeJs/Grunt seems like an awkward fit as a build tool.
Shell Commands in Grunt
When I end up doing custom things in my Grunt build, it tends to be that I’m trying to get to the shell and execute something. If I have a shell script, I can just execute it with grunt-exec. If I’m trying to keep all logic in Grunt, I’ll use shelljs. The thing that gets me with both of these solutions is that I’m in Node, constantly trying to get out of Node to run something in the shell, like a git command. So my code ends up looking like lots of these:
1 2 3
There’s a bit of cruft to recreate bash in Node. It’s not as clean and does not read as well as a vanilla shell script might:
Grunt does quite a bit for you. It’s now up to me to go figure out all the cool stuff it can do. Once I found the file API, I was excited and retained a touch of the nagging feeling I just mentioned related to shell commands.
Builds Scripts as Plugins
When you come up with a new Grunt task that is obviously useful for someone else out in the world, you’ll likely generalize it and publish it to npm. There already a good number of ‘gruntplugin’s out there. This is a great sharing mechanism that not every build tool environment will give you. I’m grateful for the good Grunt plugins shared out there.
Grunt, by default, has a declarative configuration style. This means lots of json, often long and nested. It’s all organized by task names, so it’s fairly easy to find stuff. But the bottom line is that there is a fair bit to navigate in the average grunt file.
Breaking Changes in Grunt API
As of this writing, Grunt 0.4 is on the verge of release. By all accounts it will make things better, and it looks promising. They have a mostly-straightforward migration guide. The thing that has been the most painful is the lack of backward compatibility. My current, working builds rely on Grunt plugins that are not 0.4 compliant, so I have two choices: Help each of those plugins upgrade or wait until 0.4 reaches critical mass – ie, most worthy plugins are upgraded.
Grunt is Fast
Grunt is faster than Pumba being chased by a hyena. Previous to Grunt, we were using Maven to do similar tasks. Now we do more (Grunt has made it easy for us to incorporate more good practices – eg, linting), and the build is done is a serious fraction of the time. The speed is super dependant on what operations the build actually performs, but my impression for my builds is that Grunt is fast.
The Grunt Logo
Yes, it’s superficial, and it’s even a lame reason, but I like Grunt because they have a great logo. Wild boar for logo? Instant win. (That is what it is, right?)
So, is Grunt helping you out? What are your impressions? Or are you using something else entirely?