This blog series is explaining common front-end development technologies for a non-technical audience. Part 1 of this series explored front-end libraries and frameworks. This post will explain/explore build tools, command line tools, and new languages.

Build Tools

When developers create applications, there are numerous tasks involved. These tasks include setting up their codebase, downloading libraries, or preparing their application for production deployment. These tasks can be done manually using the command line, a package manager (like NPM), or manually creation/coding. But running these tasks manually can become repetitive and disorganized. Developers hate repetition (that’s what computers are for) so they create tools to handle this anytime they can. The tools, in this case, are called task runners or build automation tools.

Grunt and Gulp are the most commonly used build automation tools. Grunt got an earlier start but Gulp has quickly become more popular. Think of build tools as “programming to setup for programming”. A common task in Grunt/Gulp would be to ‘lint’ the code upon saving. Linting code is the process of checking it for proper syntax/styling. This is one way to reduce bugs and make code more readable. Grunt/Gulp are commonly used to run such tasks as minification, concatenation, clean up file locations, and compile one type of file to another.

An easy way to imagine Gulp is to picture it as a sort of old-school pneumatic tube

system. Gulp is a way to pipe files from one location to another. The difference is that Gulp uses one or many plugins in the middle to make changes to the file before delivering it to it’s destination.

Broccoli is similar and newer than Grunt/Gulp. It does tasks differently and offers a more concise syntax and increased performance. Broccoli’s is supposed to be especially helpful when projects grow in size/complexity. Grunt and Gulp files can quickly become difficult to wrangle and Broccoli’s tree/folder based tasks supposedly shine here.

Yeoman has a set of ‘generators’ that allow for quickly setting up / scaffolding a project. Rather than taking the time to create folders for your HTML, JavaScript, and CSS, Yeoman will do this for you. You can then tweak the setup to your liking/needs.

A Yeoman before it became a JavaScript tool

Command Line Tools

In 2015, most development projects require a lot of external libraries (you know what a library is now, right?). To use jQuery, for example, the developer needs to go to jQuery’s site, download the source code, put it in the right folder, and include the <script> tag in their code to bring jQuery in. This quickly gets tedious as a project needs many libraries. Furthermore, it becomes difficult to keep track of which version is needed where.

An example of how libraries are included into a project

Command line tools like Bower and the Node Package Manager (npm) allow for libraries to be installed using the command line. A simple command like bower install jquery will go fetch the jQuery source code and put it into the bower_components folder, stored locally. Now the index.html file will look something like this:

NPM can do everything that bower can and more. There 70000+ npm modules to the Bower’s 10000+ packages. Npm needs Node.js to run and many projects don’t use node. Npm also installs many more dependencies (think Libraries that depend on Libraries) when you install something with npm. Bower will, supposedly, install fewer dependencies and therefore take up less space than npm modules.

It’s a bit trickier to think of metaphors for command line tools. But, imagine, you’re a dentist working on someone’s teeth. You merely have to open your hand and say the tool you need and an assistant puts in it in your hand for you. This is what Bower and Npm are to a developer. In a command or two they have quick access to the tools they need.

Dentist, Instruments, Dental, Equipment, Detail


JavaScript and CSS are default languages that are used in webpages. However, they each have their own drawbacks in terms of syntax, whitespace, and aesthetics. For this reason, developers invented new languages and ‘preprocessors’ that they develop in. They then take these new languages, like CoffeeScript or Less, and compile/convert them into JavaScript, HTML, or CSS. The newer languages are easier to develop in but must ultimately become what the browser can read.


CoffeeScript is a programming language that ‘transcompiles’ (converts) to JavaScript. CoffeeScript is a cleaner prettier version of JavaScript. It has a ‘leaner syntax’ that makes it easier to read. Here’s a quick example from the CoffeeScript site:

Looping over an Array example in JavaScript (a common task):

The Equivalent in CoffeeScript:

This is one small example of how using something like CoffeeScript makes developers’ jobs easier.


Typescript is another new language that converts to JavaScript. One of the biggest potential drawbacks of JavaScript is its ‘weak typing’. Weak typing basically comes down to not being able to tell when a piece of data is a string (text) vs. a number. Typescript has stronger typing (hence ‘Type’ in the name).

Typescript also offers some advanced (futuristic) JavaScript functionality that isn’t supported by most browsers yet. Typescript offers features (e.g. modules, classes, mixins) that will come with the next version of JavaScript, ES6. Typescript will convert back to normal JavaScript and work in today’s browsers. Typescript offers JavaScript’s future, today.

Less, Sass, and Compass

Less, Sass, and Compass are all languages that can be compiled to CSS. They are to CSS what CoffeeScript/Typescript are to JavaScript. Less, Sass, and Compass improve the process of writing CSS.

For example, say a developer is going to use the same color across their application. Instead of writing out the hex color code (e.g. #000080) multiple times, they can declare it once as a variable then use that variable across the application. When that Less, Sass, or Compass is compiled later, that hex code will put in across the CSS.

Think of Less, Sass, and Compass as using programming in CSS. They give you functions, variables, and logic to make stylesheets easier to write, maintain, and understand. Here’s a quick example in Sass from this excellent post:

This is assigning a value to the variable of “container-width”. Containers are common HTML objects. This variable will be assigned however many pixels is currently 100% (width) minus 20 pixels. This spares the designer/developer from having to go figure out what the current proper width is and subtract 20px and put that value in. When something changes in the styles, the changes will propagate dynamically across the stylesheet (vs. having to go do all the math again). This small example shows how something like Sass makes writing styling much easier.


This post covered build tools, command line tools, and new languages. Most of these tools didn’t exist 5 years ago and none existed 10 years ago. It’s easy to get lost in their cryptic names and acronyms. Simply remember that they all exist to make developing and maintaining applications easier. In 5-10 years, you’ll have a new set of technologies to learn up about! They will have the same purpose as well.

The final post in this series will curate some introductory level writing on front-end development. These 5 posts were selected to be generally approachable to a non-technical person. They will allow you to appreciate how far this field has come and how exciting it is now.

The following two tabs change content below.

Kyle Pennell

Kyle is the community/content manager at DevelopIntelligence. He spends his time reading, coding, biking, and exploring live music in Oakland. He enjoys trying to make technical concepts more approachable and likes tinkering with music and mapping APIs.