Let’s talk about Sass. No, not that kind of Sass


“I’m a hesitant believer in Sass. I write stylesheets by hand! I don’t need help and I certainly don’t want to add extra work to my flow. Go away!”

That’s what most people are thinking when they hear the word Sass, which is another new technology. What one might fail to realize is that Sass, along with other preprocessors like LESS, can be powerful tools that any programmer can implement into their code.


Sass stands for – Syntactically Awesome StyleSheets

I’ll try to explain in the simplest way possible.

Vanilla CSS is very chatty, which means that there is considerable repetition. Copy-paste is often required to get certain things done. Any time that you copy and paste code from one place to another, you introduce the possibility of accidental errors in your program. If you want to change the code, you’ll have to change it everywhere. The more you copied it, the more likely it is that you’ll miss something when you update it.

Syntactically Awesome StyleSheets are a “preprocessor”.

The idea behind a preprocessor, like Sass, is that your code contains far less of those repetitions, which means that it’s easier to make changes “in one place” and have them broadcast throughout the stylesheet. Specific colors and other repetitive styles become much easier to implement and maintain.

Let me show you the difference between vanilla CSS and SASS using the same block of code:


Picture 1-1

On the left side, we have CSS code that gives each background and font color its own specific color. If you’re working on a large project and find out there is an error in the color, you would have to go back and look through hundreds of lines of code, then change each color to the correct one.

Look at the right side where we have the same code, but this time it is in Sass. First, we define a variable and initialize it with its own color. We then use that variable throughout the code and place it wherever it is needed. If you were to find an error in the color, all you would need to do is change the variable color up top and the whole stylesheet would make that change automatically.

This is just one of the amazing things about using Sass.


Sass does not use curly braces or semi colons. This is great because these are repetitive keystrokes and take up time. It also uses indentation and nesting for hierarchy, instead of long selectors. Nesting isn’t new – JavaScript, HTML and other languages use it to help programmers track parents and their children. Unfortunately, vanilla CSS lacks this technique.

Because of its rules about indentation, it is hard to write unreadable Sass. Sass forces you to write your code the same way every time. On large teams or in situations where you aren’t the sole author of all the code, this could be a significant advantage. It forces the team into using more strict coding practices and leaves little room for deviation from the beaten path. I’ll show you a great example below, which uses nesting instead of an extensive list of selectors to reach a specific element.

Picture 1-2

On the left side, we typed out “#mainDiv .subDiv p p” to change the font-size of a specific child. However, on the right side we simply nested our selectors.


As mentioned in the example above, another powerful feature that Sass borrows from programming languages is the concept of variables. Variables recycle repetitive styles like font names, numbers, colors, etc.. If you can write it in CSS, you can store it in a variable. They store this information into “buckets” that you can reuse throughout the rest of your stylesheet. You can even set global variables and use them throughout all of the files without having to declare them several times.

This brings me to my favorite thing about Sass: mixins. Sass mixins are the stylesheet equivalent of functions. They allow you define a series of rules which can easily be mixed in to another ruleset. Take for example, displaying an HTML element as a Flex element. Creating a mixin is very simple. All that we need to do is to use the @mixin command followed by a space and our mixin name, then we define the style. It is something like this:


Picture 1-3

Therefore, instead of giving multiple elements a Flex display, we declared a mixin which can be reused in your stylesheet.


Sass fuels better responsive design. The CSS way of writing media queries often separated the queries by including them at the bottom of the stylesheet. In Sass, it’s more integrated and nested in a sheet with the “respond-to” mixin. It’s easier to write media queries and to create responsive breakpoints, which makes the overall design process easier. Sass’s approach to responsive breakpoints is much cleaner, because it’s contained in that one mixin.

Do you want to see something really cool? Say you wanted to adapt Bootstrap’s 12 column concept but modify the automatic width instead. Sass allows you to avoid writing almost the same thing 12 times. I created a mixin, or function, that loops through the numbers 1 – 12 (12 columns) and will determine the specific width needed to make your app responsive. Check below:


Picture 1-4


I mentioned earlier that I was reluctant to try Sass. Let’s clear up a few things. You can use the terminal/command line as a compiler or you can use an application. Don’t be afraid of the command line. I sympathize with designers and front-end developers who don’t want to go there. For Sass, there’s very little command-line action required – in fact, a single command is all you need to grasp.

If you’re particular about the way your stylesheets are organized, remember that the Sass syntax is a superset of CSS3, so you don’t have to change anything about the way you write CSS.

Embrace change! Sass and languages like it are the future. Yes, you can complain about the syntax. You can complain about the generated code. However, the productivity and simplicity that languages like Sass offer will ultimately win over the masses.

Be the first to comment

Leave a Reply

Your email address will not be published.