LESS vs Sass? It’s time to switch to Sass

by Brian Rinaldi on January 20, 2014

The modern web is always changing, and this article is more than two years old.


By Zing Design

The Sass versus LESS argument has been done to death. In this article I’ll explain why Sass really is the best and why you should start using Sass if you haven’t already. If you are interested, I’ve also written about how to get started using Sass and the problems with pre-processors.

Before I begin my highly opinionated tirade, let me just mention that I learned LESS first. LESS is great for beginners: it’s really easy and quick to set it up. It’s very similar to plain CSS, so writing it is intuitive. Compared to CSS, everything about LESS was very easy and friendly, I was quite enjoying LESS for a while…

…Until I discovered the truly awesome power of Sass and Compass. Looking back, I like to imagine LESS as the training wheels for beginners, or perhaps a gateway-drug into preprocessed CSS. Sass is the next level, a tool for the slightly more experienced front-end developer.

Why Sass is better than LESS

  • Sass lets you write reusable methods and use logic statements; ie. conditionals and loops. LESS can do these things but in an inefficient and counter-intuitive way (ie. guarded mixins for conditionals, self-referencing recursion for loops). Like LESS, Sass comes with lots of very handy functions built-in, including color manipulation, mathematics, and parameter lists.
  • Sass users can utilize the awesome power of the Compass library. There are libraries available to LESS users, but nothing really comes close to Compass, which is regularly maintained and contributed to by a huge community. Compass has some really awesome features like dynamic sprite-map generation, legacy browser hacks and cross-browser support for CSS3 features.
  • Compass also lets you add an external framework like BlueprintFoundation, orBootstrap on top. This means you can easily harness all the power of your favorite framework without having to deal with the mess of using multiple tools.

Problems with Less

LESS aims to be as much like CSS in style, syntax and structure. While this is a nice thought for easing users into writing it, there are a few issues which make it a lot less fun to work with than Sass:

Logic statements

In LESS you can write a basic logic statement using a ‘guarded mixin’:

.lightswitch(@colour) when (lightness(@colour) > 40%) {
  color: @colour;
  background-color: #000;
  .box-shadow(0 3px 4px #ddd);
.lightswitch(@colour) when (lightness(@colour) < 41%) {
  color: @colour;
  background-color: #fff;
  .box-shadow(0 1px 1px rgba(0,0,0,0.3));

The equivalent in Sass uses if statements:

@mixin lightswitch($colour) {
  color: $colour;
  @if(lightness($colour) > 40%) {
    background-color: #000;
    @include box-shadow(0 3px 4px #ddd);
  @if(lightness($colour) <= 40%) {
    background-color: #fff;
    @include box-shadow(0 1px 1px rgba(#000,0.3));


In LESS you can loop through numeric values using recursive functions:

.looper (@i) when (@i > 0) {
  .image-class-@{i} {
    background: url("../img/@{i}.png") no-repeat;

  .looper(@i - 1);


//--------------- Outputs: --------------------
//.image-class-3 {
//  background: url("../img/10.png") no-repeat;
//.image-class-2 {
//  background: url("../img/9.png") no-repeat;
//.image-class-1 {
//  background: url("../img/8.png") no-repeat;

In Sass you can iterate through any kind of data, which is much more helpful:

@each $beer in stout, pilsner, lager {
  .#{$beer}-background {
    background: url("../img/beers/#{$beer}.png") no-repeat;
// ------------------- Outputs: ---------------------
//.stout-background {
//  background: url("../img/beers/stout.png") no-repeat;
//.pilsner-background {
//  background: url("../img/beers/pilsner.png") no-repeat;
//.lager-background {
//  background: url("../img/beers/porter.png") no-repeat;

Custom functions

In Sass, you can write your own handy functions like so:

//Courtesy of Foundation... 
$em-base: 16px !default;
@function emCalc($pxWidth) {
  @return $pxWidth / $em-base * 1em;


@em-base: 16px;
.emCalc(@pxWidth) {
  //Ah. Crap...

Hmmm… Which would you rather use?

Problems getting started with Sass and Compass

It seems like the biggest problem that people have with moving to Sass are:

  • The added hassle of setting up the Ruby environment;
  • Crippling fear of the command line;
  • The inconvenience and time involved switching to a different tool;

To help with this, at Zing Design, we’ve written a tutorial for beginners eager to make the move to Sass and Compass which details every step to show just how easy and fast it is to get started, the awesome power of Compass, and how similar writing Sass is to other technologies.

If you’re already a Sass addict, take a look at our post about the problems with pre-processed CSS and the future of web presentation.

With the enormous popularity of Twitter’s Bootstrap, many designers and developers are moving toward this framework to fulfill their presentational needs. I’ve seen quite a few developers grumpy about the fact that it is built with LESS. As mentioned in another article, there are several forks of Bootstrap (like this one) which let developers customize their favorite framework in their favorite pre-processor language.

This article was originally published at http://www.zingdesign.com/less-vs-sass-its-time-to-switch-to-sass/

© 2017 Modern Web & our authors. All rights reserved.