Jezen Thomas

Jezen Thomas Jezen Thomas

I'm a Haskell/Elm programmer, the founder of NBM, co-founder of Comparestack, and a public speaker. Occasionally I write about technology, and currently I am perpetually travelling the world. Find me on Instagram, or on GitHub, or write me an email.

Keeping CSS Simple

In a previous day job, I suggested removing all instances of Less. Not because it’s bad, or because Sass is “better” in some way.

I suggested removing it and not replacing it with Sass, instead keeping with plain CSS because I felt the team had not shown the discipline to not abuse the extra power a pre-processor gives you.

The codebase was a tangle of nested rules which results in overly complex and specific selectors. When specifics of those need to change, the team doesn’t back out of the existing specificity, but instead overwrite it with more. Add to this a liberal helping of mixins — because “code reuse”, apparently — and the resulting CSS is applied, disabled, reapplied, over and over.

My suggestion to not use a CSS pre-processor was met with much flapping and exasperation.

But everyone uses pre-processors! That’s just the way it’s done!

You can chalk up the above to both the Bandwagon and Appeal to Authority logical fallacies. These fallacies are particularly widespread in software development. To paraphrase Alan Kay and then take him slightly out of context, software development today is more popular culture than engineering.

Any flavour of CSS pre-processor gives you objectively more power when writing web page styles. But do you need that power? Or is that extra power just rope with which to hang yourself? I think the benefits of pre-processors don’t outweigh the drawbacks, especially in the hands of the enthusiastic but inexperienced.

Plain CSS gets you plenty far enough.