Sass vs Less anno 2015 – Luuk Hartsema

_{This is a repost from an article I wrote for Devhouse Spindle https://wearespindle.com/articles/sass-vs-less-anno-2015/}

Nowadays a CSS pre-processor is indispensable. When we decided to implement a pre-processor into HelloLily, I immediately proposed to use Sass because I was accustomed to work with Sass and had done my research in the past. One of my colleagues rightly asked whether I made this choice consciously.

I realised that my decision was based on the research I had done in the past, but the developers of Sass and Less have been busy in the meantime. Things change quickly, so despite the fact that I was really satisfied with Sass, I had to update my frame of reference. How does Less(.less) compare to Sass(.scss) anno 2015?

Many discussions

In my search for information about which pre-processor to use, I found many opinionated discussions. Another problem was the high amount of dated information. Arguments that used to be true weren’t true anymore. I asked other well known front-end designers about their current personal preferences. Even among them there is unclarity about how Sass compares to Less. Many of them gave arguments in favour of Sass, but most of the arguments given were no longer valid.

Just to give an example; some argued that Less didn’t have a nice way to do breakpoints. Breakpoints are a great way to create responsive websites. However, since version 1.7.0 Less offers breakpoints in a similar way as Sass does.

Breakpoint in Less

@ipad-size: 768px;

.breakpoint(@canvas) {
   @media only screen and
   (min-width: @canvas) {.props}
}

.luuk-hartsema {
   .breakpoint(@ipad-size); .props() {
      content: 'ipad!';
   }
}

Breakpoint in SCSS

$ipad-size: 768px;

.luuk-hartsema {
   @include breakpoint($ipad-size) {
      content: 'ipad!';
   }
}

Not so different

Based on the information I have today, I have to conclude that Less and Sass can both do great things and it is a matter of personal preference. Both pre-processors can do the same things, the only difference is that the one does it in a slightly different way than the other. I believe you can get used to both ways.

In version 3 of Sass the SCSS syntax was introduced as the new main syntax. This was a huge improvement. I personally prefer to use the SCSS syntax because it’s like conventional CSS with superpowers. This enables people without experience in Sass to understand things easier. Some prefer the cleaner Sass syntax because it doesn’t require you to write brackets or semicolons.

The future

For the future I foresee that most people will decide to use Sass. If only because the highly opinionated internet is in favour of Sass. Mark Otto, one of the developers of Twitter bootstrap recently tweeted that Bootstrap 4 will be written in SCSS. Another pre-processor to keep an eye on is PostCSS. They claim to be the future after Sass & Less.

At this stage I believe it is wise to go with the pre-processor most people use. It allows front-end developers that join our team to get up and running quickly. For this reason we decided to use Sass. Our CSS is being compiled by LibSass. LibSass is a C/C++ port of the Sass engine. It compiles the code incredibly fast.

I’d like to hear the insights of others. Feel free to share yours in the comment section below. If you like to continue reading. I recommend to read the following sources: Sass-Lang LibSass, LessCss, Css Preprocessor Benchmarks.