A Front-End Workflow For The Evolving Web
Portent Staff Jan 14 2014
Front End Development is a fairly new concept. Back when “Webmaster” was an actual job title there was no real “development” on the front end. Websites were structured using tables, CHSS and SSP were being joined together to make what eventually would be CSS. The web was still primarily a place for documents, real people were in chat rooms, and life was grand. Even as sites became more flashy (blink element anyone?) and CSS1 came of age, they were still fairly simple.
Things are getting heavy, and I mean that literally. In 2013 page weight went up 32%. That’s up from a 30% increase in 2012! The web is getting bigger, more complex, and does more things. This is a good thing, but it presents some new challenges.
As we’ve grown and expanded, we’ve been taking on larger and larger projects. It’s forced our development team to re-examine how we build things. We found ourselves needing a more modern workflow to deal with all of the complexities of the modern web. Software Engineering principles, REST API’s, and unit testing suddenly became relevant. Separation of concerns became more than just separating HTML and CSS.
Our Evolving Solution
Have you ever tried to build a non-trivial AngularJS app? The learning curve is steep and usually requires digging around the source code. The fact that frameworks like AngularJS and Ember.js exist says a lot. Here’s how the dev team here at Portent modernized our workflow:
- Github – We moved our projects from CVS to Github and adopted Github flow, a variation of Git-Flow outlined by Scott Chacon. It’s simple, requires minimal setup (getting everyone on Github) and provides a nice interface for the less technically inclined (e.g. managers).
- Yeoman.io – It combines generators, or scaffolds if you will, to build out a skeleton project (you can also write your own). It uses Grunt.js for task running and compiling assets (Sass/LESS/images) and Bower for package management. Seriously, this tool can save you a lot of time on both ends of the development cycle.
- Sass and SMACSS – Preprocessors are all the rage and for good reason. They can increase maintainability of your presentation layer. Many people use LESS but we chose Sass because it seemed to be more actively developed. There is a downside to preprocessors though, and that’s the ability to shoot yourself in the foot with bad/extraneous styling. To combat that, we use Scalable and Modular Architecture for CSS. Out of the two, SMACSS is more important because clean code always wins.
- Atomic Design – We’ve started to build things according to Atomic Design from Brad Frost. Basically you start at “atoms” (like colors, fonts, search bar) and move up the chain to “molecules”, “organisms” etc. Combined with SMACSS, this allows us to develop as we design, cutting down overall project time.
- Freedom – This one is very important. We’re lucky to work with managers and clients that want to stay ahead of the curve, that want tomorrow instead of today. This allows us to experiment with new technologies, languages, and frameworks.
This list may change as we’re always experimenting with new workflows to make our lives easier and our projects better. Some things on our radar for the future are Docker and Google’s Go and Dart languages. I’ll keep you posted on our workflow and if you have a tool or a workflow that you think is great, we would love to hear about it.