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

4

I often hear about SASS and SCSS, but I do not know exactly how these tools work. I just know they are CSS generators (?).

I found a related question here but it does not address the question of why it uses them, just the syntax difference between one thing and another.

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

So I'd like to know:

  • What exactly do they do?

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

asked by anonymous 30.04.2018 / 17:53

3 answers

3

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

What do they do exactly?
LESS , SASS and SCSS are extensions of CSS , that is, in a very simple way, they add functionality to CSS . Taking the Web development context, we can think of how TypeScript is for Javascript , adds new features, without breaking the compatibility, that is, 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, contents repeated throughout 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 CSS. Or the name of the sources, and so on. When you need to find the colors, you have to resort to searching, and when you want to change for example, you have to go out changing the whole code. If you had a basic programming language functionality in CSS, which are 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 would not be easier to see and change if it were something like this:

$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 being processed, will be generated equal to the first one, not causing incompatibility with browsers.

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

Another good example is the Mixins feature, which allows you to reuse a portion of CSS as if it were a function. Here's an 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: link

In which cases would it be useful to use them instead of conventional CSS?
Well, I could tell everyone. Whenever you have an extension, as you master begins to use more, then begin to realize more options of where it can be useful. It is possible to write a 100% code in the preprocessor, and, as you master the features, you are implementing what makes the learning curve smooth.

Would not it hurt page performance instead of using normal CSS since it would be an overprocess or cost x benefit worth?
As 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 you charge ...) just in time to assemble the package to publish, I do not think it's great hindrance Some IDEs also allow you to compile the code while it is being saved, which makes the process even simpler and more transparent.

Here is a link to another very simple explanation of the features: tableless.com .br / sass-a-other-method-of-writing-css

    
30.04.2018 / 18:36
3

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

Easy maintenance

Imagine that I have a website with a certain color palette and I need to change the palette of it or create a new template to vary on a certain 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 wherever I want so that when the code is compiled for CSS, they are already defined. Ex:

_variables.scss

$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 just written

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

paddings.css

.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:

_paddings.scss

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

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

I also asked myself this question for some time and therefore the commitment to the explanation. Now that I understand SCSS / SASS I see that CSS should not be written because it takes a lot of time, it is possible for write failures and depending on the size of the solution it is impossible to maintain ... I hope it helps you.

    
30.04.2018 / 18:12
2

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

This practice is very interesting when it comes to creating web components.

See below for 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 the default 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 about the concept: link

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.

On the compatibility I do not see problems since the preprocessors compile the SCSS, LESS, SASS or Stylus etc s spit a .CSS at the end ...

    
30.04.2018 / 19:34