5 Tools A Frontend Developer Should Be Using

4 min readMay 17, 2016

There are many many things a frontend developer could be using but there are some I feel are the most important here. Everything I’ve mentioned is designed to save you time, develop your skills and leave you more productive, not just to chase the new shiny. You could adopt these for individual projects but I’ve had organisations in mind when writing this.

Use a CSS preprocessor (SASS/LESS)

If for nothing else, using SASS/LESS gives you sane variables so you don’t have to duplicate and maintain quite as much code.

Once you start scratching the surface you quickly discover that using mixins and nested structures, you save a lot of aggregate time. Take the following CSS example:

.nav a {
  color: red;
}.nav a:hover, .nav a:active, .nav a:focus {
  color: pink;
}

Can be simplified to this in SASS:

.nav {
  a {
    color: red;
    &:hover, &:active, &:focus {
      color: pink;
    }
  }
}

In this example, you can see how DRY it is and would be trivial to refactor the .nav class with little to no impact.

Many editors (certainly those from JetBrains), normally have an on-the-fly SASS/LESS converter which will dump a CSS file alongside your SASS file.

Use a build tool (Grunt/Gulp/CodeKit)

Putting off using a build tool like Gulp isn’t worth it. They provide heaps of value. One strong example is using autoprefixer for your CSS. With autoprefixer you just write:

display: flex;

…and it replaces your code with:

display: -webkit-box;
display: -webkit-flex;
display: -ms-flexbox;
display: flex

Don’t you look good for covering all browser prefixes without even thinking!

You also have a great utility to introduce unit testing, automatic image optimisations, generate your own icon font from SVG files, lint your code, etc…

As a process of maturing over time, you’ll probably start by writing and running individual tasks like:

gulp autoprefixer

Which will then mature into:

gulp dist

…which will be running your JS linting, CSS pre-processing, image processing and distribution tasks, ready to hit your server.

LiveReload

Intro to BrowserSync

If you haven’t seen or heard of this before, you’re in for a treat. In short, you save the file you’re working on locally and by the time you switch back to the browser, the page has your latest changes. If you’re using a tool like Browser Sync you don’t need to worry about installing browser extensions, it will just work. It’s smart enough to realise if you change a CSS file, it doesn’t need to reload the page, it just reloads the CSS file.

Going back to the previous point of using a build tool like Gulp, that’ll be really beneficial with a tool like this as you have a pipeline to manage file watchers, processors and invoking the reload event.

Continuous integration & delivery

This sounds more daunting than it really is. If your site is static files, you’ll be able to deploy with ease by copying files to servers but for this frontend topic, it’s mostly to have a service continually running your build tasks when you push new code.

Sign up to use Codeship (or Travis) and follow their steps to setup a project. This will hook up your Github repository. With a blank project, you’ll be able to run gulp deploy (assuming you have a deploy command that dist’s and publishes artifacts) in the build steps and it will magically update your server when code is pushed to Github.

This is soo worth it as it’ll be start saving you time immediately and lay the foundations to run your new frontend build tools.

Create a UI Toolkit

Following from the success of projects like Bootstrap/Foundation, you should start getting into the process of creating a living toolkit of your components if you work on a team. This should comprise of at minimum an example isolated component that looks & works as expected but will ideally also include a bit of documentation on what classes/attributes it takes and a code example available to copy-paste. Bear in mind the code examples can use your templating language’s macros to generate the output for you.

Working “toolkit driven development” will just frame the way you design and develop features with an end game to become more productive. It will allow you to easily re-use elements, opting to avoid having similar forks of boilerplate code and wasting time re-inventing features already made.

There’s also a discovery aspect to this as you probably have features that only surface in a particular flow on your web app that few will see when developing. Containing this feature in a living, breathing toolkit will ensure it’s not forgotten, especially that there are no regressions when maintaining other features.

There’s an exhaustive list of frontend tools at https://github.com/codylindley/frontend-tools but if you have any must-have frontend tools, I’d love to know, just add them in a response.