Sass vs. Less vs. Stylus - Help me Decide

By Jordan Irabor

CSS pre-processors are a truly enabling tool for front-end developers who would love to enhance their page styling through variables, mixins, mathematical functions, operational functions, nested syntax, and style-sheet modularization. They make it easy to automate repetitive styling, reduce errors and write reusable code while ensuring backward compatibility with various CSS versions.

In recent times, the three most popular and widely adopted CSS pre-processors are LESS, SASS, and Stylus. All three are designed to do similar things but expressed in a different syntax and sometimes carried out in different ways. Let’s do some comparison.

Design Philosophy

LESS

LESS (which stands for Leaner Style Sheets) is a backward-compatible language extension for CSS. LESS follows a declarative styling pattern by nature. This implies that you specify what you want to see not how you want it to be done. This is mostly as a result of its similarities to functional programming which mostly makes it more readable and easier to understand.

However, this also introduces some difficulty when implementing complex algorithm patterns. As the name implies, LESS is designed to enhance CSS in the leanest way possible with minimal extra features. These features are designed to intuitively follow regular CSS conventions, principles, and paradigms.

The official LESS documentation quotes “because LESS looks just like CSS, learning it is a breeze.”

SASS

SASS, which stands for Syntactically Awesome Style Sheets, was created by Hampton Catlin. It is equally designed to be compatible with all versions of CSS. It follows an imperative styling pattern which implies that you get to specify how things get done.

SASS has a wider range of functionalities and features that enable developers to do amazing things and implement very complex algorithms with lesser difficulty. However, this comes at the expense of maintaining a CSS-like look all-round.

At some point, it tends to feel a lot more like a programming language than a styling language and this makes it more difficult for people (e.g designers) without a programming background to quickly get up to speed with.

STYLUS

Stylus offers a bit more expressiveness while maintaining a much more concise syntax. People with Python backgrounds will very much resonate with its non-curly braced syntax of indentation. However, this is a purely optional feature and one could still stick to the regular CSS syntax.

It shares striking similarities with LESS, but it has an imperative syntax like SASS. Stylus thrives over SASS and LESS in its support of seamless mixins as shown below:

border-radius()
  -webkit-border-radius: arguments
  -moz-border-radius: arguments
  border-radius: arguments

body
  font: 12px Helvetica, Arial, sans-serif

a.button {
  border-radius: 5px
  }

Syntax

All three pre-processors have their strengths and weaknesses.

LESS is pretty intuitive and more CSS-like.

SASS is more programmatic than it is CSS-like, although it supports all versions of CSS.

Stylus is more concise, intuitive and is just as programmatic as SASS. This is due to the fact that they are both imperatively styled.

All three pre-processors follow the Don’t-Repeat-Yourself (DRY) principle deeply and can perform conditional statements, functions, and operations.

Code Snippets

CSS

.conditional-example-1 {
  background-color: #000;
  color: #ddd;
}
.conditional-example-2 {
  background-color: #fff;
  color: #555;
}

LESS

.mixin (@a) when (lightness(@a) >= 50%) {
  background-color: black;
}
.mixin (@a) when (lightness(@a) < 50%) {
  background-color: white;
}
.mixin (@a) {
  color: @a;
}
.conditional-example-1 {
  .mixin(#ddd)
}
.conditional-example-2 {
  .mixin(#555)
}

SASS

=mixin($a)
  @if lightness($a) >= 50%
    background-color: black
  @else if lightness($a) < 50%
    background-color: white
    color: $a;
.conditional-example-1
  +mixin(#ddd)
.conditional-example-2
  +mixin(#555)

STYLUS

mixin(a)
  if lightness(a) >= 50%
    background-color black
  else if lightness(a) < 50%
    background-color white
    color a
.conditional-example-1
  mixin(#ddd)
.conditional-example-2
  mixin(#555)

Learning Curve

When considering the learning curve for all three pre-processors, it would be biased to factor in the difficulty of setup with tools like Ruby for SASS and Node for stylus and LESS. This is due to the existence of applications like Codekit and Live Reload which make it easy to set up watchers and compilers for your code without requiring so much technical expertise with Ruby, NPM and the command line.

A more reasonable perspective will be that the only learning curve is in the syntax which holds different levels of difficulty depending on your background. Those with little or no programming experience would most likely find it easier to adapt to LESS than SASS and Stylus.

Inheritance

In writing CSS, there are times when you might want to apply the same styling to multiple elements at once as indicated below:

h1,
h2,
h3{
  /*Some styling here */
}

This brings into focus the “Cascading” attribute in the Cascading Style Sheets (CSS). As much as this works perfectly, things get a little messy and much more difficult to keep track of as the need to add individual styling to these elements increases.

SASS and Stylus enable us to efficiently address such concerns elegantly via the @extend syntax which imposes inheritance as shown below.

.header {
  padding: 2px;
  font-weight: bold;
}

h1 {
  @extend .header; /* Extends .header styles */
  font-size: 42px;
}
h2 {
  @extend .header; /* Extends .header styles */
  font-size: 36px;
}

This in-turn compiles to CSS in this form:

.header, h1, h2{
  padding: 2px;
  font-weight: bold;
}
h1 {
  font-size: 42px;
}
h2 {
  font-size: 36px;
}

In contrast, LESS has no direct support for inheriting styles like SASS and Stylus. A workaround, however, is to use selectors as properties which tend to handle them as mixins without arguments. So styles are imported in place of their selectors. This unfortunately mostly results in repeated styles in the compiled stylesheet. Here’s what it looks like:

.header {
  padding: 2px;
  font-weight: bold;
}

h1 {
  .header; /* Extends .header styles */
  font-size: 42px;
}
h2 {
  .header; /* Extends .header styles */
  font-size: 36px;
}

This in-turn compiles to:

.header{
  padding: 2px;
  font-weight: bold;
}
h1 {
  padding: 2px;
  font-weight: bold;
  font-size: 42px;
}
h2 {
  padding: 2px;
  font-weight: bold;
  font-size: 36px;
}

Working with Media Queries

A good number of CSS developers are already quite familiar with adding @media at the bottom of their stylesheets to target and specify styling modifications for various screens. However, going this route could create a sort of disconnection between the original styling and the specified style for alternate screens especially with larger projects.

SASS and LESS enable us to take advantage of nesting, to keep all the styling for a particular section together irrespective of what kind of devices is targeted. An example is shown below:

.special-class {
  /* special class styles */

  @media (max-width: 800px) {
    /* Responsive styling for special class */
  }
}

Stylus also provides a similar way to do this. Observe the following syntax below:

.special-class
  /* special class styles */

  @media screen and (min-width: 600px)
    /* Responsive styling for special class */
<

Error Reporting

If you’re like me, you definitely can recall a time when you spent several hours trying to figure out what was wrong with your styling. Perhaps you got to find it after all and realized that the error had been staring at you silently the whole time.

With these pre-processors, you can get error reports as your authored files get compiled. They will tell you if there’s something wrong with your code, where and sometimes, why.

Website & Documentation

Stylus and LESS have a somewhat simpler and intuitive design on their website than SASS.

Although SASS keeps a pretty robust documentation, LESS and Stylus tend to do a better job in going straight to the point, helping developers keep up to speed quickly and locate resources faster.

Conclusion

All three CSS pre-processors considered in this article are mostly capable of the same things at their core and really just go about implementation and syntax differently. They have their areas of excellence and those of weakness. The choice of which to use is mostly situational and dependent on the requirements of the project in question.

SASS and Stylus are mostly programmatic in nature and permit advanced logic and algorithms. They allow us to write custom functions.

SASS has the largest adoption, an active community; popular front-end frameworks like Angular, Vue and React use it too.

Stylus has a highly concise and flexible syntax and easily integrates with Node projects.

Although LESS has the fewest features and logic-based functionality, it compiles very easily on the front-end hence it thrives on serverless architectures. It also has several built-in functions to complement its flaws.

Further Reading:

Here are some extra topics and links to guide you as you make your decision:

• Sass vs LESS vs Stylus: Preprocessor Shootout
• Popular CSS Preprocessors With Examples: Sass, Less & Stylus
• Less vs Sass vs Stylus