Current development workflow is going pretty well and with the large number of projects Cargo have worked on over the last year or so it’s the smoothest it’s ever been.
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.
At first I was fairly sceptical about PostCSS. My workflow rocks right now, why would I change it?
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
- Finally, watch for changes in JS or CSS files and then inject or refresh the browser!
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!