My Ideal Front-end Development Workflow For a New Project
My Ideal Front-end Development Workflow For a New Project
A front-end developer reviews her workflow and ideal tool set.
Join the DZone community and get the full member experience.Join For Free
Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
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
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:
+ 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
+ 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.
Another good example of task running would be compiling templating languages like Jade
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.
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.
This is a big question, and one for which there is no clear correct answer. Here’s a quick break down of my recommendations:
“Undefined is not a function??? What does that even mean??!” – Every software developer ever
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.
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.
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
A good middle-ground.
+ Less magic than Angular, more magic than Backbone
+ Uses the Handlebars template engine
+ Testing is easy through the CLI
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 optimization
– BYO test environment
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:
- Grunt for task-running
- Sass for CSS pre-processing
- Postcss for post-processing
- Write TypeScript
- Build with AngularJS
What does your dream workflow look like? Leave us a comment.
Published at DZone with permission of Sam Holt , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.