As a front-end developer myself, I read lots of articles about the latest tools promising to improve my workflow. But the truth is, a lot of them are either overkill or simply unsuitable for the smaller types of project I work on. But there are 5 fantastic tools out there that have quickly revolutionized my workflow, and I want to give you an overview of why they’re now part of my essential daily toolkit, in spite of my initial skepticism. Not only do they have super-awesome-techy-startup names – they help keep my code clean and organized, and my workflow more streamlined than an Emperor Penguin (the most streamlined and awesome of all the ocean-going birds).

That’s enough jibber-jabber. Let’s start from the top and go through 5 of the best front-end developer tools to improve your workflow:

Gulp

Task runners are the sliced bread of web development. They take care of the common tasks that you find yourself doing over and over, like optimizing images and refreshing browsers. Not only that, but they allow you to use SASS, which in turn allows you to script CSS, making it more flexible, reusable, and just plain pukka.

Gulp is super useful. Having previously used Grunt (an alternative to Gulp), I discovered Gulp to be much quicker in compiling, as well as preferring the style of its configuration file – but that’s just my opinion.

Getting started

Gulp runs on Node, so you’ll need to install that first, (http://nodejs.org/). Once you’ve got node installed, and installed Gulp using the package manager (npm install -g gulp), you’re ready to start creating tasks using the gulpfile.

The gulpfile can be broken down into sections:

Dependencies – Node’s require allows us to specify plugins that we’re going to need for our Gulp task. This may be a plugin to compile SASS, or a plugin to concat files. For example:

var gulp = require('gulp'),

sass = require('gulp-sass'),

concat = require('gulp-concat');

Tasks – These are the tasks that can be run using terminal commands. For example:

gulp.task('sass', function() {

return gulp.src('scss/app.scss')

.pipe($.sass({

includePaths: PATHS.sass

})

.pipe($.autoprefixer({

browsers: COMPATIBILITY

}))

.pipe(gulp.dest('css'));

});

So I’ve called my task ‘sass’. This means I can simply run this task by going to the corresponding folder in the terminal, and then running ‘gulp sass’. It will then do the following:

Get my app.scss file

Compile the SASS into CSS.

Automatically prefix for older browsers, e.g. -webkit, -moz

It’ll then output the file to the CSS folder.

Further Reading:

SASS

You may have already heard of SASS, since it’s been about for a while. It’s a very common tool, but for those of you who are still skeptical about using it, don’t be. It’s super awesome. SASS extends CSS to be so much more flexible than you probably think is possible. As well as allowing you to create set variables you can use from project to project, it boasts other amazing features such as variables, mixins, nesting, inheritance and extends. These keep your code squeaky clean and easier to worth with.

Getting started

First set your variable:

$primary-color: #aaa;

body {

color: $primary-color;

}

.button {

background: $primary-color;

color: #fff;

}

This means if I want to adjust the colour by a shade or two, I simply change one variable. Recompile the CSS, and everywhere I’ve used that colour is automatically updated, taking up less time, causing less hassle, and resulting in cleaner code. Not bad, eh?

Use mixins to handle retina images with ease:

@mixin background-image-retina($file, $type) {

background-image: url($file + '.' + $type);

@media (-webkit-min-device-pixel-ratio: 2), (-moz-min-device-pixel-ratio: 2) {

& {

background-image: url($file + '@2x.' + $type);

}

}

}

Now, with just one line, I can make sure images suffixed with @2x are used on retina devices, simply by replacing the background-image line with:



@include background-image-retina("../assets/img/intro-bg", "jpg");

The extend function allows you to stop typing repeating code elements. For example:

.callout {

background: #333;

border: 1px solid #ccc;

}

.success {

@extend .callout;

border-color: green;

}

Further Reading:

Bower

Keeping your project’s dependencies up to date can become a bit of nuisance. Manually downloading files, extracting and overwriting quickly becomes laborious, and certain rogue scripts can introduce compatibility problems. I’ve had issues with a specific version of jQuery being incompatible with another essential script. Talk about wasting time. Bower sweeps all this away – managing dependencies by fetching and installing them for you. It’s so easy to get up and running, a dolphin could do it.**

**A trained one, obviously.

Getting started

Bower manages your dependencies from open source projects on Github. Personally, I use Foundation. So, to install a dependency once bower is installed, I just run:

bower install foundation-sites —save

When a Foundation update is released, I just run:



bower update

See how easy this is?! No more downloading zip files or manually tracking versions – Bower does it all for me. Now when I pick up a project, I don’t have to worry about whether I’m running the latest Foundation version because Bower has my back.

Further Reading:

Susy/ Foundation/ Bootstrap

I’ve been in many a conversation about frameworks, evaluating pros and cons of each, as well as working out which one is the best. Personally, I use Foundation. It’s something I’ve used for a long time now, so I’ve optimized my workflow for this setup, meaning I’m familiar and comfortable with every aspect of it. The latest version is also massively reduced in size, making it even more agile.

Bootstrap is an alternative to Foundation, and is also very popular. Bootstrap was the first framework I ever used and still remains one of the best. There are a few reasons why I prefer foundation, but I won’t go into them now. If you want to know more, leave a question in the comments and I’ll be happy to go into more detail.

However, some developers prefer other solutions such as Susy. A very lightweight responsive grid system, Susy’s had a meteoric rise in users lately. It’s a fantastic bare bones starting point which I really like. It’s perfect for developers who want a lighter-weight starting point that’s still man enough for the tough stuff.

Getting started – Foundation

Foundation 6 has lots of boilerplate elements, from a responsive grid to buttons, forms, tables and more. It breaks down these components into SASS includes, which you can simply remove from its SASS file:

@include foundation-global-styles;

@include foundation-grid;

@include motion-ui-transitions;

@include motion-ui-animations;

It also has gulp included by default, so SASS automatically compiles on save. Look Ma, no hands!

Getting started – Bootstrap

Bootstrap, similar to Foundation, has everything baked in, from the grid, to carousels, to forms. You can also customise your build using a config.son file, which allows you to cut the bloat from the project. However, it uses LESS rather than SASS.

Advantages:

Very popular – other designers & developers are likely to have used or at least heard of Bootstrap, making it a good choice for collaborations.

Disadvantages:

No SASS support – this is a personal preference. I find SASS much easier to manage.

Very popular – this also means that lazy designers/developers end up using the default styles, and website are becoming more and more templated.

Getting started – Susy

Once installed, Susy can be easily imported into your SASS file:

@import "susy";

It uses SASS to allow you to work your grid into the CSS, rather than bloating the front end code. To create an easy container, and grid, you could do the following:

.container { @include container(80em); }

nav { @include span(25%); }

Advantages:

No bloat – Susy is just a grid, and very flexible. It allows you to write most all of your code, while remaining fully flexible.



Disadvantages:

No basic styles for common elements – for example a basic button, or a form element.

Further Reading:

Beanstalk – Git Deployment

Git deployment is a very recent addition to my workflow. I’ve been thinking about using it for a while, but always thought it was overkill for most of my projects. (And to be honest I was a bit scared of using all the git commands, merging, branching, etc.)

Git deployment has improved my workflow in a variety of ways, but one of its main benefits is providing me with another backup solution. For a long while I couldn’t find a convenient way to backup my projects. I’d tried solutions like Dropbox, but syncing all the node files for each project was getting ridiculous, not to mention eating my bandwidth. Using git allows me to have a remote backup of each and every project, as well as a huge history of changes, which is a brilliant feature. It saves me time and money, and allows me to work across devices quickly and easily.

I recently worked on a large project where the client wanted to have two versions of the site: a testing/ development version to trial features, and a stable production version. Handling this manually would have been a nightmare, and so I decided to dance with the devil: Git deployment. I created two branches – a master, and a dev branch. Using Beanstalk, I set up two environments: a testing domain, and a live domain, each with FTP deployments. Then every time I pushed a change from my local machine to Beanstalk, it would automatically deploy it to the live site. I enjoyed history logs of changed files, a remote backup, and seamless project management every step of the way. I could now compare the two versions of the sites, as well as merge changes once the features had been approved. Since then, I really haven’t looked back. Now FTP can eat my dust.



Further Reading:

For Similar Articles, Check out: