SASS and SCSS: Why use them instead of conventional CSS?

Asked

Viewed 10,018 times

13

I hear a lot about SASS and SCSS, but I don’t know exactly how these tools work. I just know they are CSS generators(?).

I found a related question here but it doesn’t address the question of why you use them, just the difference in syntax between one thing and the other.

As a developer front-end I have never used such tools, but I would like to get a sense of what they do if I develop a project and think they are better options than conventional CSS, in order to improve or make the CSS part more functional.

So I’d like to know:

  • What exactly do they do?

  • In which cases it would be useful to use them instead of conventional CSS?

  • Wouldn’t hurt the page’s performance instead of using normal CSS since it would be an extra process or the cost x benefit is worth it?

3 answers

12


I’ll share what I know and some sources on the subject.

What exactly do they do?
LESS, SASS and SCSS are extensions of CSS, I mean, in a very simple way, they add functionality to the CSS. Taking the context of Web development, we can think about how the TypeScript is for the Javascript, adds new features, without breaking compatibility, ie, at the end the code is compiled, or converted to a standard version. So do these CSS preprocessors.

A more functional example helps to understand. Scenario 1, repeated contents throughout the CSS. It is common for the company to provide the color palette and colors to be set to this standard. Then the same RGB appears several times in the CSS. Or the font name, and so on. When you need to find the colors, you have to go to the search, and when you want to change for example, you have to change the whole code. If you had a basic programming language functionality in CSS, which are the variables, this would be easily solved.

Example:

.estilo1 {
   background-color: #fafafa;  /* uma cor padrão */
   font: Helvetica, sans-serif
}
.estilo3 {
   color: #fafafa
}
.estilo4 {
   background-color: #fafafa; /* novamente, de uma maneira que foi inevitável não duplicar...*/
   font: Helvetica, sans-serif
}

Now it wouldn’t be easier to visualize and change if it were something like that:

$cor-padrao: #fafafa
$font-padrao: Helvetica, sans-serif;
.estilo1 {
   background-color: $cor-padrao;
   font: $font-padrao
}
.estilo3 {
   color: $cor-padrao
}
.estilo4 {
   background-color: $cor-padrao;
   font: $font-padrao;
}

This second code after processed, will be generated equal to the first, not causing incompatibility with the browsers.

This is a simple example, but you can get an idea of how easy it can be to do certain things, make the code clear, and also simpler to maintain, could change the default color only in the variable and all the CSS code would already be reflecting the change.

Another good example is the resource of Mixins, that allows you to reuse a part of CSS, as if it were a Function. See this example:

@mixin border-radius($radius) {
  -webkit-border-radius: $radius;
     -moz-border-radius: $radius;
      -ms-border-radius: $radius;
          border-radius: $radius;
}

.box { @include border-radius(10px); }

Source: https://sass-lang.com/guide

In which cases it would be useful to use them instead of conventional CSS?
Well, I could say everyone. Every time you have an extension, as you dominate you start to use more, then you start to notice more options where it can be useful. It is possible to write a code 100% in in preprocessor, and, as it dominates the features, it implements, which makes the learning curve smooth.

Wouldn’t hurt the page’s performance instead of using normal CSS since it would be an extra process or the cost x benefit is worth it?
Since the code can be compiled and delivered as a normal CSS, there is no incompatibility the cost would be to wait a few seconds (not enough, but if it comes...) only at the time of assembling the package to publish, I do not think it is too much trouble. Some Ides also allow you to compile the code while it is being saved, which makes the process even simpler and transparent.

Here is a link with another very simple explanation about the resources: tableless.com.br/Sass-an-other-way-of-writing-css

8

Well, we can say that SCSS and SASS do everything that CSS should and should not do. Here are some examples:

Easy maintenance

Imagine that I have a site with a certain color palette and need to change the palette of it or create a new template to vary on a given page. So we have:

  • In CSS I would have to access all style files and change colors. Ex:

foo css.

.bg-foo { background-color: #00FF00; } /* aqui seria alterado */
.fg-foo { color: #00FF00; }            /* aqui seria alterado */

navbar.css

.navbar { background-color: #00FF00; } /* aqui seria alterado */
  • In SASS or SCSS I can create variables and import them where I want and so, when the code is compiled to CSS, they are already defined. Ex:

_scss variables.

$color-x: #00FF00;                     /* aqui seria alterado */

_foo.scss

@import './variables.scss';
.bg-foo { background-color: $color-x; } 
.fg-foo { color: $color-x; }

_navbar.scss

@import './variables.scss';
.navbar { background-color: $color-x; } 

Code programmed and not only written

  • In CSS if I want to define a padding structure like in bootstrap I would do something like this:

css paddings.

.p-1 { padding: 4px; }
.p-2 { padding: 8px; }
.p-3 { padding: 12px; }
.p-4 { padding: 16px; }
.p-5 { padding: 20px; }
  • In SCSS I could use a loop like the for that every language has, thus staying:

_paddings.scss

@for $i from 1 through 5 {
    .p-#{$i} { padding: $i * 4px; }
}   

In particular, I prefer to use SCSS by maintaining a "visualization" closer to C#, C++, Java or other languages that have a certain structure. The design of SASS is based on PERL, Rails, Python, and does not have the keys, it uses line breaks and tab as separation and this in confuses but, regardless of which you use, you will still have the same functionalities and still, SCSS understands SASS and vice versa =D

I also asked myself that question some time ago, and that is why I have worked hard to explain it. Now that I understand SCSS/SASS I see that CSS should not be written because it takes too long, it is possible to write faults and depending on the size of the solution it is impossible to maintain... I hope it helps you.

6

There is yet another concept that has not been addressed by the other answer that is nesting selectors or in English nested selector

This practice is very interesting when creating web components.

Below is an example of nested CSS code.

.features {
  background-color: #cccccc;
  .box {
    border-radius: 3px;
    border: 1px solid #666666;
    background-color: white;
    p {
      font-size: 1rem;
      line-height: 1.2;
      color: #333333;
    }
  }
}

The above code would be the same as this in standard CSS:

.features {
  background-color: #ccc;
}
.features .box {
  border-radius: 3px;
  border: 1px solid #666;
  background-color: white;
}
.features .box p {
  font-size: 1rem;
  line-height: 1.2;
  color: #333;
}

Another practice is the nesting of pseudo-classes and pseudo-elementos as you can see in this example

   .element {
   /* meu css */
      &:hover,
      &:focus {
        /* meu css */
      }
      &::before {
        /* meu css */
      }
    }

Here’s a very interesting article on the concept: https://www.sitepoint.com/beware-selector-nesting-sass/


OBS: One of the main arguments for using these CSS building templates is productivity. There are several articles talking about how to write in LESS or SASS decreases the number of lines of code and consequently the working time.

About the compatibility I see no problems since the preprocessors compile the SCSS, LESS, SASS or Stylus etc s sew a . CSS at the end...

Browser other questions tagged

You are not signed in. Login or sign up in order to post.