“Which CSS preprocessor language should I choose?” is a hot topic lately. I’ve been asked in person several times and an online debate has been popping up every few days it seems. It’s nice that the conversation has largely turned from whether or not preprocessing is a good idea to which one language is best. Let’s do this thing.
Really short answer: SASS
Slightly longer answer: SASS is better on a whole bunch of different fronts, but if you are already happy in LESS, that’s cool, at least you are doing yourself a favor by preprocessing.
Much longer answer: Read on.
The Much Longer Answer
The Learning Curve with Ruby and Command Line and Whatever
The only learning curve is the syntax. You should use an app like CodeKit to watch and compile your authored files. You need to know jack squat about Ruby or the Command Line or whatever else. Maybe you should, but you don’t have to, so it’s not a factor here.
Winner: Nobody
Helping with CSS3
With either language, you can write your own mixins to help with vendor prefixes. No winner there. But you know how you don’t go back and update the prefixes you use on all your projects? (You don’t.) You also won’t update your handcrafted mixins file. (Probably.) In SASS you can use Compass, and Compass will keep itself updated, and thus the prefix situation is handled for you. Yes you’ll have to keep your local preprocessor software updated and compile/push once in a while, but that’s trivial and thinking-free.
So what this comes down to is: SASS has Compass and LESS does not. But it goes deeper than that. The attempts at creating a real robust project like Compass for LESS haven’t succeeded because the LESS language isn’t robust enough to do it properly. More on that next.
Winner: SASS
Language Ability: Logic / Loops
LESS has an ability to do “guarded mixins.” These are mixins that only take affect when a certain condition is true. Perhaps you want to set a background color based on the current text color in a module. If the text color is “pretty light” you’ll probably want a dark background. If it’s “pretty dark” you’ll want a light background. So you have a single mixin broke into two parts with these guards that ensure that only one of them takes effect.
.set-bg-color (@text-color) when (lightness(@text-color) >= 50%) { background: black; } .set-bg-color (@text-color) when (lightness(@text-color) < 50%) { background: #ccc; }
So then when you use it, you’ll get the correct background:
.box-1 { color: #BADA55; .set-bg-color(#BADA55); }
That is overly simplified, but you likely get the idea. You can do some fancy stuff with it. LESS can also do self-referencing recursion where a mixin can call itself with an updated value creating a loop.
.loop (@index) when (@index > 0) { .myclass { z-index: @index; } // Call itself .loopingClass(@index - 1); } // Stop loop .loopingClass (0) {} // Outputs stuff .loopingClass (10);
But thats where the logic/looping abilities of LESS end. SASS has actual logical and looping operators in the language. if/then/else statements, for loops, while loops, and each loops. No tricks, just proper programming. While guarded mixins are a pretty cool, natural concept, language robustness goes to SASS. This language robustness is what makes Compass possible.
For example, Compass has a mixin called background. It’s so robust, that you can pass just about whatever you want to that thing that it will output what you need. Images, gradients, and any combination of them comma-separated, and you’ll get what you need (vendor prefixes and all).
This succinct and intelligible code:
.bam { @include background( image-url("foo.png"), linear-gradient(top left, #333, #0c0), radial-gradient(#c00, #fff 100px) ); }
Turns into this monster (which is unfortunately what we need for it to work with as good of browser support as we can get):
.bam { background: url('/foo.png'), -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #333333), color-stop(100%, #00cc00)), -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 100, color-stop(0%, #cc0000), color-stop(100%, #ffffff)); background: url('/foo.png'), -webkit-linear-gradient(top left, #333333, #00cc00), -webkit-radial-gradient(#cc0000, #ffffff 100px); background: url('/foo.png'), -moz-linear-gradient(top left, #333333, #00cc00), -moz-radial-gradient(#cc0000, #ffffff 100px); background: url('/foo.png'), -o-linear-gradient(top left, #333333, #00cc00), -o-radial-gradient(#cc0000, #ffffff 100px); background: url('/foo.png'), -ms-linear-gradient(top left, #333333, #00cc00), -ms-radial-gradient(#cc0000, #ffffff 100px); background: url('/foo.png'), linear-gradient(top left, #333333, #00cc00), radial-gradient(#cc0000, #ffffff 100px); }
Winner: SASS
Website Niceitude
LESS has a nicer, more usable website. The SASS documentation isn’t awful. It’s complete and you can find what you need. But when competing for attention from front end people, LESS has the edge. I don’t doubt this plays a large role in LESS currently winning the popularity race. Things may be changing though.
Winner: LESS
The @extend Concept
Say you declare a class which has a bit of styling. Then you want another class which you want to do just about the same thing, only a few additional things. In LESS you’d likely:
.module-b { .module-a(); /* Copies everything from .module-a down here */ border: 1px solid red; }
That’s an “include” essentially. A mixin, in both languages. You could use an include to do that SASS as well, but you’re better off using @extend. With @extend, the styles from .module-a aren’t just duplicated down in .mobule-b (what could be considered bloat), the selector for .module-a is altered to .module-a, .module-b in the compiled CSS (which is more efficient).
.module-a { /* A bunch of stuff */ } .module-b { /* Some unique styling */ @extend .module-a; }
Compiles into
.module-a, .module-b { /* A bunch of stuff */ } .module-b { /* Some unique styling */ }
See that? It rewrites selectors, which is way more efficient.
Winner: SASS
Variable Handling
LESS uses @, SASS uses $. The dollar sign has no inherit meaning in CSS, while the @ sign does. It’s for things like declaring @keyframes or blocks of @media queries. You could chalk this one up to personal preference and not a big deal, but I think the edge here is for SASS which doesn’t confuse standing concepts.
SASS has some weirdness with scope in variables though. If you overwrite a “global” variable “locally”, the global variable takes on the local value. This just feels kind of weird.
$color: black; .scoped { $color: white; color: $color; } .unscoped { // LESS = black (global) // SASS = white (overwritten by local) color: $color; }
I’ve heard it can be useful but it’s not intuitive, especially if you write JavaScript.
Winner: Tossup
Working with Media Queries
The way most of us started working with @media queries was adding blocks of them at the bottom of your main stylesheet. That works, but it leads to mental disconnect between the original styling and the responsive styles. Like:
.some-class { /* Default styling */ } /* Hundreds of lines of CSS */ @media (max-width: 800px) { .some-class { /* Responsive styles */ } }
With SASS or LESS, we can bring those styles together through nesting.
.some-class { /* Default styling */ @media (max-width: 800px) { /* Responsive styles */ } }
You can get even sexier with SASS. There is a really cool “respond-to” technique (see code by Chris Eppstein, Ben Schwarz, and Jeff Croft) for naming/using breakpoints.
=respond-to($name) @if $name == small-screen @media only screen and (min-width: 320px) @content @if $name == large-screen @media only screen and (min-width: 800px) @content
The you can use them succinctly and semantically:
.column width: 25% +respond-to(small-screen) width: 100%
Note: requires SASS 3.2, which is in alpha, which you can install with gem install sass --pre. I don’t think there is any doubt this is a very nice way to work.
Winner: SASS
Math
For the most part, the math is similar, but there are some weirdnesses with how units are handled. For instance, LESS will assume the first unit you use is what you want out, ignoring further units.
div { width: 100px + 2em; // == 102px (weird) }
In SASS, you get a clear error: Incompatible units: ‘em’ and ‘px’. I guess it’s debatable if it’s better to error or be wrong, but I’d personally rather have the error. Especially if you’re dealing with variables rather than straight units and it’s harder to track down.
SASS will also let you perform math on “unknown” units, making it a bit more futureproof should some new unit come along before they are able to update. LESS does not. There is some more weird differences like how SASS handles multiplying values that both have units, but it’s esoteric enough to not be worth mentioning.
Winner: Narrowly SASS
Active Development
At the time of this writing…
Number of open issues on LESS: 392
Number of open issues on SASS: 84
Pending pull requests on LESS: 86
Pending pull requests on SASS: 3
Number of commits in the last month in LESS: 11
Number of commits in the last month in SASS: 35
None of that stuff is any definitive proof that one project is more active than the other, but the numbers do seem to always leans toward SASS. As I understand it, both of the leads work on the languages in whatever little free time they have, as they both have other major new projects they are working on.
Winner: Probably SASS
More Reading
SASS vs. LESS is a post from CSS-Tricks
Source: CSS-Tricks
