"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 affectwhen 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;
}.box-1 {
color: #BADA55;
.set-bg-color(#BADA55);
}.loop (@index) when (@index > 0) {
.myclass {
z-index: @index;
}
// Call itself
.loopingClass(@index - 1);
}
// Stop loop
.loopingClass (0) {}
// Outputs stuff
.loopingClass (10);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)
);
}.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);
}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;
}@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;
}.module-a, .module-b {
/* A bunch of stuff */
}
.module-b {
/* Some unique styling */
}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;
}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 */
}
}.some-class {
/* Default styling */
@media (max-width: 800px) {
/* Responsive styles */
}
}=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.column
width: 25%
+respond-to(small-screen)
width: 100%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)
}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
- Chris Eppstein: SASS/LESS Comparison
- Jeremy Hixon: An Introduction To LESS, And Comparison To Sass
- Ken Collins: Too LESS? Should You Be Using Sass?
- Johnathan Croom: Sass vs. LESS vs. Stylus: Preprocessor Shootout
