Front end build tools can be confusing even to experienced developers like me. The solution is to understand how they work — and work together — on a conceptual level.

This article presents my opinionated approach to making sense of front end build tools. Instead of diving into code, I’ll walk you through my mental model of how these tools work and what they accomplish.

Don’t be intimidated by the state of the art

Node, NPM, Grunt, Gulp, Bower, Webpack, Browserify, Yeoman, Brunch… there are so many front-end build tools out there that it can seem impossible to keep up.

The key is not being intimidating. All of these projects are designed to make your life easier.

To understand the what, why, and how of these tools, you just need to grasp a few concepts.

Concept #1 — The core dichotomy of build tools is “installing vs. doing”

Build tools do two things:

1. Install things
2. Do things

The first question to ask yourself when confronting a new build tool is: “Is this tool intended to install things for me, or do things for me?”

“Installing” tools like npm, Bower, and Yeoman can install pretty much anything. They can install front-end libraries like Angular.js or React.js. They can install servers for your dev environment. They can install testing libraries. They even help you install other front end build tools.

In short, they install most any code-related things you can think of.

The “doing” tools like Grunt, Webpack, Require.js, Brunch, and Gulp are much more complicated. The goal of the “doing” tools is to automate all the menial and error prone tasks in web development. The things they do are sometimes called “tasks.”

To do these “tasks” they often use their own ecosystem of packages and plugins. Each tool writes tasks in different ways. These tools also don’t all do the same thing. Some “doing” tools try to handle any task you throw at it (Grunt, Gulp, etc). Others focus on one thing, such as handling Javascript dependencies (Browserify, Require.js, etc).

Sometimes you end up using several of these tools in the same project.

Here’s a short list of “tasks” I’ve automated with these “doing” tools:

1. Replacing a string of text in a file
2. Creating folders and moving files into those folders
3. Running my unit tests with a single command
4. Refreshing my browser when I save a file
5. Combining all my JavaScript files into one, and all my CSS files into one
6. Minifying my concatenated JavaScript and CSS files
7. Modifying the placement of <script> tags on an html page

Once you understand that tools install stuff or do stuff, categorizing them becomes much easier:

 

Build tools sorted by whether they primarily install things or do things

Concept #2 — The grandparent of all build tools is Node and npm

Node and npm install and run all these build tools, so there is always a trace of them in your project. Because of this, many developers try to use these two tools as much as possible before they resort to installing an additional tool.

Node and NPM fall into our “build” and “do” dichotomy. Node is the “do” tool, and npm is the “install” tool.

npm can install libraries like Angular.js or React.js. It can also install a server to run your app locally for development. It can even install tools to do things like minify your code.

Node, on the other hand, “does” things for you, like run JavaScript files, servers, and so much more.

If you need a place to start learning, start with Node+npm, and stay there for a while. When your project gets large enough, you’ll reach the limits of what Node and npm can automate for you. At that point you can organically incorporate another build tool.

Concept #3 — A build is just a production ready version of your app

Developers often break JavaScript and CSS out into separate files. Separate files let you focus on writing more modular chunks of code that do one single thing. Files that do one thing decrease your cognitive load. (If you think separate files are more confusing than one large file, try working in a 5000 line file, and you will quickly change your mind