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 I’ve grown and expanded, I’ve been taking on larger and larger projects. It’s forced me to re-examine how we build things. I found myself 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 likeAngularJS and Ember.js exist says a lot. Here’s how my current workflow goes:
- Github – moved 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. They’re not always needed (Sass for a splash page might be overkill) but are definitely useful on larger things. Many people use LESS but I chose Sass, mostly because Sass seems to be the popular choice here in Seattle. 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, I use Scalable and Modular Architecture for CSS. Out of the two, SMACSS is more important because clean code always wins.
- Atomic Design - I’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 a closer tie between development and design, cutting down overall project time.
- Freedom – This one is very important. I’ve been lucky to work with managers and clients that want to stay ahead of the curve, that want tomorrow instead of today. This allows me to experiment with new technologies, languages, and frameworks.
This list may change as I’m always experimenting with new workflows to make developer lives easier and projects better. Some things on the radar for the future are Docker and Google’s Go and Dart languages. I’ll keep you posted on my workflow and if you have a tool or a workflow that you think is great, I would love to hear about it.