Originally published at: http://www.sitepoint.com/build-css-preprocessor-postcss/
Use a CSS preprocessor for while and life soon becomes imaginable without it. Many developers have adopted LESS, Stylus or — the current favorite — Sass. Ideally, you should also be post-processing your CSS using Autoprefixer to add vendor prefixes when required without resorting to mixins or frameworks such as Compass.
Autoprefixer is a plugin for PostCSS; a tool which translates CSS into an object model which can be used to manipulate styles. There are many more plugins available which implement preprocessor-like features such as variables, mixins and nesting.
Ben Frain’s recent article, Breaking up with Sass: it’s not you, it’s me, raises an interesting proposition. Do you really need Sass, LESS or Stylus given you can craft the CSS preprocessor you want using PostCSS?
A basic Sass-like parser can be created within your build process. For this example, I’ll use a Gulp.js task file but the same concepts apply to Grunt or any other build system. Continue reading this article on SitePoint
Although it looks like a modular approach to post-processing CSS can be useful, I’m still not seeing a good reason to add complexity and bloat to the development workflow. CSS is just not that difficult to warrant or justify making stylesheet creation complicated with pre- or post-processing.
I can see why people think SASS (for example) can greatly speed up their CSS writing but it just seems to be an illusion for people who are, frankly, doing it wrong. Yes, nesting styles in SASS cuts down on repetitive typing, but if you want such specificity in your selectors to benefit from SASS nesting then you’re doing it wrong. Yes, using mixins and functions to autopopulate vendor prefixes is nifty, but if you have more than 1 or 2 different box shadows or gradients then you’re conceiving your CSS wrong and arguably your design work may need tightening up too. Yes, using a variable to define core colours so you only need to change a single instance is handy, but is a simple Find and Replace so abhorrent?
Same can be said for the post-processing described in this article. Yes, I’d find it more useful to create my vendor prefixed stuff after the event, and as a developer I don’t think the requirement of JavaScript processing and valid CSS is actually a negative since you’d know these anyway (or are people so wrapped up in SASS and jQuery these days they actually don’t know pure CSS and JavaScript?), but as I said with pre-processing if you’re creating CSS that uses a lot of rules with vendor prefixed content then arguably you’re doing it wrong - how many different box shadows do you need? How many gradients? How many different transitions? And why don’t you just define a class that has your box shadow defined once and slap that class onto any HTML element that needs it?
Good article as always, but I’m afraid just don’t see it.
I was initially skeptical about pre-processors. I agree they can be mis-used. You should only use a pre-processor if you understand CSS. It’s easy to use them badly too, e.g. creating convoluted functions for basic styles. But that’s an fault of implementation - not the technology.
The main benefits? You can keep related styles in multiple files. Nesting makes code less verbose and easier to read. Variables are handy. Useful functions can assign colors. In other words, CSS is easier to organise.
I disagree with your point about post-processing. You don’t need vendor prefixes for things like box-shadow - it’s well supported. But what about modern features such as flexbox, animation or filters? I don’t worry about it - I just let Autoprefixer add them as necessary according to data from caniuse.com. I no longer care whether Apple does or doesn’t support a specific feature - the hard work is done for me. Features such as media query packing, calc() reduction, and fallbacks are a bonus.
And what about minification? That’s a post-processing feature. Doing that manually is painful.
Use a pre or post-processor for a while and life becomes more difficult without it. Try using one - you may like it.
I can see why you’re skeptical. I’m just looking into trying postCSS to see what can be done with it and I can already see how it will look bloated. That said, when I first used Sass I had the same initial feelings about complexity and bloat but as soon as I had learnt how to do things better the issue was much less of a concern, especially due to the benefits it’s given me. At the moment I can only see one benefit that can;t easily be done with Sass and that is the ability to write my own processors with js.
Hopefully with a bit of time and experimentation it’ll be viable to use but for the moment it’s still going to be Sass over postCSS on any medium to large project.
Of course, there’s no reason why you can’t use both Sass and PostCSS. You possibly are already. That way, you can still use the normal SCSS syntax but drop into JavaScript when you need advanced functionality.
I don’t know why I didn’t think of that. It’s probably the better solution, since it can be added onto the current pipeline without having to re-educate everyone else on the team! Thanks for the idea!
Yeah I agree. The only thing that’s at the back of my mind is that by mixing the 2 it will make it hard to understand for some people. I think there’s going to be a lot of back and too until the right balance is found. Having the CSS/Sass separate from mixins will to me feel like I have to go 2 places to do things and I can’t just leave the processor to do things behind the scenes. I think if Sass had never existed then postCSS would have been a simple choice.
In my workflow I use stylecow (I’m one of the maintainers). It’s another postprocessor similar to postcss, but it is faster and solves some postcss issues.