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 don’t feel the “problems” CSS preprocessors intend to solve are serious enough to warrant the cost, i.e. to me the solution is worse than the problem.
I want absolute control of my CSS, which means I want to work hands on with it, and see exactly what will be sent to the browser (well, before it’s minified and gzipped, of course). If that means seeing the same declarations repeated in several rules, or having to see what vendor prefixes look like, so be it. To me, WET CSS is much more understandable and maintainable than DRY black box pseudo-CSS.
I don’t want to learn and depend on a non-standard syntax to wrap my CSS in, making it require compilation before browsers can understand it. Neither do I want my colleagues to have to.
I want my source CSS to be deployable at all times, albeit in un-minified, un-concatenated form. If my build process fails, for whatever reason (like an unpublished npm module), I can deploy the source CSS as an emergency solution. Performance may perhaps take a hit, but a slightly slower site is likely better than a site with broken or no CSS until the build process can be fixed.
I don’t want to have to wait for compilation before seeing the results of my CSS changes. Processing time may be anything from negligible to frustrating, obviously, but if it takes longer than the time it takes for me to switch from my code editor to my browser and reload the page (≈1s) it’s too slow.

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:

sorting declarations and fixing coding style issues with CSScomb
automatically inserting vendor prefixes wherever they are necessary (or removing them wherever they’re not)
inserting fallbacks for custom properties
linting CSS

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