Skip to main content

Development

Why We Switched to Sass

Developer Above Clock@1x.jpg

Editor’s Note: In 2020, Perficient acquired Brainjocks, a leading digital consultancy with a strong Sitecore platform focus. This blog post predates the acquisition.

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. 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! 🙂

Thoughts on “Why We Switched to Sass”

  1. 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!

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Emily Lord

Emily is an Account Executive and started at Brainjocks, now Perficient, in 2013. She formerly served Perficient in Project Management and Front-End Development roles. She has her Bachelors of Science in Computer Engineering and minored in Technical Communication and Mathematics.

More from this Author

Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram