In defence of CSS preprocessors

I have been using CSS preprocessors for a couple of years now. Sass combined with Compass has earned itself the title of most valuable item in my web developer toolkit.

I mean that. If I had to live without any of my web design and development tools, I would sooner lose Photoshop, Textmate or any other of my expensive pieces of software than I would live without Sass and Compass.

Yet, it is voices speaking out against the use of CSS preprocessors that I hear much more frequently than those speaking up for it (and it is usually people who have not even used such tools that speak out the loudest).

Those detractors of CSS  pre-processors use a number of arguments to justify their stance. Some of these arguments are ridiculous and should be highlighted as such, whereas others are valid concerns and require further debate.

Why CSS preprocessors are a bad idea

I often hear the following arguments used against CSS preprocessors:

I want to use this article to explore each of those arguments in turn, so that we can firstly separate the ridiculous arguments from the valid ones, and then spend a bit more time discussing those genuine concerns.

CSS is simple, it doesn't need preprocessing!

This argument is usually framed within a condescending tweet like “If you need variables in your CSS then you’re doing it wrong!”.

I really don’t get that. A preprocessor is just a tool that can make our life easier. Just like a carpenter might have a jigsaw or electric screwdriver in their tool box. A carpenter doesn’t need to use electric tools, they can get by with a manual saw or screwdriver. But if they can, they might as well use the powerful tool that makes their work easier, right?

I know CSS really well, I don't want to learn a new syntax

This used to be a valid argument. Back in the olden days Sass was your only option in the preprocessor world and it has it’s own shorthand indented syntax. This syntax is not incredibly different from normal CSS, but it’s different enough and I can understand why that might be off-putting to some.

However, along came Less which is essentially exactly the same as CSS. Less boomed in popularity and within a few months Sass released a new syntax called SCSS, which again is exactly the same as CSS. Neither preprocessing tool requires you to change the way you write your write CSS.

Preprocessors only benefit people who haven't already learned CSS properly

I’ve seen this argument made on CSS Wizardry’s Quick Tips resource. I enjoy reading CSS Wizardry and respect and value Harry’s opinion, but on this occasion I think he’s speaking poppycock.

Using my carpenter analogy from above, is a carpenter who uses an electric screwdriver considered lesser a prefessional because they use an electric tool rather than a manual one? It’s nonsense.

Harry goes on to say that we “need to write CSS sensibly, use modular styles and utilise the cascade fully”. Of course I don’t disagree with that, but the two aren’t mutually exclusive. You can use a preprocessor and learn about CSS too.

Preprocessors cause collaboration/maintainability nightmares

If you’re working in a team environment where multiple members are working on the same stylesheets, clearly you can’t have a situation where one person uses a preprocessor and the others are editing the compiled CSS. That’s just daft.

That said, anyone who already knows CSS should be able to be up and running with Sass or Less in a couple of hours, so I don’t see any reason why the rest of the team doesn’t use a preprocessor too. It’s not rocket science, it’s just a case of adjusting your work flow slightly.

On the maintenance issue, lets not forget that a preprocessor generates perfectly normal everyday CSS documents. Anyone can edit those. I personally am often hired by agencies for one off projects that I will likely never work on again, but it is likely that someone else in the agency might have to work on it after I’m finished.

In those cases, I have no qualms about using a preprocessor and leaving my client with both the source code and the compiled stylesheets. They then have the choice to maintain the source code using Sass, or to just maintain the compiled stylesheets.

Both collaboration and maintainability are genuine issues, but they needn’t be show stoppers. It may be that you decide that using a preprocessor isn’t appropriate for a particular project. Fine, but that doesn’t mean it won’t be appropriate for the next.

Preprocessors by design generate inefficient stylesheets

Yes. They do.

It is in a developers nature to always strive for clean, organised and efficient source code. So when we author a preprocessed stylesheet, our immediate concern switches to writing efficient Sass rather than generating efficient CSS.

Heavy use of mixins and excessive nesting can very quickly result in CSS documents being far, far bigger than they need to be. Preprocessors empower us to write cleaner and more semantic HTML markup, but the trade-off is undeniably messier CSS.

Lea Varou wrote a decent article last week discussing these kind of issues. I agree that this is a valid concern, but I disagree with Lea’s conclusion. I still think the benefits of using a preprocessor by far outweigh these potential problems.

When does inefficient CSS become a problem?

Let’s remember, stylesheets are written for browsers to parse styles. Not necessarily, for humans to read and critique.

Inefficient selectors cause the browser to do more work, but when does that get to the point of being a perceived performance hit? I don’t know the answer to that question, but I would hazard a guess that it takes many thousands of selectors before there becomes a noticeable performance hit on the browser.

Is optimisation worth it?

Extra bytes of course create more bandwidth and slower pages, and we should always do all we can to reduce that. But if our stylesheet is a dozen kilobytes larger than it needs to be, is that a problem? I say it depends.

Sure if you’re a high bandwidth site, every byte has a genuine cost effect. But for the vast majority of sites we work on, the benefit of optimisations is less clear cut. I’m not downplaying the value of optimising your website, I’m just saying a balanced view is required in light of the advantages that using a preprocessor brings.

We can code better!

When using Sass it’s all too easy to fall into the trap of over-using mixins, nesting too deeply, and not worrying about modular styles and classes. But as I said above, using a preprocessor and learning how to write sensible and modular CSS are not mutually exclusive.

Sass has an @extend directive that re-writes selectors rather than duplicating styles. It’s possibly the toughest part of Sass to wrap your head round, but it’s there specifically to address these very concerns. Chris Eppstein has written an article explaining the @extend feature.

Ultimately, using Sass is a learning curve like using any other tool. With experience comes the knowledge of when or when not to use a mixin. With experience comes the knowledge of when or when not to nest. With experience comes the ability to truly master the tool.

Conclusions

Clearly, I’m an advocate of Sass (and by association, Compass). I honestly cant imagine web development life without these tools they are so integral to my workflow. Because of that, I can’t believe other people don’t use them, let alone speak disparagingly about them.

As I’ve hopefully shown in this article, there is a discussion to be had about the appropriate use of things like mixins and nested selectors, but we can do that and get on with the job of building brilliant websites - with the help of CSS preprocessors - at the same time, can’t we?