Toolbox top shelf filled with used tools.

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

October 18, 2017| by Adam Fuchs

Front-end development in 2017 is a complicated and constantly shifting landscape of frameworks, trends, libraries and strategies. It seems like there is a new ‘must use’ tool every few months. It can feel as though you’re drowning in quicksand trying to keep your head above the latest trends. 

When you look at your front-end tool box, do you feel more like Bob Vila or Bob Saget? 

Bob Vila in front of drywall with arms crossed
Bob Saget with arms crossed



Before we go any further, let's make sure we're on the same page for the terms I'm about to use. By front-end developer, I'm referring to the good folks working on the client-side of a website, specifically the parts of a website that a visitor sees and interacts with directly. As a front-ender, you’ll need tools that allow you to manipulate HTML, CSS, and JavaScript as quickly and easily as possible. Having something to check your work is a good idea as well. 

My must haves for a good front-end toolset are:

  • CSS Preprocessor

  • JavaScript Framework or Library

  • Task Runner

  • Lint or Debug program

(Note that there are many other tools not covered here, such as your choice of computer, your IDE and other software. For this article, let's just cover the libraries and frameworks.)

CSS Preprocessors

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.

sass logo

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.

Javascript Framework or Library

There are a lot of tools to help write JavaScript, but what exactly are they? What’s the difference between a framework and a library? What are the benefits of each?

A framework is a structure imposed on JavaScript to solve a specific problem or provide a consistent or simpler way of coding. Think of it as a template or set of rules for your code which is then output through the framework and its attendant libraries. Frameworks enable you to build component pieces (or to use existing components in the framework's libraries) and call them as needed with script while building your site. React, Angular, and Backbone are popular frameworks.

React js logo
Angular JS Logo
Backbone js logo

A library is a toolkit meant to do specific, well-defined tasks. It makes it easier to write JavaScript without forcing the way in which you write it. You can plug and play the existing scripts as needed to get the outcome you want. While being more flexible and variable than frameworks, libraries can also be more difficult to master and more of a performance burden if used incorrectly. jQuery and MooTools are common libraries.

Jquery logo
Mootools Logo

I’ve been a jQuery guy since I started my first web project ever, but the increasing popularity and stability of frameworks definitely make them an attractive choice. React and Angular seem to still be fighting it out for position as the most popular framework but React is supposed to be a bit easier to learn and if you’re a Drupal front-end developer, getting to know React is definitely a good idea given the recent push to use React for Drupal’s administrative UI’s.

Task Runner

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.

Lint and Debug

We’ve covered writing fun and fancy CSS through a preprocessor, using a framework or library to take the pain out of JavaScript, and putting a task runner to work bring it all together. Lastly, we need a proof reader. Some way to know that what we built is working or tell us what’s wrong.

Think back over all the time you’ve spent trying to find a missing semicolon or unclosed bracket that brought a project to its knees, while you manually scanned 1000s of lines of code to figure out what you did wrong. Wish you had that month or so of your life back? Tools like Stylelint, ESLint, and your browser’s built in development tools will not get that time back for you, but they will help prevent that pain from happening again.

Stylelint logo
ESLint logo

Stylelint and ESLint are command line lint programs that comb your code and compare it against a set of specified rules. You can write your own rules, use an existing library, or a combination of both. Your linting can be targeted to follow a set of best practices, just the rules you most care about, or help you overcome bad coding habits.

For instance, you can lint your Sass with Stylelint to show an error when you use spaces instead of tabs, leave too many blank lines after a block, or miss a semi-colon. ESLint can lint your javascript to detect if you are missing a bracket somewhere or have a comparison in which both sides are the same. For more in-depth information on Sass linting with Stylelint read my recent blog post Sass Lint: or How I Learned to Love the Lint.


Another critical front-end tool is web browser developer tools. Firebug was an early version of these tools, available in Firefox, but now all browsers come with a set of developer tools. These developer tools allow you to inspect your CSS and HTML, test and debug style rules directly in the browser, and look for errors in the JavaScript console. A browser like Chrome even allows you to slow and stop animations, set the color scheme of the inspector, view print styles, and expand minified CSS and JS source files.

The Final Word

Front-end developer tools come and go, and the choices are many– Sass or Less, Grunt or Gulp, React or jQuery. The key is to understand what each set of tools can do, and to choose the right one for you. Even though we’ve only scratched the surface of preprocessors, JavaScript helpers, task runners and front-end debugging, hopefully you feel a little more confident in going to the hardware store, finding the right tool and hammering in some nails.

And if you don't know who Bob Vila or Bob Saget is, you're probably younger than me!

photo of adam fuchs wearing a dress shirt

About the Author:

Adam has a BFA in graphic design from the Minneapolis College of Art and Design, and has been specializing in web design and development since 2013, working with a variety of large and small clients. More about Adam »