public

  • Download Gist
sass_and_less_compared.markdown
Markdown

Sass/Less Comparison

In this document I am using Sass's SCSS syntax. You can choose to use the indented syntax in sass, if you prefer it, it has no functional differences from the SCSS syntax.

For Less, I'm using the JavaScript version because this is what they suggest on the website. The ruby version may be different.

Variables

Sass             | Less
-----------------+-----------------
$color: red;     | @color: red;
div {            | div {
  color: $color; |   color: @color;
}                | }

Both languages support scoped variable definition within a selector context. However they differ in their behavior:

Sass                     | Less
-------------------------+-----------------
$color: black;           | @color: black;
.scoped {                | .scoped {
  $bg: blue;             |   @bg: blue;
  $color: white;         |   @color: white;
  color: $color;         |   color: @color;
  background-color: $bg; |   background-color: @bg;
}                        | }
.unscoped {              | .unscoped {
  color: $color;         |   color: @color;
  // Would be an error   |   // Would be an error
  // background: $bg;    |   // background: @bg;
}                        | }

And their different output:

Sass Output                 | Less Output
----------------------------+----------------------------
.scoped {                   | .scoped {
  color: white;             |   color: white;
  background-color: blue;   |   background-color: blue;
}                           | }
.unscoped { color: white; } | .unscoped { color: black; }

Nested Selectors

Sass and Less have the & selector that allows nested selector to refer to the parent scope.

Sass               | Less
-------------------+-----------------
p {                | p {
  a {              |   a {
    color: red;    |     color: red;
    &:hover {      |     &:hover {
      color: blue; |       color: blue;
    }              |     }
  }                |   }
}                  | }

Mixins

Sass                              | Less
----------------------------------+----------------------------------
@mixin bordered {                 | .bordered {
  border-top: dotted 1px black;   |   border-top: dotted 1px black;
  border-bottom: solid 2px black; |   border-bottom: solid 2px black;
}                                 | }
                                  | 
#menu a {                         | #menu a {
  @include bordered;              |   .bordered;
}                                 | }

Mixins with Arguments / Dynamic Mixins

Sass                              | Less
----------------------------------+----------------------------------
@mixin bordered($width: 2px) {    | .bordered(@width: 2px) {
  border: $width solid black;     |   border: @width solid black;
}                                 | }
                                  | 
#menu a {                         | #menu a {
  @include bordered(4px);         |   .bordered(4px);
}                                 | }

Selector Inheritance

Less does not provide selector inheritance.

Sass                        | Less  | CSS Output
----------------------------+-------+---------------------------
.bordered {                 |  N/A  | .bordered, #menu a {
  border: 1px solid back;   |       |   border: 1px solid back; }
}                           |       |
                            |       |
#menu a {                   |       |
  @extend .bordered;        |       |
}                           |       |

Colors

Both less and sass provide color math. It was a bad idea in Sass, I'm not sure why less chose to copy it. There's no point in comparing them.

Sass provides a full array of tools for manipulating colors. All color representations (named colors, hex, rgb, rgba, hsl, hsla) are understood as colors and colors can be manipulated.

Sass exposes a long list of color functions not found in CSS:

Accessors:

  • red($color)
  • green($color)
  • blue($color)
  • hue($color)
  • saturation($color)
  • lightness($color)
  • alpha($color)

Mutators:

  • lighten($color, $amount)
  • darken($color, $amount)
  • saturate($color, $amount)
  • desaturate($color, $amount)
  • adjust-hue($color, $amount)
  • opacify($color, $amount)
  • transparentize($color, $amount)
  • mix($color1, $color2[, $amount])
  • grayscale($color)
  • compliment($color)

Note: Less.js provides a number of similar color functions.

Numbers

Both Sass and Less support numbers and basic arithmetic. However they differ significantly with respect to how they handle units.

Sass supports unit-based arithmetic, just like you learned in school. Complex units are supported in any intermediate form and will only raise an error if you try to print out the value of a complex unit.

Additionally, Sass has conversion tables so that any comparable units can be combined.

Sass will let you define your own units and will happily print out unknown units into your css. Less will not. Sass does this as a form of future proofing against changes in the w3c specification or in case a browser introduces a non-standard unit.

Sass:

1cm * 1em => 1 cm * em
2in * 3in => 6 in * in
(1cm / 1em) * 4em => 4cm
2in + 3cm + 2pc => 3.514in
3in / 2in => 1.5

Less:

1cm * 1em => Error
2in * 3in => 6in
(1cm / 1em) * 4em => Error
2in + 3cm + 2pc => Error
3in / 2in => 1.5in

Conditionals & Control Structures

Less does not provide any conditionals or looping structures. Instead, it provides mixin guards and pattern-matching which can be used to similar effect.

Sass and Less provides provide boolean types true and false, the and, or, and not operators as well as <, >, <=, >=, == operators. There are minor syntax differences between the two (Sass syntax shown here).

Some sass examples:

@if lightness($color) > 30% {
  background-color: black;
}
@else {
  background-color: white;
}

Looping:

@for $i from 1px to 10px {
  .border-#{i} {
    border: $i solid blue;
  }
}

A similar example in Less, using mixins:

.mixin (@color) when (lightness(@color) > 30%) {
  background-color: black;
}
.mixin (@color) when (lightness(@color) =< 30%) {
  background-color: white;
}

Less supports looping via recursion, but not (yet) selector interpolation as shown in the Sass example, so it is of limited use.

Server Side Imports

Both sass and less will import other sass and less files.

Output formatting

Less has three output formats: normal, compressed & yui-compressed. Sass has four: nested, compact, compressed, expanded.

Sass output compression currently beats the google pagespeed css plugin output by a few percent.

Comments

Less and Sass both support C-style (/* */) and C++ Style comments (//).

Namespaces

Less provides a feature that Sass does not:

#bundle () {
  .red { background-color: red }
  .green { background-color: green }
}

.foo {
  #bundle > .red;
}

Generates:

.foo {
  background-color: red;
}

The sass team considered this feature and decided that adding it would create fragility and unexpected interconnectedness.

Actualy it's Scss not Sass.

Now Less.js strips only // comments.

@Warry, SCSS is one of the syntaxes of Sass, so the above code can be said to be either SCSS or Sass.

Just as an update, lesscss.org has made the full switch to .js being it's implementation now ;)

/me resumes reading

Well it's about time! Sass 3.1 is coming out soon... I'll update this gist accordingly when it does.

Indeed it is :) I'm looking forward to the updated version. Now I have a ton more research to do (including Compass finally which I've managed to skip somehow so far). /me saw the --blueprint flag somewhere and now am very curious ;)

very nice and helpful comparison. Thanks @chriseppstein .

"&" for nested selectors has been available in Less.js for some time.

Nowadays Less has compression, which means it outputs each rule set on it's own line and strips all comments

If people have updates to make, please fork the gist and make changes. I'll merge them in.

Why is color math a bad idea ? I think it makes theme-ing quite a breeze

Thanks @chriseppstein! This is a great list - pretty much made up my mind to move to sass from less.

Thanks for this breakdown. I would now be comfortable using either. I don't understand how this is an argument for SASS over LESS, they seem very comprable. The main difference being accessors in LESS which make sense for CSS and conditionals in CSS, which is more of religious issue. Wondering by @MikeBarnlund is feeling compelled to switch.

I wasn't trying to convince anyone of anything, just provide facts.

My comments wasn't directed at @chriseppstein, just trying to understand what he found to be a major SASS advantage. Just noticed the basic math errors in LESS, although one could argue mixing number types like that is begging for cross-browser compatibility pain.

I think Sass wins over Less in terms of robustness, configurability, and feature richness. Less provides a simpler setup by using in-browser compilation.

@chriseppstein By 'robustness' do you mean the underlying code quality is better? Or that it's harder to break Sass as an end user? I know you probably have better things to do, but some concrete examples of how Sass is more robust would be interesting. Don't sweat it, though, I'm just curious.

One other area where I think Sass excels is in its community. Between the Sass and Compass groups and the IRC channels, there is plenty of help and support, and the community is friendly and responsive. I couldn't find any reference to any support at all on the LESS site (apart from the author). I'm sure there must be a group somewhere, but I couldn't find it.

"Both less and sass provide color math. It was a bad idea in Sass, I'm not sure why less chose to copy it."

Could you please explain why color math is a bad idea? (I'm genuinely curious.)

I'm curious to know why you consider color math to be a bad idea ?
I find these functions to be essential in designing directly within the browser, and I love them :)

A big up in favor of sass, is having the choice between the scss and sass syntaxes !

I'm a (very) lazy typer so I prefer to use the sass syntax. But sometimes, having the scss syntax is very practical and faster in integrating some existing css code and experimenting with it.

Less also has lessphp, which I'm more comfortable with than a javascript compiler - why get the client to do the compilation when the server can do it? Throw in caching and you're good to go. See http://leafo.net/lessphp/ EDIT: didn't realise less could be run with node.js. Still, the PHP compiler is another option if you're more comfortable with that.

@melat0nin - Neither Less nor Sass require client compilation. (Not that you said that - just that readers might get confused about that).

I use sass/compass primarily because I can commit the compilation configuration to SVN/GIT and share with the rest of my UI team, so they just have to run 'compass watch' and not worry about the details. Perhaps Less has something similar, but we were using the Mac Less App which didn't have a distributable configuration file that I know of.

@MikeBarnlund that does sound useful. I haven't explored SASS/Compass much myself (LESS was a seachange for me when I found it a few months ago.. I can't handle two revolutionary improvements to my workflow in one go...) but it is something I intend to look at.

Forked to update selector inheritance. Great work. Bye!

Interesting! It seems the two are very close in functionality; almost completely the same except for a few small differences. I haven't tried either yet. I'm going to pick Less first because I like the style of their site more. haha

My less dealbreaker vs sass is the latter's @extend. Specifically for clearfix and similar reusable code.
@import copies the clearfix into every block, repeating the code. @extend adds the affected rule definition to the clearfix definition block.
This way grouped styles can be defined once and reused in css without repeating lines of code and without adding presentational classes to the html.

That I can debug in a line number basis via the FireSass Firebug extension (with supported compilers) is the clincher. Otherwise (with the possible exception of the @extend difference mentioned) I'm relatively agnostic. A FireLess extension was available for a while, but hasn't been maintained and I've never seen it working. Currently I'm able to do real line number-based debugging with FireSass/Firebug using either LiveReload, OR the Sasson Drupal theme, with built-in compiling and FireSass support. That has been my holy grail for about 2 years since I first spotted Less/Sass!

Chris Coyier at css-tricks has done an excellent comparison here: http://css-tricks.com/sass-vs-less/

@MikeBarnlund that comparison is not worth reading, this gist mentions everything said there and more, unless you consider "Website Niceitude" an objective and pivotal factor. :P

Overall SASS is better, but LESS has more sugary (CSS equivalent) syntax. For anything serious I'd advise on using SASS (scss syntax). The whole @include and @mixin syntax might seem more verbose but it is actually more correct. LESS's syntax over steps itself to no end. LESS doesn't have a CSS compatible syntax, it has "css looking" syntax.

With regard to comments on Twitter using LESS. Is that actually true? The Twitter Bootstrap uses less, but I don't see that as evidence twitter.com does; if they do they certainly don't use the compile on the browser version. With regard to Twitter Bootstrap using it, given the "vanity" syntax in their javascript and comments on their issue tracker I would imagine their choice to be simply a stylistic preference, rather then a practical one. Don't get me wrong, they do a lot of good, but this one thing is just not a good example to follow IMHO.

@srcspider Chris Coyier is a pretty smart guy, and that’s a short and concise article. Having another professional’s take on SASS vs. LESS is well worth the 5 minute time investment.

And yeah, “Website Niceitude” may not be purely objective, but if that sort of thing had no bearing on one’s choice of product, we’d all be out of jobs, wouldn’t we? Documentation and website usability can be important for someone making their first foray into CSS preprocessors.

I may be missing something regarding your comment about LESS not having CSS-compatible syntax – could you clarify that? A pure CSS file can be renamed ?.less or ?.scss and compile perfectly fine: they’re both 100% compatible with CSS syntax as far as I know.

Twitter.com uses Bootstrap for several UI elements but it of course isn’t built exclusively on Bootstrap (http://www.quora.com/Twitter-Bootstrap/Does-Twitter-use-Twitter-Bootstrap).

Unless you plan on using Bootstrap, Sass is the way to go. Bootstrap is a great way to get a project off the ground. Primary reason for prefering Sass on my part though is "robustness" and it being more like a programming language. Especially in the sence that it has support for proper functions and control structures.

LESS and Sass are equally easy to install, but with Sass it's also really easy to extend on what others have built before you. With LESS you'd google a bit and then copy/paste the mixins you'd like to use.

With Sass: Need road-tested mixins with cross browser support and thorough documentation? gem install compass. Need really great responsive grids? gem install susy. Want to add some eyecandy and call-to-actions? gem install sassy-buttons.

Sass' robustness allows for projects like these to thrive. Stuff like what happens in Susy would just be hard work to accomplish with LESS. Gems like Susy and Sassy buttons also extends Compass, so we are not reinventing the wheel here either, like the case is with LESS. Look at almost any collection of LESS mixins (grid systems in particular), and you can bet they all have their own almost identical version of the clearfix mixin.

One thing that also struck me when I was working with LESS just recently: In Sass your CSS file will contain comments about where each part of your compiled CSS was defined. So if you have 100 Sass-files compiled into one CSS-file, it's still easy to figure out which file contained that CSS you want to adjust, because the included comments will tell you the file's position and the exact line number.

The compiler will also give you a lot better error messages that what is the case with LESS, so my WTFs pr minute went way up after I started using LESS. I was probably still making as just many stupid errors as before, just not getting proper error messages in return. :)

I personally used LESS on my projects more than SASS, but nobody seems to ever mention Stylus, which I'm loving more and more everyday.

Does Less have something similar to the newly introduced content blocks in Sass 3.2?

Less seems to support selector interpolation now.

This gist shows that the parent referencing operator & cannot be dangling in SCSS, while Less can.

https://gist.github.com/3995828

I really like LESS. Plus, SyncStar supports LESS:

http://the-sync-star.com/documentation/less-file-support/

It is so cool because when you save the LESS file, it will be automatically compiled, uploaded, and then browser is refreshed! This make it even easier to use LESS.

I would love some explanations or reasons as to why you think color math is a bad idea. I think it's great, makes theming and applying relative colors a breeze.

Agreed with @percyhanna

@percyhanna, @rakeshjuyal I think I have an explanation.

Both less and sass provide color math. It was a bad idea in Sass, I'm not sure why less chose to copy it. There's no point in comparing them.

I believe that when @chriseppstein wrote the above, he was referring to direct arithmetic with colors, e.g.:

$color: #300 + #030 + #003    // $color => #333

I don't believe that Chris meant that color manipulation in general is a "bad idea" but rather just that arithmetic with colors is less useful than utilizing the different color types and color theory, e.g.:

$color: hsl(40, 30, 20)
$new-color: lighten($color, 40)    // $new-color => hsl(40, 30, 60)

In fact, @chriseppstein wrote the initial implementation of these color manipulation functions.

@chriseppstein, this is a much better function reference to use for Less. Also, Less now provides selector inheritance via extend, which defaults to "exact match", but you can also specify extend all.

Thanks for putting this together!

I'm still quite curious why do you think color math is a bad idea. A lot of people have asked about it and no reply.

Fine compression. Clear the overall concepts.

I've been using Sass (SCSS) alongside Bootstrap but since it seems that LESS has somewhat caught up since I last looked at it I'll probably hop back to it. My workflow consists of the Roots WP starter, grunt.js, composer, Bootstrap and I guess LESS now.

I like SCSS a lot but it seems to be the odd man out in my workflow now...

According to lessjs.org, LESS 1.4.0 "[i]ncludes new features such as extends..."

However, I don't see an example on the site, and it was proving more than a simple Google search to find out more information than the one line on LESS' site.

ditto to @CWSpear's point, if you have

.bordered {
  border: 1px solid back;
}

#menu a {
    .bordered;
}

it will successfully compile to:

.bordered {
  border: 1px solid back;
}
#menu a {
  border: 1px solid back;
}

Treating the selector as if it were a mixin.

Your conditional example also doesn't account for LESS 1.4 where we can do this

@iterations: 10;

.loopingClass (@index) when (@index > 0) {

  .border-@{index}px {
    border: unit(@index, px) solid blue;
  }

  .loopingClass(@index - 1);
}

.loopingClass (0) { /*stop*/ }
.loopingClass (@iterations);

Far from as lean as the SASS example, but generates the same CSS and is whole possible. At least in the example you use.

@CWSpear for less > 1.4

 .bordered {                
  border: 1px solid back;  
}                         

#menu a {                 
 &:extend(.bordered);
}

compiles to:

 .bordered, #menu a {
  border: 1px solid back;
  }

LESS supports another use of the & operator that SASS does not:

.parent {
    background: #fff;
    &-child {
        color: #222;
    }
}

…produces:

.parent {
    background: #fff;
}
.parent-child {
    color: #222;
}

Try that in SASS or SCSS, and you'll get an error.

@arlodesign I believe you can now that Sass 3.3 has been released. I'm not sure if the gist is updated to cover last Sass version, if not I hope it will be soon!

One of the main 'features' of pre-processors that nobody ever seems interested in talking about is compile time. That is Sass's achilles heel in non-Ruby projects. It's horribly slow to spin up Ruby just to compile Sass.

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.