There is no denying that CSS was the first great revolution in the front end web world. Without it, think of what the web would look like; most likely, it would have remained limited to its academic origins, where style and design play a much less significant role than the multifaceted, visual web we have today.
In recent years, CSS has undergone a revolution of its very own, as preprocessors such as Sass, LESS, Stylus and others change our methodologies in creating our stylesheets. These tools allow for greater efficiency both in terms of creating the CSS and the final product that’s produced. I was slow to jump on the CSS-preprocessor bandwagon, but I am fully on board these days.
Once the NSCorp project was over, we knew we needed a new tool.
So we took up Grunt.js, and I have to say, it took me a little while to grok it. Fortunately, I have very smart friends such as Aaron Jorbin and Brian Watson who were kind enough to help me figure it all out. If you’re strictly a front-end developer, Grunt.js is a bit daunting, and if you’re not ingrained in the world of Node.js, it can be downright intimidating. If you’re just getting started with it, I cannot recommend enough Chris Coyier‘s excellent piece for 24ways, “Grunt for People Who Think Things Like Grunt are Weird and Hard“.
The biggest benefit of Grunt.js over CodeKit is the codification of rules. There is a master control file, Gruntfile.js, that lets you set out everything you want Grunt.js to manage, and even how to handle these tasks differently in different environments. (Think leaving your Sass with full comments and line numbers in development, but minifying the whole thing for production.) If you need to make a change, just edit the Gruntfile, commit it to your version control of choice, and it distributes itself out to your fellow team members.
Grunt is the tool we moved to after the NSCorp project, and I’m currently using it to build a responsive WordPress site for another client (more on that next month).
But wait, haven’t you heard? Grunt.js is dead, long live Gulp!.
I won’t lie and say I know anything about Gulp. From the article above, it’s supposed to be more straightforward and more intuitive to Node.js people. I’m not Node.js people, so I don’t know the implications of that.
But here’s my question for the room: should I abandon my brand-new workflow, after one project, for yet another new system? Is such a model of “use once then ditch for the next new shiny” a realistic way to do our jobs?
Yeah, I’ll probably spend a little time to look into Gulp and see if it offers significantly more than Grunt.js, both in terms of capabilities and in terms of ease of use (because if tools aren’t easy to use, what point is there in using them?).
But I would certainly like it if a tool stuck around long enough for me to master it. Or at least use it for a second project.