Everybody who’s anybody is using CSS preprocessors!
Or so it feels. I’m an old-school vanilla CSS curmudgeon, and the more I’ve dipped my toes into working with CSS preprocessors (specifically, SCSS with Compass), the less I like them.
As I see it, there are three main problems with vanilla CSS:
No variables. Honestly this is probably the only problem I really have with CSS. I’d like to be able to set variables for things like colors that I use throughout a site. To a lesser extent, I see the benefit of “mixins” — reusable chunks of CSS.
Redundant code. It really depends on how you conceptualize your CSS structures, but it is very easy to fall into a habit of writing the same CSS code over and over again, resulting in bloated, hard to maintain files. While I am guilty of this just like anyone else, I find that if you format your CSS code properly you can combine properties efficiently to avoid redundancy without needing any external solutions.
Lack of programmatic logic. Here I’m thinking about things like conditional statements, and also math operations. This is probably as much of a strength as a weakness. CSS is a stylesheet, not a program. It’s a set of rules to be applied to formatting a document. There’s nothing programmatic about it. But still, as CSS selectors become more complicated and convoluted, it is clear that in some cases light programming logic would be helpful.
The real question is, do CSS preprocessors actually solve these problems? Or, more specifically, do they solve them without introducing new problems that are at least as bad as the ones they’re trying to fix?
For me the answer has been, and continues to be, no, they don’t. But I’m trying to get a more tangible explanation for why that is, rather than the simple gut feeling that’s been driving me away from using them up to this point.
What are other people saying?
My first stop in trying to answer this question of why I dislike CSS preprocessors was Google. I wanted to see what other people were saying, pro and con. Here are some interesting blog posts I found, going back a few years to the early (or at least earlier) days of CSS preprocessors:
The problem with CSS pre-processors
This article by Miller Medeiros was the first one I came across a few months ago when I initially pondered this question, and at the time it was all I needed to satisfy myself that I was not crazy for wanting to avoid CSS preprocessors.
So, assuming preprocessors do solve the problems with vanilla CSS, what are the problems they introduce? And how bad are they, really?
I need to get specific to my own situation for a minute here. I have a former coworker who is a firm believer in SCSS, and now that he’s gone, I’m left to maintain and extend the code he was writing. This experience casts my aversion to CSS preprocessors into stark relief.
Maintenance can be a challenge
The most obvious issue with using a preprocessor is that the output CSS is not exactly easy to hand edit, and worse, you shouldn’t hand edit it, because your changes don’t end up back in the original SCSS (or whatever format you’re using) files. If someone else goes back in later and edits the original SCSS and generates new CSS, your changes will get lost.
But let’s set that matter aside for a minute. In a broader sense, one of the key challenges for any web developer is to build code that is easy to maintain. Not just for you to maintain, but for whoever comes after you to maintain. Face it, you’re not going to be working on this project forever. At some point, someone else is either going to need to take it over, or throw away what you did and start fresh.
If you’ve ever jumped into an existing project midstream, or been handed the task of maintaining something someone else built — especially if it’s something built by someone who is no longer around to answer your questions — you know that it’s rarely an ideal situation. Even if the previous developer left copious documentation, it can take hours of picking apart their code to really get a firm understanding of how it all works. This is true with plain CSS too, but at least with plain CSS it’s a lot less work to track down a particular piece of troublesome code.
It’s non-standard
What happens when certain features of your favorite preprocessor get rolled into a future version of vanilla CSS? What happens if similar (but incompatible) features of a different preprocessor become the standard? In short, what if everything you’re doing right now becomes obsolete? How long are you going to hang on to doing things your old way with your no-longer-relevant preprocessor, before you have to scrap it and start over, or at least rewrite big chunks of your code to fit the new way everyone is doing things?
Call me a curmudgeon, but having been a professional web developer for over 18 years I’ve seen a lot of technologies and design trends come and go. I’ve always been skeptical of anything non-standard. I never used VBScript or ActiveX, I never embraced Flash, and in general I’ve done everything I could to both champion and adhere to open standards as much as possible throughout my career.
Suffice to say, resisting CSS preprocessors is just in my blood. They just don’t feel right to me. I’d rather do without features I want, if they’re not part of the standard, than resort to a non-standard workaround to make them happen… especially if it looks like there’s a reasonable chance they’ll be added to the standard at some point in the not-too-distant future.
