A Sceptic’s Take On PostCSS

We use a combination of CodeKit and Gulp to compile and optimise our SASS and Javascript, saving all our changes in our Git repository and then deploying the changes to the relevant development environment with DeployHQ. Finally, tracking issues within the repo’s issues or Basecamp project.

For those of you who are not developers, CodeKit, Gulp and SASS are used to produce streamlined CSS and Javascript (coding languages which are the building blocks of your website’s look) and allow them to be interpreted together to make your website a beautiful, functional and accessible home on the web. This code, once pulled together, fulfils its duty as your website. The rest of the article might not make much sense, but rest assured it means here at Cargo we’re working hard to innovate our development and make your websites more robust, future friendly and less likely to break with the inevitable release of new devices and technology.

PostCSS has been around for a while now and we’ve been keeping it on our ‘to look into list’. The time has come and we’ve had a blast getting to grips with what Gulp and PostCSS can do. Following the great tutorials over at Envato’s Tuts+  we were able to replicate, and build upon, our current workflow using only Gulp and the PostCSS plugins.

Now, at first I was fairly sceptical about PostCSS. My workflow rocks right now, why would I change it? SASS allows me to write what I need, easily, and CodeKit does everything else and then updates the browser automatically so I can see my changes, why would I need to post process my CSS? Well, that’s where I fell into the trap assuming PostCSS was done AFTER everything else…which is not strictly true.

The first section of the Envato tutorial does a great job of explaining what PostCSS is and is not so I won’t go through it here. Let’s just go with: PostCSS can be incredibly useful regardless of your current workflow. You can choose how you use it by either picking from a long list of existing plugins or by writing your own. These plugins can do anything from simply consolidating your individual CSS files to automatically adding vendor prefixes, stripping all comments, combining multiple files together and then outputting one single, optimised CSS file.

Cole Peters, a London-based web designer, wrote a great article regarding once again being able to author real CSS whilst also future-proofing the code for new CSS specifications using PostCSS in combination with the plugin cssnext.

Sounds great! Writing code now and it works as soon as it’s in browsers? Sign me up. But wait…writing code to an unfinished spec? What if the spec changes? Chris Coyier, a front end web designer and writer, brings up some pretty interesting points in his cssnext opinion article, “The Trouble With Preprocessing Based on Future Specs”. After reading, I considered his points and was put off getting stuck into PostCSS. The great thing about it, though, is that you don’t need to use the cssnext plugin in your process if you don’t want to.

At the end of our initial foray into the PostCSS unknown, our Gulp file’s PostCSS order looked something like this:

• Prepare CSS files to accept SASS like variables, functions, mixins and imports
• Allow the use of Lost grid
• Add fallback CSS to properties that need it
• Combine all CSS files into style.css
• Add fallbacks to future CSS properties
• Convert rem values to px fallbacks
• Group all media queries together and move them the end of the css file
• Strip out comments and whitespace
• Create a style guide document based on specified styles
• Lint and compile javascript
• Finally, watch for changes in JS or CSS files and then inject or refresh the browser!

The Envato tutorial was incredibly easy to follow and formed the basics of our final (for now!) process, which was a welcome surprise. After tinkering and fine tuning the stack and order of the plugins (which was a bit of a learning curve as it turned out the order of the plugins is very important) we ended up with a great alternative workflow, albeit not too dissimilar to our usual CodeKit + Gulp workflow. The subtle differences make PostCSS another viable tool to consider when starting a new project, especially when it comes to ease of setup across multiple machines and pure scope of customisability depending on the needs of client.
Doing the initial ground work to get a solid project template didn’t take too long and was definitely worth the resources to put in place. Is PostCSS the next best thing? I’m going to sit firmly on the fence for now. PostCSS keeps front end development fresh and interesting whilst also being very easy to use throughout the team with very little setup time. We’ll revisit how useful it is when implemented in a live project environment. Look forward to that post at a later date!