My ideal front end development workflow for a new project

By Sam | Posted Oct 28, 2016 | 7 min. (1490 words)

Embarking on a new project journey is always exciting, but it can also be thoroughly overwhelming. Decisions around the front end development workflow often get pegged as low-priority and in a lot of projects this isn’t fully realized as a problem until too late in the life-cycle.

Engineering is about making your product better, learning from past mistakes and developing a streamlined process which is easy for all to understand. We should apply these principles to our workflow, and the start of the project really is the best time to establish the rules, tools and technologies that every developer involved will be using. This workflow will help to ensure a flexible, scalable and easy to maintain product.

Starting a new project means a blank slate, and a rare opportunity to try out new tech. Fun!

As a front end engineer, before I embark on any new projects I always ensure my workflow is organized before I go ahead. This article is what my ideal workflow looks like, and the tools I choose every time.

1. Set up a task runner

For those unfamiliar with the idea of task-runner, it is a bit of software which essentially automates repetitive tasks. Some common examples include tasks like JavaScript compression, file concatenation, copying files/directories, linting scripts, and compiling CSS files. The task runner is usually run from the command line, and can allow a developer to “watch” certain files or directories for changes, then run tasks when appropriate

Choosing a task runner these days normally comes down to Grunt vs. Gulp. There are other tools out there of course, but these two are the most reliable and popular (so have better community support). A seasoned front-end dev may argue that they are pretty much the same tech and it doesn’t matter which you use, or perhaps that Gulp is the supreme overlord and all Grunt worshippers should be burned at the stake for their heresy.

In terms of which is better, it’s really a matter of preference. Grunt revolves around configuration, it’s clunkier and slower, but has a gentler learning curve and a bigger community. Gulp requires complicated pipelines but is generally faster.

Here’s a quick breakdown of the positives and negatives of both:

Grunt

+ Easy to get started

+ Finer level of control through configuration

+ Been around longer, bigger community, more plugins

– Non-streamed file I/O makes it slower

Gulp

+ Less configuration

+ Faster processing

+ Uses streaming, allowing asynchronous file processes

+ Write less code

– Limited API

Both Grunt and Gulp run on Node.js, so each developer in your team will have to have that installed.

2. Define your CSS process

Secondly, you’ll need to decide on a CSS methodology, this could be BEM, SMACSS, or Atomic CSS. Once again, this is a matter of personal preference and most likely something you’ll need to discuss with your team. We use BEM at Raygun and have found it easy to learn, and very effective for working on application components in a large team.

Once you’ve established a set of rules around how you’re writing your CSS, you should decide on how the CSS is going to be written. These days it seems crazy to not use some kind of pre-processor like Sass or Less to write cleaner, tidier CSS. These days it doesn’t really matter which you use, and CSS4 may render these ‘languages’ obsolete in the near future.

Consider whether a pre-preprocessor is necessary as it does add time to your build process. For example, if you’re using BEM, you may not need to take advantage of the nesting benefits of Sass or Less.

Use a Sass library like Compass can boost the capabilities of Sass, adding extra functionality like sprite-map generation, cross-browser mixins, file reading and mathematical helper functions for developers looking to really nerd-up their CSS. Using Sass and Compass will mean all your developers will need to install Ruby.

Alternatively, you can use a JS plugin like postcss to post-process your CSS. The extensible postcss plugin allows you to automatically add browser-prefixes based on your required browser support, inspect CSS, compress files, generate sprites and more. We use postcss at Raygun and would highly recommend it.

3. Establish JavaScript laws

This is the most exciting part of beginning a new project, and the point where you can save the most technical debt further on down the track. You can lay down some serious guidelines around how your JS is going to be written, which framework you’re going to use and the design patterns your developers will follow.

Which flavour of JavaScript are we writing? ES5, ES6+, TypeScript, or something else?

This is a big question, and one for which there is no clear correct answer. Here’s a quick break down of my recommendations:

ES5

The benefits of ES5 are that (hopefully) all your developers will be fluent in JavaScript, will understand the structure, and how to work around the various idiosyncrasies of the dynamic language. There is no learning curve for experienced devs, and all the major JS MVC frameworks will support it.

The negatives of course are that you’re still writing plain old JavaScript. It’s verbosity, loose-typing and lack of traditional OOP language features make it a nuisance for any developer used to C#, Java, Ruby, etc. In my experience, JavaScript generally presents a steeper learning curve for new software developers.

“Undefined is not a function??? What does that even mean??!” - Every software developer ever

ES6+

ES6 is the future of JavaScript, or maybe ES7? Who knows? But it’s a good idea to begin writing to modern language standards in order to future-proof your code. ES6 offers some very attractive language features at a glance: classes, interfaces, lambda functions, module import/export functionality and other fancy features one might find in a ‘real’ programming language!

The negatives of ES6 are that you will still need to transpile your code down to ES5 due to patchy browser, server and OS support. This isn’t a big deal and hopefully won’t be an issue in the future, but adds an extra step in the build process. Another possible issue is that it does present a learning curve to those unfamiliar, but on the flip-side, presents an opportunity for your dev team to up-skill.

TypeScript

TypeScript is Microsoft’s answer to everything wrong with JavaScript. The benefits include basically all the great language improvements found in ES6+, as well as tooling for Visual Studio, and strong support by Angular v2. TypeScript aims to make JavaScript scalable by adding modern language features and making it easier for developers used to working in a .NET environment.

In terms of negatives, again you’ll also need to transpile TypeScript down to ES5 and up-skill your team.

This leads us to the next question.

Which JavaScript framework will we use?

Nowadays there are a million JavaScript frameworks floating around and it would be impossible to compare and consider each one. Instead I’ll look at three of the most popular, Angular, Ember and Backbone. The reason I chose these frameworks is that they’ve all been around for a while, so have had extensive development, created a large community knowledge-base and provide three very different approaches to building applications on the client-side. Here’s a breakdown of the positives and negatives of each framework:

Angular

Angular v2 would be my first choice, after a great experience with Angular v1, I am very excited about using the latest version in my next project.

+ Very fast to prototype and build

+ Documentation for TypeScript and Dart

+ Test-driven development is easy with Jasmine and Karma

+ Lots of magic

– Lots of magic

– You must follow the Angular way of doing things or explosions

Ember

A good middle-ground.

+ Component-driven

+ Less magic than Angular, more magic than Backbone

+ Uses the Handlebars template engine

+ CLI

+ Testing is easy through the CLI

Backbone

Old school, bare-bones framework

+ Hardly any magic

+ Full control over your design patterns, code-style, architecture

+ Some of the biggest apps and websites still run on Backbone

+ Choose your own template engine

+ Essentially cleaner HTML, no magical attributes needed

– Requires a lot more boilerplate code

– Not dependent, but benefits greatly from a view framework like Marionette

– Requires more code to be written in general, but allows greater optimisation

– BYO test environment

In conclusion

It’s crucial to discuss every decision with the team, see who has experience with what. Discuss the nature of the product and build your workflow around it. Making good decisions at this stage in the project life-cycle is absolutely critical to the success of the product.

My dream workflow would look like this: