Forums

The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums Other Benefit of Using LESS and SASS

  • This topic is empty.
Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #235628
    akirajt
    Participant

    I don’t understand about LESS and SASS because it is so confusing.

    What is the benefit to use LESS and SASS instead of using the regular CSS3 in my website?

    Thanks!

    #235629
    Paulie_D
    Member

    You are perhaps misunderstanding what SCSS or LESS actually are.

    They aren’t replacements for CSS, they are methods of writing CSS more efficiently and programmatically than standard CSS.

    The end product of these preprocessors IS CSS, they just make it easier and faster to write.

    #235630
    akirajt
    Participant

    Thank for your help!

    If possible, do you have concrete example by comparing the standard CSS with SCSS and LESS about how does it make it more efficiently and programmatically?

    Thank you!

    #235632
    Paulie_D
    Member

    Just read their respective documentation.

    At the lowest level just having variables is a huge start.

    I can define a color as a variable in one place and just keep referring to that color using variable name in all other places.

    If I need to make a change I just change the variable definition and it iterates all the way through.

    #236101
    mhodges44
    Participant

    Akirajt,

    As Paulie_D mentioned, the purpose of CSS Preprocessors are to write more efficiently and also promote code reuse. Here are a few concrete examples that you have asked for. Say you have nested elements or pseudo elements or hover states, etc. Here is an example from some of my production code using SCSS and I’ll also show its CSS counterpart. You will quickly see how much easier it is to read, write, and maintain using SCSS.
    SCSS Version:

    .nav-section-container {
        padding-bottom: 10px;
        li:hover {
          color: #F93E3E;
          transition: color .2s;
          > a {
            color: #F93E3E;
            transition: color .2s;
          }
        }
        &:not(.show-left-border){
          > li {
            padding-bottom: 10px;
            margin-left: 3px;
          }
        }
        &.show-left-border {
          > li {
            margin-left: 10px;
                &:nth-child(1) {
                    padding-bottom: 10px;
                    margin-left: 3px;
                }
          }
        }
      }
    

    And here is the same code in plain CSS:

    .nav-section-container {
      padding-bottom: 10px;
    }
    
    .nav-section-container li:hover {
      color: #F93E3E;
      transition: color .2s;
    }
    
    .nav-section-container li:hover > a {
      color: #F93E3E;
      transition: color .2s;
    }
    
    .nav-section-container:not(.show-left-border) > li {
      padding-bottom: 10px;
      margin-left: 3px;
    }
    
    .nav-section-container.show-left-border > li {
      margin-left: 10px;
    }
    
    .nav-section-container.show-left-border > li:nth-child(1) {
      padding-bottom: 10px;
      margin-left: 3px;
    }
    

    As you can see, there is a lot of unnecessary repetition with our CSS selectors. Nesting them allows for much easier code to read and write.

    Also, SCSS extends are extremely useful if you have the same code repeated numerous times throughout your CSS file, you can simply create a extend and reference it in your SCSS file and you don’t have to have repetitive code.

    SCSS mixins are highly powerful for handling cross-browser support and legacy browser support for things like font size, color gradients, vendor prefixing, etc. One really useful mixin I have is for font size. Here’s the code:

    @function calculateRem($size) {
      $remSize: $size / 16px;
      @return $remSize * 1rem;
    }
    
    @mixin font-size($size, $important: null) {
      @if ($important != null) {
        font-size: $size !important;
        font-size: calculateRem($size) !important;
      }
      @else {
        font-size: $size;
        font-size: calculateRem($size);
      }
    }
    

    This mixin allows you to say @include font-size(18.5px); in your SCSS file, but when the CSS gets generated, it calculates the rem font size and uses that if the browser supports it, but if not, it also generates the px fallback. Nothing earth shattering, but it’s an example of how powerful mixins can be.

    Have repetitive but similar css selectors for percentage of something like push or pull? That code can look like .pull-5 {…} .pull-10 {…} and so on.. cluttering your SCSS file. You can create a mixin to generate all of that code for you:

    @mixin pull-x {
        @for $i from 1 through 6 {
            .pull-#{$i*5}{ 
                position: relative;
                left: -($i * 5) + px;
            }
            .tablet-pull-#{$i*5} { 
                @include respond-to(medium){
                    position: relative;
                    left: -($i * 5) + px;
                }
            }
            .mobile-pull-#{$i * 5} { 
                @include respond-to(small){
                    position: relative;
                    left: -($i * 5) + px;
                }
            }
        }
    }
    

    This generates desktop, tablet, and mobile classes for pulling an element a given number of pixels. Your code in your SCSS file would look like this:

    @include pull-x
    boom, one line and all of those classes are generated for you when the SCSS is compiled.

    As Paulie_D mentioned as well, variables are highly useful for colors, font sizes, etc.

    Hopefully this gives you a glimpse into the power of a CSS preprocessor. I believe they can do nothing but help you, and you are not forced into anything you don’t want to do. With SCSS, you can write in the exact same CSS syntax you are used to and it complies perfectly fine – you can use SCSS specific code as frequently or rarely as you wish.

Viewing 5 posts - 1 through 5 (of 5 total)
  • The forum ‘Other’ is closed to new topics and replies.