CSS Pre-processor: SASS

It can be very cumbersome writing CSS code when doing it for a large site. They tend to be repetitive, long, complicated, and messy. Debugging large CSS sites can become a nightmare because of this. Using a CSS pre-processor is the solution for many frontend developers, of which SASS is the most popular and preferred.

A pre-processor is a program that acts as a sort of middleman between a client program and the compiler. It receives input in a particular language, processes it, translates it, and sends out output in another language’s syntax.

SASS (Syntactically Awesome Style Sheet) is the middleman between regular CSS and the compiler. Its primary purpose is to cover up the flaws of standard CSS and extend CSS's syntax by adding new instructions. Now, a developer writes in SASS syntax, but the output is compatible with all CSS versions and works well with any website.

Ruby – written in SASS – frequently referred to as 'CSS with Superpowers', is a basic programming language. It extends CSS's functionality by bringing with it the paradigms of traditional programming like functions, loops, variables, nesting mixins, inheritance, and so much more. If you are wondering or scared about using SASS because it is a programming language, you shouldn't. It is fundamental and takes on the form of CSS. If you have good knowledge of CSS, working with SASS won't be a problem at all.

SASS vs SCSS

SASS has two syntaxes. SASS, its own syntax and pre-processor, and SCSS (SASSy CSS) is another syntax of the SASS pre-processor. They both have the same pre-processor, and that SASS is a syntax, and a pre-processor is one reason why SCSS and SASS are often confused together. SCSS syntax is like SASS and has the same functionality – to extend CSS features. There are, however, certain differences between them.
SASS pre-processor is Ruby powered. SASS's syntax adopted Ruby's style, strict indentation, no semicolons, and no braces syntax. SCSS, on the other hand, was developed to bridge the gap between CSS and SASS syntax. SCSS got its name 'SASSy CSS' because it creates more CSS features and still maintains its core features. Just like CSS, SCSS uses curly braces and semicolons. Every valid CSS file is also a valid SCSS file – it will work after changing the file extension from .css to .SASS. However, the reverse action is not possible.

Here’s a simple code showing the difference between the syntax of SASS and SCSS.

SCSS

div { 
  border: 2px; 
  background: red; 
}

SASS

div 
  : border 2px 
  : background green

While SCSS is written like regular CSS, SASS syntax places the colon as a prefix to property names. It uses new lines to separate expressions instead of semicolons. It also uses indentation to separate selectors from property names and their values (instead of curly braces).
Although SCSS is the younger and more recent of the two, it is more popular and widely used than SASS. This is because of its CSS friendly nature. For the examples in this article, we will use SCSS since it is closer to CSS than SASS and easier to understand.

Installing SASS

To use SASS, you need to install Ruby and install it on the command line. You can also use third-party applications like CodeKit, PrePos, Hammer, Scout-App, and Ghostlab to get it up and running. Check out the official SASS documentation - https://SASS-lang.com/install on the different ways of installing and running SASS.
SASS is operating system independent, meaning it runs on Linux, Windows, and Mac. It also supports all major browsers – Edge, Chrome, Opera, Safari, and Firefox. This makes it readily available to every developer who wishes to learn.

Features of SASS

As earlier mentioned, SASS stretches CSS's features, and we will look at these features and how they make your CSS powerful and easier to maintain.

Variables

The purpose of a variable in SASS is the same as regular programming. It allows you to store values that will be used frequently throughout the program. Properties like color and fonts are the most common and recurring in a stylesheet. They can be stored as variables in SASS, allowing the developer to reuse them at will, without writing them out every time.

SCSS uses a dollar sign ($) symbol as a prefix to the variable names.
In CSS, for example, I could have the following in my code.

  font-size: 16px; 
  background-color: #000000; 
  color: red;

Any time I want to use them, I must rewrite them out, explicitly.
In SCSS, we can have this.

$bgcolor: #000000; 
$fontsize: 16px; 
$fontstack: Arial, Sans-serif; 
$mywidth: 700px; 

body{ 
  font-family: $fontstack; 
  background-color: $bgcolor; 
} 

div { 
  font-size: $fontsize; 
  width: $mywidth; 
  font-family: $fontstack; 
}

You could argue that CSS id and class selectors reduce repetition. Yes, but it doesn’t eradicate it. More so, I may not want to assign a class or id to a particular element because it may have more than the properties I need. Writing more styles for specific selectors makes the code more bogus.

Nesting

Nested codes are codes inside another code. Nesting allows you to mimic your HTML elements' hierarchy and target elements in a much cleaner way. It gives the code a better structure and makes it easy for you to find elements during debugging.

In regular CSS, the code is defined one by one, and it could be anywhere on the file. We have:

nav ul { 
list-style: none; 
  margin: 0;
  text-align: right;
} 
nav li { 
  display: block;
}
nav a { 
  padding: 2px 4px;
  text-decoration: none
}

This code snippet can be nested in SCSS as:

nav { 
  ul { 
    list-style: none; 
    margin: 0; 
    text-align: right; 
  }    
  li { 
    display: block; 
  } 
  a { 
      padding: 2px 4px; 
      text-decoration: none; 
  }
}

The ul, li, and a selectors are placed inside the nav in the SCSS, making it look more readable and organized.
Nested codes in SCSS should be specific and straightforward. Having an elaborate nesting can create more confusion for the developer and make the code difficult to read and maintain. Instead of having one extended nested code, the code can be nested in different small groups to allow readability.
Using & When assigning values to pseudo-classes in CSS, we tend to repeat the selectors and the pseudo-classes. We could have:

a { 
text-decoration: none; 
  color: #ffffff; 
} 
a:hover { 
  color: #000000; 
}

In SCSS nesting & can be used to target upper/outer parent selection. Meaning, it recognizes that a selector has been specified in the lines above (parent selector), it identifies it and replaces it in subsequent inner selection. The & selector makes it possible to reuse parent selector in more diverse ways, but most notably on assigning values to nested pseudo-classes.
The CSS code above, in SCSS, becomes,

a{ 
  text-decoration: none; 
  color: #ffffff; 
  &:hover{ 
    color: #000000; 
  } 
}

Mixins

SASS's beauty is in how it simplifies CSS and makes it DRY (Don't Repeat Yourself). Mixins are an essential aspect of SASS because they emphasize the core purpose of SASS – to keep things simple.
Mixins behave like functions, although they are not SASS functions. They allow you to write reusable blocks of code that would be repeatedly used on your site. The mixin can take arguments, too, just like functions. A mixin is defined using the @mixin directive, and it can be called anywhere in the file using the @import directive.
One notable area where mixins can be utilized is in writing browser vendor-prefixed properties. These tend to be very long and repetitive. Here’s an example of how to use mixins.

@mixin border-radius($radius) { 
  -webkit-border-radius: $radius; 
  -moz-border-radius: $radius; 
  -ms-border-radius: $radius; 
  border-radius: $radius; 
}
div { 
  @include border-radius(20px); 
}

Typically, in CSS, the vendor prefixes would have to be reused anytime we need them. This condition changes in SCSS after we have defined them once using @mixin.
Here’s another example

@mixin fontstack( $family: 'Ubuntu' , $weight: 400 , $style: normal ) { 
  font-family: $family , 'Arial', 'Helvetica', sans-serif; 
  font-style: $style; 
  font-weight: $weight; 
}

Note that values were declared in the mixin, so we don’t have to specify them again when using @import

div { 
  @include fontstack; 
  text-transform: uppercase; 
}

This is compiled into

div { 
  font-family: 'Ubuntu', 'Arial', 'Helvetica', sans-serif; 
  font-style: normal; 
  font-weight: 400; 
  text-transform: uppercase; 
}

Import

Like CSS, SASS allows you to use @import directive to include one file in another, but SASS @import directive trumps CSS @import directive. When using CSS import, HTTP requests must be made separately for each file to be imported. The SASS @import directive merges all its files in a single CSS file, so the HTTP request is made just once.
Instead of having one long SASS file, you can maintain different smaller files that perform specific purposes and import them into the main file using the @import directive. Let's assume we have a SASS file called theme.scss and variables.scss.

@import "themes"; 
@import "variables"; 

You could add the above code at the top of the file. File extensions are not needed as SASS automatically assumes you either have a .scss file or .SASS file, both of which are acceptable.

Why SASS?

There are many reasons to use SASS, but here are the most important ones:

  1. It keeps broad code consistent
  2. With variables and mixins, code is kept DRY.
  3. Changes are made quickly and efficiently.
  4. The code is easier to read and maintain.
  5. It is a cleaner, leaner form of CSS.
  6. It has a great community and documentation

Conclusion

Both SASS and SCSS are valid CSS syntaxes for the SASS pre-processor. If you are not sure which to use or learn, you can start with SCSS. SCSS files can be converted to SASS files using SCSS-to-SASS converters, so you need not worry if you want to switch later.
SASS is not the only CSS pre-processor available. Other CSS pre-processors include Less and Stylus. Although SASS is not included in the official CSS documentation, it is widely accepted and compatible with regular CSS. It has its own official documentation, guide, and a great community to help you out.

Author

Mariya Videva | UX Strategist  | UI/UX Designer

Mariya is an experienced User Interface (UI) and User Experience (UX) expert, with a strong tendency toward improving Customer Experience (CX). After a successful brainstorming session, she implements the user experiences used by millions of users thereafter.
There is no problem big enough for her not to tackle a solution to sometimes sophisticated user flows. User Experience Strategy sits at the heart of her actions, making her think ahead of time and beyond implementation.