My Foray into PostCSSFebruary 5, 2016
I’ve been a web developer for 5 years now. In those 5 years, the amount of times I’ve changed my CSS process is shocking. I started, of course, with vanilla CSS. When I moved into agency work, we used LESS. Then we transferred to Sass. When I moved to my newest job, we were using a sort of hybrid Sass library that didn’t require brackets or semi-colons, which I can’t stand. Copying and pasting CSS from Chrome to Sublime with that format of Sass requires the extra step of removing the brackets, spaces and semi-colons. Not fun. Each of these changes served a different purpose, and all-in-all, I would say they were all for the best. I’ve learned a lot from each of these CSS processors. After researching PostCSS, I found that it could offer me more than I ever expected a “post processor” to offer.
Why I Chose PostCSS
In my new role as a senior front-end developer, I’ve been tasked with wrangling in and refining our front end development process. PostCSS has been all the rage lately. Lots of companies, small to large, have made the transition. At first, I didn’t get what the difference was between Post and any other pre or post processor. It finally occurred to me, after hours of studying articles and series on the subject, that PostCSS really is just what you make of it. It can be as close to Less or Sass as you want it to be. It can do as little to your original code as you want, or you can make it completely unrecognizable after the fact. To me, PostCSS has been a way for me to know exactly whats being changed, moved around and minified after the fact. I enjoy the freedom to add and subtract PostCSS modules as I please. I like that I can use it with a familiar build system like Gulp (although I do plan on going to straight NPM build in the near future). Below I’ll outline the steps in my process and what modules I chose to use.
For the build system I do use Gulp. I’m familiar with both Grunt and Gulp, but from what I had read about PostCSS, most people used Gulp. Also, it’s very simple to integrate PostCSS processes with the JS and HTML processes I already use.
I chose to include modules that gave me a lot of the same formatting as Sass. I use ‘postcss-import’ to help break up all my code into different files that are imported using one file. ‘Postcss-nested’ gives me the same nesting as you’d find when writing LESS and Sass. For variables, I used ‘postcss-simple-vars’, which functions exactly like Sass variables.
I really like being able to nest media queries with their corresponding tags so that I can easily keep context, instead of putting them all at the bottom of the CSS document. That can get a little heavy in the end, unless you have ‘css-mqpacker’ in your process, which filters through your css and puts all of your media query rules into just one.
I use ‘autoprefixer’ which automatically adds vendor prefixes to whatever styles still require them.
Using a seperate production task, I minify and concatenate the code with ‘cssnano’. With most of our projects, we use bootstrap as the foundation for our css, so I use ‘gulp-uncss’ to filter out all of the bootstrap css we end up not using in the end.
When folks say that PostCSS is fast, they aren’t kidding. My builds are done almost instantly, certainly quicker than anytime I’ve used LESS or Sass. When used in conjunction with ‘browser-sync’, saving and seeing changes in CSS has never been faster.
I’m glad that I’ve made the switch to PostCSS. The simplicity and granularity I can modify my processes with are whats sold it for me. In the future, I’ll look to eliminate Gulp from the equation and use only NPM to build. I’m going to see where some modules, or my process in general, are lacking and look to build my own modules to make my PostCSS experience truly unique.