Why should you start learning Sass?
Rather than another article telling you how to get started with Sass I thought I’d write a little introduction into the reasons why you should start writing Sass, well what I like about Sass anyway.
I started using Sass within a Laravel project. Laravel is a php framework, but has built in support for Sass using its Elixir service. Don’t worry if that makes no sense to you, the point I am trying to make is that the framework supports Sass and made it easy to use, encouraging me to start experimenting with using it and getting to know the benefits.
Previously, I was a bit unsure about creating build scripts and it all seemed a bit of a faff. I was unsure about spending time learning something else and making things more complicated than it needed to be, but I'm glad I did as the benefits are huge.
Sass is CSS
The first thing to know is that Sass is CSS. I may get a lot of comments on this point, but if you don’t want to use any of the features of Sass to begin with then you can write your Sass stylesheets in CSS and it will still work the same. Once you know this you can then start to take advantage of the features of Sass as and when you are ready.
Going back to my Laravel project, I started writing my CSS in the normal way, but ended up with a single long file. This is ok whilst you are working on it, but leave it for a few days and come back to it and its difficult to remember which rule is where. Sass allows you to create multiple files and then import them into the main file. This means you can split your long file into several, logically named and grouped files, making it easier to update CSS in future.
A typical project for me would start with a file for the grid, a file for colours, a file for basic layout and so on. You have the flexibility to import as many files as you need.
If you are used to programming then you are probably aware of variables. You can set a value once and store it in a variable so you can reuse it again. This is great for CSS as quite often you have a colour scheme in your design and rather than have to keep writing the same hex or rgb code you can write a variable.
The benefit to this is when your client decides they want to change that red to be a bit more pink, you only need to change it where you have set the variable and everywhere it is used will be updated.
Another benefit is that it is often easier to remember a variable rather than a hex code, leading to less consistency errors.
If you code a responsive design then I bet you use media queries somewhere in your CSS. I was never sure where to put the media queries in the CSS, so I ended up making a section at the bottom of the style sheet for things that changed for different screen widths. The problem with this is that the rules become separated from the initial rule, making it difficult to maintain.
Nesting allows you to write media queries for a class, within the class itself.
This means you can keep all the rules for a class together, making it much easier to read and maintain. You no longer need to keep scrolling up and down the file.
As well as using this for media queries you can also use the & to add rules for states, such as hover or active.
There are lots more cool things that Sass can offer, but I’ll only mention one more in this article. If you have two classes that have a lot in similar but a couple of differences, then rather than declaring all the styles twice, you can create a base class and then extend it with the second. This means it inherits the styles from the first, but additional styles can be added or specific items can be overwritten.
This is really useful for items such as buttons, where you have a standard button style, but may have a range of different colours. You can declare the standard button styles and then extend this class and define only the background colour, with the default button styles being inherited.
I think that’s enough reasons for one article, so hopefully it will help you see the benefits that Sass can offer you.