What is The Point of CSS Preprocessors

Written by Paula Borowska on 01 Jul 2014
36,303 Views • Web Development

When it comes to preprocessors some of developers have the opinion that they are fixing something that is not broken. However, I’ve personally found that CSS is a pretty dumb language as it is very repetitive and inflexible.

If you’ve noticed this too but are not yet convinced about the glory and awesomeness of preprocessors like SASS/SCSS, LESS, Compas let me shine some light on what makes them good alternatives to pure CSS. For the examples within this post I’ll be using SCSS and LESS.

Easy to set up

Whether you are using either LESS or SASS, both are easy to set up. SASS can be installed with a few command lines and CSS files are generated automatically too – if you set it up to be that way of course, but this too can be accomplished with a few lines in the command as well. LESS too can be installed with a few command lines actually. If you are a Windows kind of person, LESS does get a bit more complicated. But let’s face it, Windows doesn’t give you too many easy things. However, there are plenty of online tutorials – like this one - that you can follow along to get through the slightly bigger complexity for setting up LESS.

Quick to learn

The syntax changes between both LESS and SASS is very simple, which makes it easy to grasp. I’m not sure if there really is a learning curve for these preprocessors because it is mostly knowing what things to avoid. Most preprocessors get rid of things like the brackets, {}, and semi-colons, ;. The indentations and how to define and call a variable are super easy to get the hang of – especially if you know other programming languages like JavaScript.

Saving you time

The number one thing that preprocessors have to offer is saving you time. You don’t have to repeat the same things over and over again, you can’t write more intuitive code thanks to nesting or functions. Yes, CSS processors have variable, functions and mixins, which allow you to create theoretical objects that you can reuse over and over. My biggest pet peeve about CSS is lack of variables, because I always have to remember a bunch of random hex values, sizes, and other information pieces; after a while it becomes very complicated. With a preprocessor, I don’t have to remember, I can just call a variable or a function.

Writing DRY code

Don’t repeat yourself, or DRY, means you shouldn’t write the same code over and over again. It’s a very prominent rule actually because it helps keep your code clean. However, CSS makes that very difficult because every new CSS rule needs its own properties, by default you need to repeat things like font-family, colour, or font size. Most CSS preprocessors help you make the best of nesting or importing so that you don’t have to write out the same things multiple times. For the properties that you don’t want specifically, just override them.

CSS:

h1 {
	font-family: Arial, sans-serif;
	font-weight:bold;
	font-size:30px;
}
h2{
	font-family: Arial, sans-serif;
	font-weight:bold;
	font-size:25px;
}
h2 {
	font-family: Arial, sans-serif;
	font-weight:bold;
	font-size:20px;
}

SCSS:

h1 
	font-family: Arial, sans-serif
	font-weight: bold
	font-size:3 0px

h2
	@import h1
	font-size: 25px

h2 
	@import h1
	font-size: 20px

/*You can also nest within SCSS:*/
h1 
	font-family: Arial, sans-serif
	font-weight: bold
	font-size:3 0px
	
	h2	
		font-size: 25px
	
	h2 
		font-size: 20px

LESS:

h1  {
	font-family: Arial, sans-serif;
	font-weight: bold;
	font-size:3 0px;
}
	h2 {	
		font-size: 25px;
	}
	h2 {
		font-size: 20px;
	}

Mixins are prefix heaven

Most preprocessors come with mixins for CSS properties which aren’t fully supported and need prefixes like –moz or –o. If you proceed to use such mixin it will compile the selected property for you with the required prefixes making your life easier. Seriously, like I’ve been saying it saves you a lot of time by making your coding life easier.

CSS:

.box {
	-moz-border-radius: 5px;
	-ms-border-radius: 5px;
	-o-border-radius: 5px;
	-webkit-border-radius: 5px;
	border-radius: 5px;
}

SCSS:

@mixin  border-radius
	-moz-border-radius: 5px
	-ms-border-radius: 5px
	-o-border-radius: 5px
	-webkit-border-radius: 5px
	border-radius: 5px

.box
	@import border-radius

LESS:

.border-radius{
	-moz-border-radius: 5px;
	-ms-border-radius: 5px;
	-o-border-radius: 5px;
	-webkit-border-radius: 5px;
	border-radius: 5px;
}

.box{
	.border-radius;
}

Easier to maintain

This advantage point is made perfectly to explain to you why variables are the best thing about preprocessors. You see, if you have an accent colour, per se, when you define it to be a specific hex value you can just call that variable all over your code. This works exactly the same way as it does in JavaScript or other programming languages like PHP. In plain old CSS you have to know which hex value your accent colour is and repeat that over and over and over… However, if the said accent colour changes, all you do is change the variable value and it then take effect within the whole code. Again, in plain old CSS you have to find the old hex value and individually replace it with the new one. Like I said, it’s much easier to maintain.

SCSS:

$off-white: #fefefe
$charcoal-gray: #262626
$pink: #fe6969

body
	background-color: $off-white
	color: $charcoal-gray

p
	color: $pink

LESS:

$off-white: #fefefe;
$charcoal-gray: #262626;
$pink: #fe6969;

body {
	background-color: $off-white;
	color: $charcoal-gray;
}

p {
	color: $pink;
}

Organizing is easier

Nesting is the second best things aspect of preprocessors as it allows you to easily organize your code. You can indent all you want within regular CSS but you can still have different rules that relate to one another all over your whole style sheet. By nesting variables within each other not only are you organizing your rules but also reuse previously stated properties to new ones; did I mention that these preprocessors save you time and effort?

CSS:

h1 {
	font-family: Arial, sans-serif;
	font-weight:bold;
	font-size:30px;
}
h2{
	font-family: Arial, sans-serif;
	font-weight:bold;
	font-size:25px;
}
h2 {
	font-family: Arial, sans-serif;
	font-weight:bold;
	font-size:20px;
}

SCSS:

h1 
	font-family: Arial, sans-serif
	font-weight: bold
	font-size: 30px
	h2
	   font-size: 25px
	
	h2 
	   font-size: 20x
LESS
h1 {
	font-family: Arial, sans-serif;
	font-weight: bold;
	font-size: 30px;
}
	h2 {
	   font-size: 25px;
	}
	h2 {
	   font-size: 20x;
	}

Don’t knock it till you try it

In all honesty I can list as many pros or cons for preprocessors as I want it all comes down to you trying them out. The ultimate decision is yours whether you come to like them and use them or you too will find that they are trying to fix something that isn’t broken. I think it would just be simpler for me to shut up about them and let you try them out all on your own. Once again, here are some links to get you started: SASS, LESS, Compas.

Conclusion

Please don’t get me wrong, there are disadvantages to preprocessors too, like there are to everything, but I wanted to show you what made them great. Personally, I believe they are nifty tools actually, which can help you write CSS with greater ease. Some even say that CSS preprocessors make writing CSS fun! Don’t knock it till you try it as preprocessors are becoming more and more popular and I hope this post convince you to at least give them a try!

Join the discussion

Comments will be moderated and rel="nofollow" will be added to all links. You can wrap your coding with [code][/code] to make use of built-in syntax highlighter.

4 comments
Ruffo 10 years ago
After a couple of years doing front-end, I highly recommend using (any) preprocessor:

- high maintainability (seriously)
- DRY code
- helps you to BEM-ified your elements/layout/template.
- saves your time (and ass)

but your css is not going to be "better", you need to know what you're doing first. Don't forget of getting involved how css rules works and when are they need it.
Reply
iFX 10 years ago
Nice post - I'll have to check them both out...

Although, your h-tag examples might not be the best way to show the power of the preprocessors, since you could rewrite:
(I'm assuming the 2nd h2 was supposed to be h3?)


h1 {
font-family: Arial, sans-serif;
font-weight:bold;
font-size:30px;
}

h2 {
font-family: Arial, sans-serif;
font-weight:bold;
font-size:25px;
}

h3 {
font-family: Arial, sans-serif;
font-weight:bold;
font-size:20px;
}



You could rewrite that in CSS as:


h1, h2, h3 {
font-family: Arial, sans-serif;
font-weight:bold;
font-size:30px;
}

h2 {
font-size:25px;
}

h3 {
font-size:20px;
}


which wouldn't be that much different to the LESS version.
Reply
Eric Vaughan 10 years ago
Under the Writing DRY code section, the LESS code you wrote won't compile the h2 and h3 with the h1 styles. Indentation doesn't do anything in the LESS compilation.

You could write:

h1,
h2,
h3 {
font-family: Arial, sans-serif;
font-weight: bold;
font-size: 30px;
}
h2 {
font-size: 25px;
}
h2 {
font-size: 20px;
}

Though that's just plain CSS. In LESS you could use extend to do this:

h1 {
font-family: Arial, sans-serif;
font-weight: bold;
font-size: 30px;
}
h2 {
&:extend(h1);
font-size: 25px;
}
h2 {
&:extend(h1);
font-size: 20px;
}
Reply
Bui 9 years ago
If you write the css correct in the first place, then you don't need this added layer of production, this is another example of programmers trying to be clever with no experience in true optimized css creation. - DRY is standard for css creation, what's next, html pre processors lol, slowdown man,...lol :)
Reply