Grunting with GruntJS

I have been working on a team using a diverse tech stack: PHP, MongoDB, EmberJS and requireJS. Since we intend to release the alpha version in a few weeks insha Allaah, I had to bring everything up to production-ready levels. The usual needs: Javascript linting and obfuscation, resource (JS, CSS + images) minification, test automation (unit + functional) and a few others.

One thing I like about the project is that it gives us a chance to explore and try on new technologies – the best way to learn something is to implement in it. From EmberJS for MVC JavaScript to requireJS for AMD (helps to maintain code sanity) and now GruntJS for automation (I have been yearning to try out Grunt for looooooooooooooong).

GruntJS was written by Ben Alman, same guy who wrote tinypubsub. He wrote it because found it difficult to set up his loads of projects easily. It is in the same category of tools like make, maven, ant and rake. Unlike these tools, Grunt is refreshing and a cinch to grasp – the simple ‘JavaScript-y’ approach got me sold. Also, there are an immense number of 3rd-party add-ons that send give programming bliss; I agree it might not be as flexible as other tools (can you grunt Java? Doubt it) but it does what it needs to do and does it well. That’s all I need for now…

My team’s current Gruntfile config includes options for linting, minification, obfuscation, SASS compilation, live reload, qunit testing for unit testing and also casperjs for functional testing. All tests are run against a phantomjs headless browser.

Lessons? Never take on a side project without learning something new. So what else? Here are a couple of reasons why you should consider GruntJS:

1. Standardized interface – it defines a completely repeatable method for defining tasks.

2. Great community – there are one gazillion plugins, tutorials and blog posts on why you should use Grunt.

3. Plugins for nearly every web dev work you’ll do – I personally love the watch tasks that reload the browsers.

4. The learning curve is almost non-existent; I love easy-to-use stuff.

5. Grunt is powerful – it packs a punch!

6. Flexible, I found out that you can actually invoke command line arguments and run new programs.

6 thoughts on “Grunting with GruntJS

  1. I started Grunting last month & its simply amazing. On 2 of our projects, we are using similar tools with a few minor differences – Node.js (server-side), Underscore.js, Backbone.js (front-end), Jasmine (testing). It would be great to know what your other experiences with these slick technologies are.

    And ‘Hey!’, I’m looking for adventurous hands to work (remotely) on our internal & external projects.

    aniediudo [at] gmail [dot] com


    1. Awesome to hear about your use of GruntJS!

      I actually evaluated backbone and EmberJS and chose the latter – I believe both are excellent however EmberJS is my preferred choice. Underscore looks great – I checked it out some time ago, however I am not using it. Finally, no server-side JS for me for now; I’ll love to learn it but I have got my hands terribly full now.

      Do you remember we met at the 2010 G-Nigeria in Unilag? :)


  2. Nice intro!

    “I had to bring everything up to production-ready levels”
    Is your Scrum increment not already at production-ready levels at the end of each Sprint (I.E. potentially releasable)?
    To gain the maximum benefit out of “The usual needs: Javascript linting and obfuscation, resource (JS, CSS + images) minification, test automation (unit + functional) and a few others”.
    They need to be running on every Increment (Sprint). Otherwise, you’re not getting maximum benefit.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.