Why you should use Sass over CSS

If you are new to web development, probably still navigating HTML and CSS you might have heard the term, “Sass” flying around with a lot of people proposing that you should try it out that it would lead to a better styling process than CSS. Why is this so? In this article, we would be looking at what Sass is and why writing your stylings in Sass rather than in Vanilla CSS is a better move or if it does not matter at all.

Alright, let’s head right in.

What is Sass?

Initially designed by Hampton Caitlin and developed by Natalie Weizenbaum. Sass is short for Syntactically Awesome Stylesheet and it is a CSS preprocessor that provides mechanisms such as variables, nesting, mixins, imports, functions and selector inheritance into regular CSS. A preprocessor is a program that processes its input data to produce output that is used as an input to another program. So Sass as a CSS preprocessor means its inputs, which is written in SassScript, are compiled into CSS. Sass is the most popular but not the only CSS preprocessor out there, others include Less and Stylus.

Sass uses two syntaxes; the original syntax, called “the indented syntax” or simply Sass and the newer syntax, “SCSS” (Sassy CSS). Sass uses indentation to separate code blocks and newline characters to separate rules while using .sass as its file extension. SCSS uses block formatting just like CSS. It uses braces to denote code blocks and semicolons to separate rules within a block. The SCSS uses .scss as its file extension. For code snippets in this article, we would use the SCSS syntax.

So why should one use Sass rather than plain, old CSS?

A brief answer to that would be that Sass makes writing stylesheets faster, easier, more flexible and easier to maintain by letting us use features that do not originally exist in CSS. Let’s look at these features independently to understand how they help us write stylesheets easily.

1. Variables

Variables in Sass work in the same basic way, variables in other programming languages do, which is that they let you store information in a particular variable so that you can reuse it across the files. Sass lets you store the values like numbers, colours, strings and booleans in variables. The basic syntax for variable declaration is using a ‘$’ before the variable name.

$variableName: variableValue;

After the variables are declared, they can be used anywhere within the stylesheet. This feature helps you save time by reducing repetition in the case where you are to use the variable value repeatedly through the file. For example, if you created a site with its base colour being #3895ff and the client later wants slightly tweak it to #56a3fa. Ordinarily, this would involve making the change through lots of lines of code in several style sheets but Sass, this change can be made at one line and the change is then effected across the stylesheet.

The example below illustrates how variables in Sass work.

2. Nesting

Nesting is another remarkable feature in Sass. It lets you declare blocks of code within the braces of a parent declaration. The idea is to do it in such a way as to mimic your HTML hierarchy. It makes the code cleaner and easier to read. A con of nesting is that you can run into problems if you nest your code too many levels deep.

The example below illustrates how variables in Sass work.

3. Mixins

Mixin is another powerful feature in Sass. This feature allows you to create a certain block of code and then reuse it across the file. The @mixin directive lets you create CSS code that is to be reused throughout the stylesheet and the @include directive is created to let you use the created mixin with the declaration you want to use it.

Say for example if we have four links set in an unordered list and we wanted to style, each with a different background colour, border and some other property. These links would have similar properties but different values for each of them. Ordinarily, we would write it like this example below;

Notice how the list item property had a color and border which was initially inherited by all of the list items until a more specific value was given to the border, color and background properties of some of them. That is a lot of repetition which can be avoided, with Sass if we use Mixins, we would have the code below;

4. Extends

The extends feature works similarly to how the mixins work. It provides inheritance by letting you share a set of CSS properties from one selector to another. Unlike mixins, you don’t need to declare an extension explicitly. You can extend any rule of any selector with other selectors by simply including the @extend directive.

The example below first creates a style that all the buttons would share and then, we create a style that is particular to each button.

By using the @extend directive, it saves us the murky work of using several classes for a single element in our markup in order to style it. There are a few things to take note of when working with extends, one is that you cannot extend within a media query, this is because media queries are also directives. You can also chain extends i.e. after adding an extend directive to one selector, you then use this selector (which already has an extend) as an extend for another selector. This practice of chaining extends is often seen as a bad practice and it is advised to avoid this as much as possible.

5. Partials and Imports

Partials and Imports are my favourite feature of Sass. Partials are basically smaller Sass files and imports allow you to import contents of one file to another just as they work with CSS, Sass then allows you to use imports for partials. This means you can import other Sass files into a base Sass file. How I have come to use this over the years is to divide my markup's UI into components and then create a Sass file for each of this component, so I would have a separate file for my header, sections of the webpage, footer, popup pages and other important pages for the webpage. This method allows my code to be modular and easy to maintain especially if it’s a website with several pages because to edit the code base, I wouldn’t need to go through thousands of lines of code rather I could go to a particular file and make that particular change I want.

Partials are named starting with an underscore, then the name we want to give the file followed by the Sass extension and when importing them we use the import as a directive with the partial name in quotation marks with the underscore omitted.

In addition to all of these, Sass also allows for the use of functions and the use of operators for arithmetic and boolean operations. It provides functions natively and also lets you write your own functions.

Functions follow this syntax

@function function-name($arguments){
     @return value-to-be-returned;
}

The example below shows an example where we can set the widths of various columns using the function directive

With everything we have said in this article, you can clearly see that styling your webpage using the Sass Preprocessor puts you in a more advantageous position rather than working with plain vanilla CSS. Sass deals with all the challenges that styling with CSS presents when you are working on large projects; it lets you structure your codebase better using partials and imports, it reduces the use of lots of CSS classes saving you lines of code and it most importantly makes the codebase easy to maintain, very readable and increases your productivity.

Working with Sass might not come easy for one who is quite new to CSS so it is advised you must have practised with CSS considerably before delving into Sass. One of the best starting points for learning Sass (or any framework or language) is the official documentation page, the page provides documentation along with examples and if there’s any time you feel lost there are other tutorials on Youtube, blog posts and many more resources which are bound to be helpful.

Thank you very much for reading to the end. Till next time. 🤗

Comments (1)

@thebarefootdev's photo

You are aware regular css has many of these features including variables?

What is missing here is perhaps a brief explanation of the overhead in using any preprocessed css like SASS, LESS or similar. For these to work a preprocess step must be added to the build process, which would need something like Webpack or similar. Indeed a build process in general is needed to compile this pre css to regular css.

One cannot merely drop in pre css into a web project without a compiler.