Front-End Developer Toolbox: How Does Yours Measure Up?

If you’re like me, you started theming websites using plain old CSS and, like me, you probably griped about how long it took to theme something like a dropdown menu with hover and focus effects. Thankfully, some very smart people got fed up with the way we were forced to write CSS and came up with the idea of CSS Preprocessing.

CSS Preprocessors take a specific syntax of code and transform it into modern, browser-friendly CSS. They enable you to write code faster, keep your CSS "dry", and use variables and functions that should have been in CSS in the first place. While each preprocessor has its own syntax and method for outputting CSS, they all function in a similar manner. A recent poll by SitePoint found that 86% of front-end developers polled use some sort of preprocessor, with the top three being Sass, Less and Stylus.

I use Sass as my preprocessor of choice because I enjoy the flexibility and code control that it offers. It also gives me the ability to include vendor libraries like Compass and Bourbon and their advanced mixins. The use of mixins, extends and placeholders, along with the ability to import one stylesheet into another, allows me to build components of reusable code and to write leaner, cleaner styles which makes things not only easier to read but more performant as well. With components, I can insert and alter complex functionality as needed with minimal effort.

A good task runner is another key front-end tool. Task runners work behind the scenes to run scripts for spinning up development servers, compiling code, testing, concatenating and compressing files, and deploying code. Grunt and Gulp are two of the most common task runners. Gulp seems to be winning the popularity contest, but Grunt still has a strong user base.

Grunt focuses on configuration and is structured around a set of built-in tasks, with support from custom plugins in the community. Grunt tasks are completely independent of each other, which often requires code repetition because source and destination files must be specified per task. This makes Grunt a bit more work for projects with many tasks as well as making it slower than Gulp.

Gulp is built on streams and pipelines instead, and takes advantage of node.js to connect code and tasks into a seamless output. Think of it like the Sass of task runners. Gulp community plugins are highly-focused micro tasks that usually try to do a single thing. These plugins are piped together in a gulp.js file allowing them to be processed simultaneously, while Grunt processes one task after another. The Gulp processing method is also one of the reasons it runs faster than Grunt.

Skip the task runners?

A recent trend is to skip the task runner completely and use plain npm scripts. These are very small configuration scripts defined in a package.json file and run through the command line. The big advantage of npm scripts is that you are always up to date. If a package is updated, the run script will automatically use the updated version (unless specified otherwise). If the same package is used through a Gulp task, the newest version of the package would not be available for use until the Gulp dependency developer updated the plugin. The downside is that each npm script only does the one thing its designed for, unless you concatenate additional commands to the script, or add pre and post hooks to expand it. For complex tasks, trying to define enough pre and post script hooks to get a manageable command can get out of hand quickly.

I use Gulp in combination with npm scripts to compile my Sass, run Stylelint, spin up a local browser instance that syncs with any Sass changes, generate a sprite and Sass mixins from my SVG files, and numerous other tasks. Using Gulp with npm scripts means that I can run one command ‘npm start’ to kick-off all the tasks in my gulp.js, and any npm scripts I have concatenated to run on ‘start’ in my package.json file.