Why BrainJocks Switched to Sass

BrainJocks has released SCORE v2.0, and our development team is loving it! This release brought many changes, but one of the biggest was to the front-end code. We have switched our CSS preprocessor from LESS to Sass, as many other developers have chosen to do. Even Bootstrap, which had been one of LESS’s biggest supporters, has switched their source code over to Sass. You may think: these preprocessor languages are so similar, so why switch? I’m going to break down some benefits of using Sass over LESS, and why our lives as front-end developers will be much easier with SCORE v2.0 and beyond.

 

Using @extend

Another change to SCORE with v2.0 was stripping out almost all component class names and putting the task of Bootstrap style inheritance into the CSS. The syntax for accomplishing inheritance is much simpler in Sass.

LESS:

.score-button-toolbar {
    &:extend(.btn-toolbar all); //inherit bootstrap
    a {
        &:extend(.btn-toolbar .btn all);
    }
    & > a {
        &:extend(.btn-toolbar > .btn all);
    }
}

SCSS:

.score-button-toolbar {
    @extend .btn-toolbar; //inherit bootstrap
}

The LESS version isn’t terrible, but it’s not good either. I don’t feel comfortable writing LESS extend statements from memory, and I had to do a lot of hunting through Bootstrap’s code to get the necessary selectors to target under the button toolbar. Sass’s version is simply @extend ______. That’s it!

 

Sass Maps

I wrote a blog article recently about Sass maps and iterators and how powerful they are. You can check it out here. LESS also has the ability to loop, but they are recursive and only iterate through numbers. Here is an example from the LESS documentation:

.loop(@counter) when (@counter > 0) {
  .loop((@counter - 1));    // next iteration
  width: (10px * @counter); // code for each iteration
}

div {
  .loop(5); // launch the loop
}

Sass iterators, on the other hand, can iterate through almost anything. Here is my example from my Sass maps article, which iterates through class names and fills an entire value for its background position (two numbers separated by a space). The class names and associated background position values can be conveniently stored in a Sass map with your variables.

@each $icon, $background-position in $social-icons {
   .#{$icon} {
        background-position: $background-position;
   }
}

Sass also supports logic statements in a much larger capacity than LESS does, and they support for and while loops. MUCH more powerful programming!

 

Better Documentation

LESS had the upper hand with documentation for a while, but I think Sass has now surpassed them in this category. I have spent plenty of time scouring LESS’s site trying to find something specific. Sass’s site has very clear CTAs:

sass_site

While LESS, on the other hand:

less_site

Huh??? I would have no idea which option to click on if I was searching (again) for the &:extend syntax because I couldn’t remember it. Their actual documentation is adequate, but finding anything is really difficult.

 

Syntax

Syntax complaints could be considered minor, but syntax is a big part of what makes a programming language great. CSS uses ‘@’ to signify directives, such as @keyframes and @media, and Sass does the same. Sass uses it to define and include mixins, import files, and signify loops. LESS uses the ‘@’ symbol to signify a variable, which is a little weird when used alongside directives like @media. Variables should be separate from directives, and Sass accomplishes that by using ‘$’ for variables. Additionally, mixins are clearly defined and included using directives in Sass, while all classes are potential mixins in LESS. Sass’s syntax provides clear separation between concepts, which makes it feel a lot cleaner and more organized.

 

I will end by saying that even using LESS is infinitely better than writing plain CSS. CSS preprocessors are amazing tools and we strongly encourage all SCORE customers to use them. However, if you’ve been writing LESS for a while, it may be time to switch to Sass. LESS is great for beginners to the preprocessor world, but Sass is a lot more powerful. Hopefully the reasons in this article have convinced you: this is the time for Sass! Happy coding! 🙂

Emily Lord

I am a UI developer with over 2 years of experience under my belt. I love learning about modern trends and new ways to make beautiful and responsive web pages. My mission is to put a smile on the faces of both the designers and the Sitecore developers while keeping my code clean and efficient. Learn more about Emily.

1 comment on Why BrainJocks Switched to Sass

BenMarch 4, 2016 - Reply

Great article on the subject, Emily. Sass (scss) is here to stay, at least for a while, and it’s important to know why we’re embracing it within SCORE 2.0 UI. One thing to note is that we still maintain the LESS files as an option for our customers, but we HIGHLY encourage users to move ahead with styling in scss. Have fun!

Add a Comment

Your email address will not be published. Required fields are marked *

Or request call back