7 Sassy Reasons You Can’t Avoid CSS Preprocessors Anymore


CSS preprocessors have been with us for some time now and we’ve moved on from the debate over whether you should be using one one: you almost certainly should. Yet for many CSS coders out there preprocessors are just another item on a long list of things to learn – and there never seems to be enough time.

If this sounds like you, you’re not alone. Many other coders out there are fighting the clock and I myself put off diving into Sass (my personal choice of the preprocessors) for way too long. However, my only regret is that I didn’t jump into CSS preprocessors sooner – because it’s one of the best time investments I have made as a coder and I can’t even guess how many hours it has saved me over the last few years.

Don’t Procrastinate, Preprocess

I can see two main reasons why you still wouldn’t use a CSS preprocessor at this late a stage. The first reason is the time issue mentioned above. It’s hard enough keeping up with your client work as it is, without sitting down to learn yet another syntax – especially when there is nothing wrong with your CSS the way it is.

The other reason that comes to mind is the moment you first look at preprocessors – after all the buzz about how it will speed up your workflow – and you see something like this:

Thanks, but no thanks might be the first thing that comes to mind – especially if you never get involved in any programming languages. However, the above sample is the scariest example I could find in the Sass documentation and the basics of preprocessing are incredibly easy to pick up. And because all CSS is valid in preprocessors like Sass, you can carry on using CSS the way you always have and slowly integrate new features at a pace that suits you.

What Preprocessing Isn’t For

Before I go ahead and praise the wonders of preprocessors any more, I want to make a point of saying that they are not designed as a quick fix for sloppy CSS. One of the major benefits to Sass and other preprocessors is that it makes CSS cleaner – but your CSS files need to be clean to start with.

The above code is a simple example of needless repetition and you can fix this with preprocessors by using the @extend directive (in Sass) which we’ll take a closer look at later:

Which is fine, except your .css files should be cleaner than the first example anyway – all it takes is a another class name on a couple of HTML elements and you get the same effect:

You should already be taking this approach with your HTML and CSS – with clean code high on your list of priorities. This is something you will need to get the most out of CSS preprocessors.

Choosing The Right Preprocessor

There are a number of preprocessors you can choose from and to my knowledge Sass, Less, Scss and Stylus are still the favourite choices. For me the winner has got to be Sass and this would be my recommendation to anyone who asks the question.

That said, there isn’t so much between the likes of Sass and LESS that you need to worry about which one you choose. In fact, it’s more important that you simply start using one of them, because even the basics of preprocessing will save you a heap of time.

So today we’re looking at the seven basic features of Sass – although can expect very similar things from the other major preprocessing tools out there.


One of the best features in Sass is that it brings variables to CSS. which means you can store information to call upon at a later date – just as you would in JavaScript or other programming languages.

Now the above may not look like much, but what it means is that you can store primary, secondary and other colours for projects and systematically call on them as needed to put together colour schemes in an instant.

It also means no more scrolling through an entire stylesheet to find a single hex code, font stack or other repeated styles.


Sass also lets you nest your styles in a similar way to HTML markup – giving your styles a touch of visual hierarchy.  This makes your .scss (Sass CSS) files a much clearer in terms of structure – something that traditional CSS really lacks.

At the same time you shouldn’t get too carried away with this feature, because overly nested rules can actually cause more harm than good. Here is the sample code from the Sass guide for nested rules:


One of my favourite features of Sass is the ability to create partial .scss files. This allows you to create and call separate stylesheets instead of keeping all your styles in a single file. For example, you can create separate reset.scss and fonts.scss files and call them with the @import directive – a great way to modularise your stylesheets and make them more maintainable.


Partials are just one example of how you can use the Sass import directory – and you’re probably wondering what’s so great about a feature you already have in standard CSS. Well, the great thing about Sass imports is that – unlike the CSS equivalent – Sass doesn’t create another HTTP request. Instead they essentially combine the files into a single CSS file for the web browser, making the whole process much quicker.


One of the key frustrations for us in the early days of CSS3 is the need to rewrite endless vendor prefixes for things like border radius and other poorly supported rules. Sass makes this process a whole lot faster with the @mixin directive.

All you need to do is name your mixin (border-radius in this case) and type the prefixes as you would normally. The example above also sets a variable ($radius) which allows you to pass a radius value each time you call the mixin to any selector with the @include directive. In this case the selector .box has been given border-radius mixin with a radius value of 10px.


Another killer feature in the Sass collection is the ability to share CSS properties between different selectors and keep your .scss files super dry. The example below is taken directly from the Sass online guide:

The @extend directive calls the previous styles from .message into each of the following selectors. At a first glance this may not look much much help – after all you can remove the @extend .message lines and your stylesheet is instantly cleaner. Except this approach saves you stacking endless class names in your HTML markup for more complicated style rules.


You simply can’t write a modern stylesheet without crunching some numbers and Sass comes with a bunch of maths operators to help you calculate widths and other numeric values.

Using the +,  -,  *,  / and % operators you can create intuitive grid layouts and other responsive elements in no time.

Just the beginning

This is just an introduction to the powers of Sass and other preprocessors, but hopefully you can already see how even the basics can save you bundles of time, as long as you use them the right way.

So if you’re still putting off the jump into CSS preprocessors, take a look at Sass and start by implementing the basics into your workflow – I promise the time you invest is more than worth it.