Why I don’t use CSS preprocessors

Whenever I mention that I don’t use CSS preprocessors I tend to get strange looks from people who cannot imagine writing CSS without Sass. And so I have to defend my choice and explain why, over and over. Some people will understand, most won’t. Or they don’t want to. But here’s an attempt to explain my reasoning.

Back when CSS preprocessors first came into fashion I did try using them. And then every couple of years, due to external pressure and nagging, I have taken new looks and given them new chances. But to me they’ve always felt like solutions in need of a problem to solve. That is, I don’t really find the “problems” with CSS that preprocessors are intended to solve, problems. The scale of the site I’m building does not matter, be it a tiny site with just a few static pages or a humongous corporate intranet. I simply have never felt the need for mixins, nesting or extends.

A list of reasons then:

I’m fully aware that many people who use CSS preprocessors will disagree with most or all of the above. I already know that so no need to tell me :-).

However, me not using Sass or other CSS preprocessors like cssnext does not mean I don’t use CSS processors. The difference, as I see it, is whether or not your CSS requires compilation before browsers can understand it, which I really want to avoid.

I use PostCSS (with third party plugins and ones I’ve written myself) and CSScomb as helpers for things like:

I set up both CSScomb and PostCSS to work on my source CSS, which means I always see the results. No black boxes. I can save my file and reload instantly without having to wait for compilation (since the changes are mostly cosmetic and vendor prefixes/fallbacks only need to be inserted once). But the tools save me some typing and fix most coding style inconsistencies for me. That’s my kind of CSS processing.

Posted on March 27, 2016 in CSS