Choosing Tools

by Tylor

The tools, frameworks, and modules you choose for a project will influence large and small decisions that add up throughout a project. Some are better or worse in different situations, and you should evaluate each tool carefully before diving in. We look for a number of characteristics when choosing tools, and thought them worth sharing.


The best tools help you make good decisions along the way. They reward you by making certain things easy, and add friction when you’re headed down the wrong path. Sometimes you can feel things click into place, a natural extension of the mental model the tool comes with.

D3.js is a graphics library whose focus is to start from data and work out to a visualization. This constraint lets you be much more expressive in applying the data to different situations and explore animation or advanced interactions more easily. If you try to work backwards by ‘drawing’ a visualization in D3, you end up with a lot of duplication and messiness, sure signs that you’re not doing things right.

Another case comes from Heroku. When you host an application there, you must follow Twelve-Factor development practices. This encourages you to build apps that are easy to deploy, scale, and maintain. For example, you can’t store uploaded files on Heroku because it’s better to store static assets on a dedicated service. Doing so takes pressure off your application and the architecture leads to a snappier experience.

Surface area

Tools that try to solve every problem are often unfocused, difficult to master, and suffer from bloat. Instead, look for tools with a focused mission and API.

Express.js is one of our favourites. It has exactly what you need to build web services: familiar RESTful conventions, tidy JSON handling, and convenient HTTP helpers. On a large project you’ll use nearly every API provided, and it’s small enough that you can pick it up quickly.

Contained surface area also allows tools to be combined with others, allowing you to choose the right tool for the job.

Easy to pull apart

We love working with tools that we can pull apart to understand what’s going on behind the scenes. Do the abstractions make sense? Can you follow your way through the implementation when things go wrong? Are your stack traces easy to understand? Is it easy to hack and replace parts to learn how something works? Can you understand it well enough to contribute an improvement? These are all good indications that something is well built and a good choice.

We found it to be this way when we worked with Backbone.js. The internals are easy to understand and because of that, we could track down bugs and make improvements.


We try to use tools that are actively developed and used in production. That doesn’t mean they have to be hugely popular, just that there’s some code maturity and a budding community around it. The momentum on these kinds of projects leads to better documentation, examples, and places to get help if you get lost.

Tools hosted on Github are fantastic. At a glance you can see the number of watchers, forks, pull requests, issues, and commits. The more recent the activity, the better.

Sensible, extensible defaults

Good tools give you smart defaults focussed on the first problems to solve, and allow you to override or extend them when needed. This way you can get up and running and customize your way to what you need.

We like how Cocoa Touch handles many basic aspects of usability by default, yet allows for customizing the behaviour and the looks. We often end up subclassing most of our interface elements to make adjustments to how they look and how they respond to the people using them.


There are a lot of tools that will get a particular job done, and with experience help you make choices well-suited to your task.

These are some of the principles we’ve come to use in tool selection. What do you look at when you come across something new? Tell us on Twitter!

Photo: Internet Archive Book Images/Flickr