CSS Preprocessors Compared: Sass vs. LESS

By . Filed in Web Design

There are a number of CSS Preprocessor, LESS, Sass, Stylus, and Swith CSS, just to name a few. CSS Preprocessor, as we have said often before, is primarily intended to make authoring CSS more dynamic, organized and productive. But, the question is, which of them does the job best?

Well, of course, we wouldn’t be taking a look at every one of them, instead, we will only compare two of the more popular ones: Sass and LESS. To decide, we will compare the two in seven factors: the one that performs better gets one point; in the event of a tie, both will be awarded one point.

Let’s begin.

Installation

Let’s start with the very fundamental step, Installation. Both Sass and LESS are built upon different platform, Sass is running on Ruby while LESS is a JavaScript library (which it was actually also built on Ruby at first).

Sass: Sass needs Ruby in order to work, in Mac this has been pre-installed, but in Windows you probably need to get it installed before you can start playing with Sass. Furthermore, Sass needs to be installed through the Terminal or Command Prompt. There are several GUI applications you can use in place but they are not free.

LESS: LESS is built upon JavaScript, so intalling LESS is as easy as linking JavaScript library to your HTML document. There are also a few GUI applications to help in compiling LESS to CSS and most of them are free and performing very well (e.g. WinLess and LESS.app).

Conclusion: LESS is clearly in the lead.

Extensions

Both Sass and LESS have extensions for faster and easier web development.

Sass: In our last post, we had discussed about Compass, the current and popular Sass-based extension. Compass has a number of Mixins to write CSS3 syntax in less time.

But Compass is beyond just CSS3 Mixins, it has added other very useful features such as Helpers, Layout, Typography, Grid Layout and even Sprite Images. It also has config.rb file where we can control the CSS output and some other preferences. So, in short, Compass is an all-in-one package to do web development with Sass.

LESS: LESS also has several extensions, but unlike Compass that has all we need in one place, they are separated and each of them are built by different developers. This won’t be a problem for seasoned users but for those who are just starting out with LESS, they need to take some time to choose the right extensions that suit their workflow.

Here are a few LESS extensions that you might need to include in your project:

Conclusion: I think we have to agree Sass and Compass is a great duo and the Sprite image feature is really kickass, so one point for Sass here.

Languages

Every CSS Preprocessor has their own language and they are mostly common. For example, both Sass and LESS has Variables, but there is no significant difference in it, except Sass defines variables with a $ sign while LESS does it with an @ sign. They still do the same thing: store a constant value.

Below, we will examine some of the most commonly used languages both in Sass and LESS (based on my experience).

Nesting

Nesting rule is good practice to avoid writing selectors repeatedly and both Sass and LESS have the same fashion in nesting rules;

Sass/Scss and LESS

nav {
	margin: 50px auto 0;
	width: 788px;
	height: 45px;
	ul {
		padding: 0;
		margin: 0;
	}
}

But Sass/Scss takes this method a step further by allowing us to also nest individual properties, here is an example:

nav {
	margin: 50px auto 0;
	width: 788px;
	height: 45px;
	ul {
		padding: 0;
		margin: 0;
	}
border: {
    style: solid;
    left: {
      width: 4px;
      color: #333333;
    }
    right: {
      width: 2px;
      color: #000000;
    }
 }
}

This code will generate the following output.

nav {
  margin: 50px auto 0;
  width: 788px;
  height: 45px;
  border-style: solid;
  border-left-width: 4px;
  border-left-color: #333333;
  border-right-width: 2px;
  border-right-color: #000000;
}
nav ul {
  padding: 0;
  margin: 0;
}

Conclusion: Nesting individual properties is a nice addition and is considered best practice, especially if we follow the DRY (Don’t Repeat Yourself) principle. So, I think it is clear which one is doing better in this case.

Mixins and Selector Inheritance

Mixins in Sass and LESS are defined a bit differently. In Sass we use the@mixin directive while in LESS we define it with class selector. Here is an example:

Sass/Scss

@mixin border-radius ($values) {
	border-radius: $values;
}
nav {
	margin: 50px auto 0;
	width: 788px;
	height: 45px;
	@include border-radius(10px);
}

LESS

.border(@radius) {
	border-radius: @radius;
}
nav {
	margin: 50px auto 0;
	width: 788px;
	height: 45px;
	.border(10px);
}

Mixins, in Sass and LESS, is used to include properties from one ruleset to another ruleset. In Sass, this method is taken further with Selector Inheritance. The concept is identical, but instead of copying the whole properties, Sass will extend or group selectors that have the same properties and values using the @extend directive.

Take a look at this example below:

.circle {
	border: 1px solid #ccc;
	border-radius: 50px;
	overflow: hidden;
}
.avatar {
	@extend .circle;
}

This code will result as;

.circle, .avatar {
  border: 1px solid #ccc;
  border-radius: 50px;
  overflow: hidden;
}

Conclusion: Sass is one step ahead by distinct Mixins and Selectors Inheritance.

Operations

Both Sass and LESS can do basic math operations, but sometimes they return different results. See how they perform this random calculation:

Sass/Scss

$margin: 10px;
div {
	margin: $margin - 10%; /* Syntax error: Incompatible units: '%' and 'px' */
}

LESS

@margin: 10px;

div {
	margin: @margin - 10%; /* = 0px */
}

Conclusion: Sass, in this case, is doing it more accurately; as the % and px is not equivalent, it should return an error. Although, I actually hope that it can be something like 10px – 10% = 9px.

Error Notifications

Error notification is important to see what we are doing wrong. Imagine thousands of lines of code and a tiny bit of error somewhere in the chaos. A clear error notification will be the best way to figure out the problem quickly.

Sass: In this example, I’m just using Command Prompt to run the compiler. Sass will generate an error notification whenever there is invalidity in the code. In this case we will remove one semicolon on line 6, and this should turn to an error. Take a look at the screenshot below.

When I first saw this notification, I could hardly understand it. Also, it seems Sass is slightly off with where the error is. It said that the error is on line 7, instead of 6.

LESS: With the same error scenario, LESS notification is more well-presented and it also appears to be more accurate. Take a look at this screenshot:

Conclusion: LESS delivers better experience on this matter, and wins hands down.

Documentation

Documentation is very crucial part for every product; even seasoned developers would find it difficult to do things without Documentation.

Sass: If we take a look the documentation over at the official site, I, personally, feel like I am in the middle of a library, the documentation is very comprehensive. Yet, the look and feel, if that matters to you, is not motivational for reading, plus the background is plain white.

The presentation is much more like W3 documentation or WikiPedia. I don’t know if this is the standard of displaying documentation in the Internet, but it’s not the only way.

LESS: On the other hand, LESS documentation is clearer without too many text explanations, and it dives straight into the examples. It is also has good typography and a better color scheme. I think this was why LESS attracted my attention in the first place and I can learn it faster because of the layout and presentation of the documentation.

Conclusion: The LESS documentation presentation is better, although Sass has more comprehensive documentation, so I think we can call this one a tie.

Final Thought

I think it’s a clear conclusion that Sass is better with a total score of 5 versus 3 for LESS. However, it doesn’t mean that LESS is bad; they just need to be better. In the end, it is still up to the end-user’s decision to pick the preprocessor of their choice. Be it Sass or LESS, as long as they are comfortable and more productive, then that is the winner in their list.

Lastly, if you have something in mind about this subject, feel free to share it in the comment box below.

Author:

Thoriq has been dabbling in Web Design for 5 years and appreciates the giving nature of the web design community at large. He loves trying new things in CSS3 and HTML5. Apart from writing on hongkiat.com he also maintains creatiface.

Advertisement