When we were primarily a Flash shop, using JSFL was almost a necessity. We built everything from simple scripts to custom panels, even turning an internal tool into the official Project Panel in Flash Pro. Our tools’ scope also extended to building desktop applications using Adobe AIR. We built tools for creating spriteheets (Zoe), editing language files, generating ASdocs, and even creating the install badge for AIR itself. Each of these tools were rooted in making our daily work lives more productive, efficient, and enjoyable.
- Compiling Less & Sass files to CSS
- Managing assets like scripts, sounds, and images
- Creating page and component templates in html
- Deploying assets to a server
That’s a big list of items to manage, and without some sort of automation, it can be next to impossible for big projects.
It was blatantly evident we needed to define a clear criteria for our automation environment:
- Quick and easy for new developers to get up and running.
Grunt was the answer to all our build and automation needs, it was highly flexible, easy to set up, and cross-platform. Backed by npm’s huge repository of existing tools, developers began began writing custom plugins for Grunt. At the time of this writing, searching for “grunt” on npmjs.org yielded 11,322 results. That’s a lot to choose from. Grunt itself gets over 1 million downloads a month. The ecosystem is strong, and it’s showing no signs of slowing down.
Currently our default package.json file contains 19 different packages. One larger project has 28 pre-build tasks and 13 custom tasks. All these tasks can be configured once then run by a word or two:
Another huge benefit of Grunt is one person can tweak settings in the GruntFile.js and those changes are propagated to every member of the team via Git. Even though running Grunt is relatively simple, we have a diverse team of designers and developers, all with varying levels of familiarity with the command line. When pushing updates, telling designers to run
npm install or
sudo npm install; could fall outside of their comfort zone. One of our projects even requires that you pass a variety of arguments to grunt, since we’re able to deploy builds in various configurations. To solve this, we have simple run.command or run.bat files included in project repositories, a simple double-click will update npm and start Grunt.
Grunt’s popularity is also aided by its inclusion in IDE’s like WebStorm, which we use a lot internally. Grunt files can be inspected, and tasks can be run with the click of a button.
As mentioned, we use a wide variety of Grunt tasks to manage our workflows. Each project is unique, however a few favorite tasks/plugins are always used:
- grunt-contrib-sass or grunt-sass
Compiles our now preferred CSS pre-processor, Sass. We generally use grunt-contrib-sass for full sass support. More recently we’ve started using grunt-sass since the Sass compile times are much faster.
Our preferred template system, logic-less, fast, and simple to use.
Our projects are very CSS heavy and nobody likes to write browser prefixes, autoprefixer happily runs during a build making sure CSS is 100% cross-browser compatible.
Performance testing is crucial for any app, and grunt-throttle helps us test performance on slow connections. We run this process one port higher than the main one, so it’s a quick switch to run a throttled version of a site.
Will Grunt be our tool of choice a year from now? 2 years? 5 years? I don’t know. I just know we will keep on using whatever tool suits our needs best. Whether that tool is using custom scripts in BASH, PHP, AIR , node or utilizing existing tools like Grunt or Gulp.
For more in-depth discussion on Grunt vs Gulp check out these 2 awesome posts:
What kind of automation tools do you integrate into your daily workflow?