The disadvantages of CSS preprocessors

CSS preprocessors have many advantages. But like most tools, they also have a number of drawbacks which I’ll describe here.

# 1. Debugging is harder

Preprocessors have a compilation step, meaning that CSS line numbers are irrelevant when trying to debug our code. But debugging is twice as hard as programming, so this alone is a huge drawback.

“Debugging is twice as hard as programming”

Brian Kernighan

Source maps provide a solution, but they need to be setup and they don’t work in all browsers, particularly those where bugs often come up.

Without source maps, we’re left to search for rules in the hope that we find what we’re looking for.

# 2. Compilation slows down development

Compilation times can be really slow, even when using the best tools on the fastest computer. You know that feeling you get when you refresh and don’t see any changes—that.

# 3. They can produce very large CSS files

Source files may be small, but the generated CSS could be huge which is what counts.

We need to be aware that in using a CSS preprocessor, we’re losing some control.

# 4. Maintainence and overengineering

It’s common to see coder authors using a red variable, for example. But this is of little value in terms of maintainability.

If the colour changes, then we need to update the name and the value, making the abstraction pointless.

Not only are there alternatives to variables and mixins, which I’ll cover later, but a search and replace maybe all we need.

# 5. Tooling and developer convenience

CSS preprocessors require extra tooling. Code authors shouldn’t be forced to use a particular editor just to be able to use the tool. That’s the tail wagging the dog.

Also, extra stuff adds complexity. This needs to be understood, upgraded and maintained—all of which increases cost and a higher risk of problems.

# 6. Saving generated files (or not)

Whether we should save the generated CSS or not is something we don’t agree on as a community. In which case, it’s time for some Concensus Driven Development.

# 7. Capability and understanding

Whilst CSS preprocessors and the workflows around them have become widespread, there is still a knowledge gap. Particularly, when it comes to understanding the trade-offs.

There’s a big difference between understanding a tool, and using it effectively without introducing other problems.

# What about variables, mixins, and nesting?

A solid approach to writing maintainable CSS solves most problems. In anycase, we can mimick variables and mixins by using comma-delimited CSS selectors:

selector,
anotherSelector {
  /* common rules */
}

And, whilst we can repetitively qualify our selectors to mimick nesting, it’s not something that makes for performant CSS. Instead, we should use a convention.

# Summary

It’s easy to add a CSS preprocessor to the tech stack. But, it’s not easy to remove it down the line, should we so choose.

It’s our responsibility to consider the impact they have on our work flow before making the easy decision to install one.