Grow your CSS skills. Land your dream job.

Sass vs. LESS

Published by Chris Coyier

"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, LiveReload, or Mixture 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. The fact that Sass is in Ruby and LESS is in JavaScript is of little consequence to most potential users.

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. Bourbon is also good. There will be some back and forth on which of these project is "ahead."

In LESS, there are also some mixin libraries battling to be the best. They are looking a lot better these days than they have in the past. Despite their marketing-y support charts, I don't think they are quite as robust as the Sass versions. I've been led to understand in the past that the language of LESS itself doesn't make it possible to build as robust of libraries on top of it. We'll get to some of that next.

In both cases, the onus is on you to keep the preprocessor software itself up to date as well as these libraries. I also find that easier in Sass in general. For instance, Compass updates will just come automatically in CodeKit, or you use a Gem which is easy to update, while LESS mixins you'll have to manually update a file yourself.

Winner: Narrowly 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;

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(
    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.

I know that the Sass website is undergoing a major overhaul and lots of awesome people are working on it. It seems to me that it's going very slowly 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.

In LESS, every single class is also a mixin, programmatically muddies the waters, but is easier to understand at first.

As of LESS 1.4, it also supports extend. You can see some examples when we upgrade to it on CodePen. It's a bit funky in that it doesn't extend selectors nested in the original class unless you use an additional all keyword. Having the option to go either way seems like it's actually more powerful to me, but also wary of what's going on under the covers.

Sass also has the power to extend "placeholder" classes. Essentially invisible classes, in the format of %placeholder { }. This is useful for using internal naming that makes sense there but wouldn't as actual class names.

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.


  @if $name == small-screen
    @media only screen and (min-width: 320px)

  @if $name == large-screen
    @media only screen and (min-width: 800px)

The you can use them succinctly and semantically:

    width: 25%
      width: 100%

Nested media queries are a fantastic way to work. Rumor has it Sass 3.3 will have more features to make this even more useful, including a way to make extend work within media queries which is currently impossible in both LESS and Sass.

Winner: Sass


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

I'm going to update these numbers since it's been enough time since the original writing of this article.
05/16/12 01/12/13 06/25/13
Number of open issues on LESS 392 112 142
Number of open issues on Sass 84 83 110
Pending pull requests on LESS 86 10 5
Pending pull requests on Sass 3 7 11
Number of commits in the last month in LESS 11 84 2
Number of commits in the last month in Sass 35 14 14

None of that stuff is any definitive proof that one project is more active than the other, but it is interesting to look at stats. 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.

LESS has been pretty actively lately, but now Sass has gotten much more active too, due to a core member getting to focus on it directly.

Winner: Tossup

More Reading


  1. Great comparison for someone like me who isn’t using either yet. Good to know which to dive into should I eventually go the preprocessor route.

  2. Awesome work Chris. I have started with LESS and SASS feels more powerful to me.

    Any thoughts on Stylus?

    • I have used Stylus just a very little bit. I’ve purposely left it off the article for brevity and the fact that I don’t think it does anything better than its bigger brothers at the moment. Correct me if I’m wrong.

    • I’ve yet to be convinced by Stylus.

      My relatively recent experience with Stylus was that it’s compiler is a bit flakey. Sometimes it would silently fail, other times it would output mangled CSS (e.g. declarations as selectors) rather than error.

      Personally, I’m not a fan of transparent mixins because I prefer to know which parts of the file are native CSS and which parts are being handled by the pre-processor’s additional functionality.

    • Yep, the compiler is a bit fickle right now, but hey! Stylus is not that popular as Sass and Less now, so there are not that much developers and bug-reporters there. I hope that it’s development would bring the compiler to the more stable state.

      Speaking of mixins: while you can use transparent ones, you can call them as functions too, so it’s an optional thing.

  3. I like how you point out the advantages of the @extend in SASS, although I prefer the succinctness of LESS in that case. I also really like the way SASS is starting to handle media queries and I hope that LESS will soon incorporate something similar.

    • Also, one of the reasons I’ve kept away from SASS is that I have no idea what compass is and why it’s connected to SASS

    • Once you’ve used Compass you won’t believe how powerful it is and why you weren’t using it sooner! I strongly suggest you give it a try…

    • Rizky Syazuli

      Compass is basically a collection of CSS3 mixins and helpers. you should check out their website if you’d like to know more. trust me, the fact that SASS has Compass is a win by itself.

    • For those who do not want to search through the article again for the link:

  4. Amy Hendrix

    I have to admit, I picked SASS at first because I wanted Compass (which is a very good reason!), and I haven’t really looked at LESS since because I already had SASS set up. It’s great to see a good, well-reasoned comparison.

  5. Also debugging in SASS in much easier than the way it is in LESS

  6. Nice writeup. I’m still trying to decide which route to go.

    One the one hand, if I want to learn anything from you about css pre-processing, I should learn SASS.

    On the other hand, I really want to use 320 and up in a new project, but haven’t found a good SASS port, yet. Anybody here know of one?

    Codekit is awesome, by the way. Thanks for that tip.

    Good luck on your next adventure!


  7. i think each have another important win.
    sprites – sass (via compass)
    terseness – less (don’t need to define include, extend, etc)

    • I agree. Less’s syntax is slightly more intuitive when it comes to that.

      But there’s no reason you shouldn’t learn both. I personally use sass/compass. But there are a lot of projects out there that use LESS exclusively, like Twitter Bootstrap.

      So personally I think the best option is to learn both. There are many other pre-processors out there, as mentioned Stylus is one. I have always taken the stance to atleast TRY all the tools at my displosal. Not only is it invaluable in helping to further my understanding of different syntaxes, but it makes working on others projects easier when I already know the syntax because I took the initiative to learn it. This applies to all my development tools, not just css pre-processors.

  8. I’ve been using SASS (+Compass) for while (2 months) – it’s GREAT!

  9. Scott Rod

    It does seem like LESS is winning the popularity contest… That’s not necessarily good or bad. For selfish reasons, I did wish Compass/SASS were treated on par with LESS rather than perceived as second place. LESS is a great contender if you haven’t used SASS before. But, in attempt of using LESS, it has made me appreciate Compass more. I wouldn’t start a project without configuring Compass first.

    I think articulate tutorials demonstrating how to use a product – especially when it comes to the Terminal – will help surpass the first hurdle.

    One of my most valued and helpful video tuts recorded back in the day peaked my interest in pursuing Compass for the long haul opposed to other preprocessors.

    The other great videos I’ve seen were Chris Eppstein’s and David Kaneda’s demos for Sencha Touch. (Sidetracking – I wish jQTouch received more devotion. The GUI is skinned using Compass/SASS and looks super sexy. IMO)

    To install Compass, copying/pasting 2 lines of code from here into the spooky Terminal anyone can handle – especially a front-end developer. And if you use Coda, the Terminal is right there!

    For the still-terrified-at-the-terminal people, GUIs are available on the market for Compass and Sass. One of them…

    Give it a whirl!

  10. John

    I’m not doing web development at the moment (I have in the recent past), but I kind of wonder why not have your preprocessed CSS be “CSS, plus a short shell script to expand for browser support”.

    That is, the single biggest space-saver I see in all these examples is linear-gradient being expanded to [-o-linear-gradient, -webkit-linear-gradient, -moz-linear-gradient, etc]. But plain “linear-gradient” is perfectly valid CSS3, and it’s very easy to write a script which expands that into the variants that work on each individual legacy browser.

    With a modern browser, you can write and test without even running the preprocessor. And it’s easy to remove these backwards-compatibility hooks from your script later as browsers are no longer used.

    Sure, it wouldn’t solve all of these problems, but I think it’d be a nice way to get 95% of the way there, for 10% of the complexity of the solution. Maybe it’s just me, but I’d rather spend my time learning a technology that’s going to be around for the long haul (CSS) than tools which happen to be useful today (LESS, SASS) as, mostly, temporary workarounds.

    • I think maybe check out some more benefits to why you should be using LESS or SASS over vanilla CSS. For me, the number one benefit is that it’s just way faster to write. I’ve been using LESS for a couple years (might be switching to SASS after this article though) and once you realize how much time you’re saving, I think you’ll understand why it’s good.

      SASS and LESS have been around for a few years, they’re not really workarounds, but rather tools to help with productivity. The end result is the same, compiled CSS (or handwritten), so why not take the shortcut?

      After I started using LESS (actually I was using CSScaffold in PHP before that) I realized how powerful it was and I actually think it makes more sense to write it that way than straight up CSS. Mixins (or includes), nesting and variables are very powerful but simple concepts that I think CSS should handle natively (which might become reality down the road). You can reduce a ton of code redundancy with those alone.

    • Scott

      John, try Prefix-free:

      The vendor prefix thing is the only compelling reason I’ve ever seen for using pre-processors, and Prefix-free solves that.

    • Sean

      The example I’ve used recently was define a group of coloured spheres using only CSS. You can do that with a combination of corner radius and an off centre radial gradients.

      To define the different colours you can use a pre-processor to write the gradients for you using a list of base colours which you darken by a preset amount.

      I’ve never used LESS to judge it but I love SASS.

  11. Great entry Chris, as always!

    I’ve just started to delve into the world of CSS Preprocessing so for me a great insight into it; after reading this, you’ve conviced me to go with SASS.

  12. SASS vs. LESS? Stylus.

  13. Benjamin Knight

    This has been something on everyone’s mind, thanks for the write-up Chris. It will be interesting to see what gets discussed at the preprocessor talk that’s being given at Yelp at the end of this month.

    Personally I’ve just sort of ended up using LESS because my first exposure to preprocessors was when using Twitter’s Bootstrap.

    On the topic of handling CSS3 prefixes, why not just use -prefix-free.js and stop worrying about it?

    • Pat

      For quick demos -prefix-free.js (or the LESS js file) is fine. But you should NEVER depend on javascript to output your prefixes in a production environment. Not only will it not work if JS is off but it also adds un-needed processing to the frontend.

      use CodeKit, LiveReload or simply “compass watch”…

    • Benjamin Knight

      Thanks for you advice, Pat.

  14. I’ve looked into and used both and prefer LESS for it’s succinctness and ease of use: it’s basically CSS made cooler.
    But now that I’ve heard COMPASS is really good, I’d like to try out SASS more. But I don’t understand what it is really.

    Could you make a post in what COMPASS is and how best to use it?

  15. I’ve recently been starting a redesign on my website, and although I’m pretty poor at web designing, I’ve grown to like Stylus the most.

    No semicolons & braces are a win in my book.

    • Sounds like, from the comments above, that Stylus has some pretty compelling stuff in it. However if the only thing you like is the lack of semicolons and braces you can always use the .sass syntax

    • I haven’t personally used Stylus, so this is not me trying to dissuade you from using that, in fact I think I’ll give it a shot after this.

      However, if conciseness is one of your biggest concerns, the orignal Sass syntax also leaves out semicolons and braces. It has other concise benefits like using “+” instead of “@include”. I certainly prefer the original syntax, but I feel like one of the last few.

    • Benjamin Knight

      Personally using a syntax that’s an extension of CSS’s own syntax feels a lot more comfortable to me. That means not all LESS or SASS is valid CSS, but all CSS is valid SASS/LESS. Seems like there are better ways to optimize your workflow than just not having to type brackets and semicolons.

  16. With regards to the ‘Helping with CSS3′ section, it might be worth mentioning all the mixins made available by the very active Bootstrap project.

    Just in case anyone isn’t aware, Bootstrap is built entirely using LESS.

    So you could argue that LESS is perhaps easier for people to get into (you alluded to this in the documentation part), especially with its ties to Bootstrap – which again helps people just getting into web design.

  17. For us LESS is the clear winner. It’s lightweight and very easy to customize. We use the same LESS mixins on every project so it really speeds up development. CSS without LESS feel like the dark ages.

    • Permalink to comment#

      You should really try out sass then – you would really see some great benefits it really improves the way you work and the syntax just makes “more sense” than less – less seems to have fallen behind on all the different parameters tough this comment is 2 years old i think its worth changing to sass! or i would pref. scss – cause sass gives a lot syntax errors if you’r not really strict when you write

  18. Comments are very interresting, most people go to SaSS because of Compass.

    In our CMS we went to LESS
    – because of Twitter Bootstrap
    – because JavaScript can be used every where (like jsFiddle, iPad, DropBox,… for debugging/coding purpose) ruby is not well known in big company

    • Dan Bohea

      There’s a couple of Sass ports of Twitter Bootstrap now.

  19. Chris, I must say I totally agree on your conclusions. I am using both for a while now and SASS feels more solid and mature.

  20. Hi Guys

    Can someone please link me to a detailed article about why CSS Pre-prepossessing is a good thing to do. Doesn’t it slow down the page ?

    • You can compile your Sass, Scss or Less into a stylesheet and use it as normal. You don’t have to compile on page load.

      If you are using Sass, you can use the Watch to automatically compile and compress your Sass into a standard css file which you include as normal :)

    • Typically it’s something you do before deploying, so it’s not being crunched through on every live page load.

    • Rizky Syazuli

      the slow down might happen if you’re using LESS.js (the js version), which compiles LESS on page load. but SASS files is converted to CSS during development. and LESS can be configured to do that as well.

  21. Great article, but I’m surprised you didn’t touch on any of the compiling applications as there are some good ones for both.

    Also the different Sass syntaxes. As I understand is there are two, Scss and Sass. Although I guess you can’t really compare them, but I do think that from a beginners point of view the confusion between the two syntaxes in Sass can be confusing. I actually prefer Sass to Scss as you have no braces! Hurrah.

  22. Nice article. I agree with everything, though I’ve not tried any of those new SASS media features yet – this is the first I’ve heard of them!

    One thing that always puts me off LESS is that while it’s very easy for a developer to simply throw the JS version up and get going right away, I worry that the web will fill up with pages dependent on script to interpret their styles, because it’s way to easy for a learning developer to just leave it at that.

    For whatever reason, people will fail to distinguish between development and production, and with SASS if you forget to recompile it for production all you get is a bloated file full of your comments and whitespace, but with LESS you get something that might not work on everyone’s browser.

  23. If you’re of similar mindset to myself LESS could be a better bet. I write in a plain a CSS style with the addition of variables, basic maths and mixins for prefixes only as if the specs on the modules I emulate were final. I avoid use of nested rules or syntactically unfamiliar stuff. In this situation neither has an advantage (Stylus doesn’t in my experience handle this style too well, at least as of writing) other than the tools to process it. When considering the tools available I think LESS has an advantage as there are several cross platform apps, which importantly means decent availability on Windows.

  24. Any good Windows SASS preprocessor like CodeKit?

  25. SASS is great because of Compass, LESS is great because of Twitter Bootstrap.

  26. I can’t really say SASS had this very big gap with LESS. SASS is amazing because of some other stuffs like Compass extends it. So, Basically LESS can only outwit SASS when it comes to easy to use category. Other than that SASS is better.

  27. John

    I used LESS for a while now, but would like to compare it with SASS (and see what that Compass hype is about). The only thing stopping me is Ruby. Sure I need to know squat about it as you say, but I still need to install it!! And on Windows this is neither easy nor wanted. Why would I need to install a whole language with bells and whistles just to use a small pre-compiler? Give me a standalone program already! The fact that this not exists makes me wonder about SASS’s popularity outside the declining Ruby community.

    • Installing Ruby is much easier than you think. on windows you just need to download and install ruby installer from the whole process of installing ruby, Sass and compass takes around 10 minutes and it doesn’t need to know ruby language. by the way ruby is not that frightening ;)

  28. It’s worth noting that LESS doesn’t require Ruby, which seems like it could be a significant factor for some. I personally prefer being able to set up a LESS project using lessphp in 5 minutes, without having to faff around with gems etc (which, to be fair, I’ve yet to properly learn. But time is money and all that).

  29. One major consideration missing from this comparison is the ease with which either tool can be integrated with continuous integration and automated build processes. Until Sass is ported to C, LESS is the clear winner here, since, out of the box, it works with plain old JavaScript, Node.js, and Java (via Rhino), and had been ported to PHP and a few other languages as well. Sass’s current dependency on Ruby is a serious Achilles heel for many developers.

    • Rory

      I agree the dependency on ruby is offputting. I use by Handlino ( to handle the ruby stuff via GUI but it would be nice to be able to work on SASS on my staging server (doesn’t support SASS via ruby as its an old PowerPC mac). There was an old PHP port in the works but as far as I know it hasn’t been kept up to date.

    • Rizky Syazuli

      i haven’t dive into CI or such systems yet. but aren’t CSS files from LESS/SASS should already be compiled during development, way before it enters any automated testing/build/deploy process?

      do you guys have to wait for a long build process just to change a font color? seems like a hassle to me :|

  30. Now I’m thinking why I use (and love) LESS over SASS.
    Here’s what’s comin over my head:

    Setting up less takes about 15 seconds. Just rename your .css files into .less files. Lovely for old sites.
    It works easly in php or whatever you want.
    Let’s say that as you start using it you just can’t stop.
    Also, a program like Codekit can optimize your life a lot. Really a lot.

    Nothing to learn with less. To create a function just need to declare a class. That’s pretty cool though.
    There’s plenty of mixins already available out there (one for all: less elements)

    Have I already said that you need no knowledge to start using LESS? well, in case you need, the less documentation is already the best you can have.

  31. Excellent article, thanks for sharing.

  32. Artis

    Is there any way to use SASS syntax with php pre-processor?

  33. Francesco

    I always thought that it was hard to install SASS in a Windows environment… I’m not sure where I got that idea. It took me less than fine minutes to download Ruby, install it and get SASS working.

    It does look awesome, maybe it’s time to start using it, at last.

    Thank you for the great article!

  34. Why no mention of mention Bootstrap? Is Compass that much better?

  35. Excellent post! I would also love to see one of your screencasts on Compass.

  36. Tjorriemorrie

    Hi Chris

    You’ve definitely missed a major point. That’s the entry to either one. For SASS you need ruby and all kinds of installations, but with LESS it’s a javascript file include which everyone is accustomed to from using plugins. I haven’t used either, but I’m going to begin with LESS (especially since I develop everyday on osx and win). I’m sure it’s a major consideration for many others.

    • Just for the record, I’ve never installed Ruby or used the command line to work with preprocessing. Yes, SASS depends on Ruby, but that’s totally transparent to me as I use an app to deal with it.

      And another quick point, *please* don’t use LESS via actually including on your page via <script>. Maybe that’s OK for super quick testing, but that would be a major performance hit. Compile locally, include regular CSS on your page.

    • Whoa now, buddy, you can’t just tell everyone they should compile “locally”, e.g., on their development machine with CodeKit. That’s not always an option. On larger projects with larger teams, there’s a very good chance that the pre-CSS source files will be versioned and part of an automated build process in a CI (continuous integration) workflow. It may be difficult, impossible, or just simply undesirable to inject Ruby into the build process as a dependency. LESS has more options right now for integrating into a wider variety of environments. It really does make Sass a non-starter in certain situations, at least until there are some viable ports to C, Java, etc.

    • Compile locally, use a build process thingy, use a post-commit hook, invent some new fancy thing. Whatever. I’m saying don’t include less.js in the head of your deployed website and link up style.less files and call it a day. That needs to load that huge dependency, pull down all that code, process it and re-inject files. There will be flashes of unstyled stuff, it’s unnecessarily slow. That’s the overall point.

    • Actually performance using embedded less JS isn’t as bad as people like to claim. We’ve used it with sub-second page load times.

    • How is compiling a CSS file locally and uploading it to a server different from writing a CSS file yourself and uploading it to a server?

    • Colaberation is the difference with regards to workflow. LESS certainly wins there, as evidenced by how easy it was to include its workflow right into the WordPress admin…

    • Pat

      Local development, demos and quick prototypes yes…but live sites? no bueno…..

      Relying on JS to load your CSS styles is bad no matter what way you look at it……I’m surprised at how many people see this as a valid way to deploy CSS….

      I’m not on about people who compile locally and upload their CSS to the production server but rather those that rely on less.js to process their css on live….

    • Personally I find that fact that I can work live on the server, editing LESS files via FTP, then have them automagically minified, gzipped and cached using lessphp a lot more compelling than having to have an offline application that does the compilation for me, adding another step in the process. The lessphp way means my workflow hasn’t changed since the days of vanilla CSS, with the exception of course of actually using the features that LESS provides.

  37. I’ve started a new project with the intent of using a preprocessor. I started out thinking that LESS might be the way to go, but the zeitgeist seems to be leaning more towards SASS with articles like this and the ALA article. As Chris mentioned, if you compile locally, I’m not sure how Ruby is a factor in the decision.

    It’s a little out of the scope of this article, but now that we have the ability to work with logic and variables in CSS, do people have any suggestions about debugging? With vanilla CSS, you can use the web inspector and see the exact line of code that is causing the issue (more or less). Now, we’re just looking at the post-processed CSS file, which might be result of logic, variables, mixins, etc. Any suggestions on how to work backwards?

  38. Alice

    Has anyone tried Scout ( )? The idea of having to use the command line doesn’t excite me… Are there other apps, like that that you guys use?

  39. Great post Chris! I’m a SASS fan hands down. I installed the new alpha version and run a few tests with nesting media queries to a specific element. The only thing I don’t like is that way it still outputs a query for each individual element. It’ll be great if they could group all queries together on compression.

  40. I’ve become a fan of Bourbon over Compass lately:

    Fantastic docs, great add-ons, readable source, and nothing but extensions. Compass tries to do and be too much in my opinion, Bourbon only wants to help extend my SCSS/SASS. And it’s written in SCSS, which is where the SASS folks were heading.

  41. Ah, I’ve been looking for something like this for ages, but I’ve never know what to actually search for! Thanks for the awesome explanation and examples (as always).

    A quick question, did you intentionally use #BADA55 for “bad ass” or was that just an incredibly awesome coincidence.

  42. Chris, I’m using LESS in a huge project and one of your statements left me worried: “(…) don’t use LESS via actually including on your page via <script>. Maybe that’s OK for super quick testing, but that would be a major performance hit. Compile locally, include regular CSS on your page.” Actually I’m also using a fallback css file in the <noscript> tag so if there is no javascript my layout is kept alive. Is there anything wrong with this approach? Thank you in advance.

    • ian.pvd

      Get CodeKit ($20) or the (FREE)

      Set up your site as a watched folder, and whenever you save your .less file, the app will recompile it into a .css file locally in the background. Then you can reference your compiled (& minified) css file in the head without having to worry about a JS or PHP parser when the page is served.

    • @ian.pvd I’m a Windows user. It’s a shame I know (or not :) But thanks anyway!

    • Edson,
      I’m a Windows developer also and have been happy with WinLess. One drawback is that for its compression when compiling .css, it doesn’t strip newlines chars between style rules, while does.

    • Scout App is a free GUI for Compass/Sass that runs on both Windows and Mac.

    • For serverside compilation, if you’re running PHP, try lessphp –, or you could use node.js to compile.

    • Ian MacIntosh thanks for the WinLess tip! I’m testing it rigth now. So far so good…

  43. ian.pvd

    After reading about the two (and discovering Code Kit) a few months ago, I made the decision to jump into developing with LESS from now on. My decision was based on (in ascending order of importance), how good the LESS site looked and how much simpler the LESS syntax looks. My primary reason for choosing LESS was because LESS was valid CSS, and I could just change the extension on my “styles.css” files to “.less” and go. Anything previously done as longhand in CSS could be folded back into a mixin at my convenience, and I had the liberty to use nesting and variables going forward.

    I know that SCSS is valid CSS also, but it seems like all the purported benefits come from using SASS+Compass, with it’s weird indentation syntax and all those @imports for patterns. While relying on indention to declare attributes makes me nervous, the biggest issue is that I definitely don’t want to have to go through all my existing CSS and convert it into SASS, especially when all it takes to continue existing projects with LESS is a compiler like CodeKit and changing the file extension.

    If the point is to simplify what I’m writing, while I focus on a site’s appearance (and not prefixes), LESS is powerful enough and requires zero learning curve and zero effort to transition. Compass doesn’t look simple, and SASS looks like I need to change what I’m already doing to use it. Am I missing something? From here, it does’t look like the benefit of SASS outweighs the investment.

    I will admit though, that the $ vs @ variable declaration thing is weird.

    • Anahkiasen

      Uh, you can use Compass with any SASS syntax.
      Also this article really needs to mention Susy as one of the best plugins for media queries work.

    • ian.pvd

      Why do comparisons always refer to LESS vs SASS? If SCSS and SASS are the same thing and equally powerful, but the different names denote one syntax which is valid CSS and another which is not, wouldn’t SCSS hold a significant advantage over SASS when it comes to working it into existing projects?

  44. 34m0

    Stylus for me too.
    I wonder does the fact that Twitter Boostrap is in Less mean anything ? Could it lead to precompiler domination ?

  45. Although there are a variety of reasons I enjoy using LESS, the part that really bugs me in this article is this:

    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.

    Turns out CodeKit is Mac only, so it isn’t much good for those of us on Windows or Linux. LESS has a variety of easy to use compilers such as SimpLESS, Crunch, or even lessphp (see a blog post on how I automatically compile my LESS when developing for WordPress). I haven’t looked for a while, but when I first started using a preprocessor there just wasn’t anything this simple available for SASS. Has that changed? Can anyone point me to some good tools that won’t require me to install ruby on Windows and Linux?

  46. Also, if the Sass documentation scares you, you might like Better Sass Docs, a responsive way to browse through the Sass Reference:

  47. Just curious if you’ve looked at the CSS4 Spec…

    If it passes then the `$` will become a parent selector. IMO, at that point, LESS will be winning on the variable front since it could get really messy declaring variables and what could be common selectors with very similar syntax. Mentally, I much prefer sharing `@` among concepts.

    But the spec could always change and I’ll have a moot point…

  48. William Malo

    For me, the most important thing a preprocessor does is make you write less text.
    And for that, nothing beats stylus.
    Look how beautiful it is:

    bw = 20px

      border solid bw #foo
      border-radius bw-4

  49. geoff yuen

    So I’m not the only one that thinks LESS is more popular because it has a beautiful home page?

    • You’re right, the current website can drive people off Sass.

      Although, note that a complete redesign of the Sass website is on the go. You may know the designer behind the future website, it’s Jina Bolton. She’s very talented and I’m sure it will ensure that people won’t choose other preprocessors over an homepage issue.

  50. The “Active Develop” section of this article tells an important story.

    From github:

    “People have fixed plenty of issues, sometimes years ago. Go check out one of the 74 outstanding pull requests with no response. As an example, this very issue has many dupes going back 2 years (like #324 #71). Here’s a pull request that would have fixed this issue pretty simply. The commiter asked for feedback, was met with silence, and then eventually gave up.”

    I and a few others, had tried to get cloudhead to open up the GIT repo so we could help triage issues (close duplicate bugs, merge pull requests that fix simpler issues, etc) but we didn’t get very far.

  51. I think the best known LESS-based project out there is probably Bootstrap. Reading the Bootstrap code makes it evident that Compass/Sass is a better choice. Especially evident when comparing icons.less, which is CSS for the icons sprite in Bootstrap, to how you do sprites in Compass.Two lines of code in Compass accomplishes what you need 120+ lines (?) in Bootstrap to do with LESS.

    And as you can see in Bootstrap they also define a lot of mixins which are already defined in Compass, so Bootstrap is really reinventing the wheel there. Sure, mixin are lovely, but with Compass most of those you need are already pre-written.

    Compass is like a preset library of CSS patterns.

    And people’s fear of Ruby is funny. OSX comes with Ruby included. No installation necessary. (what’s Windows? :)

    And did I mention that Sass will compile LESS too? So you can easily include Bootstrap in your Sass projects ;)

    • A small comparison…

      Bootstrap (LESS) sprite, ~150 lines:

      In comparison, in Compass, the same sprites file would be made up by two lines:

      @import "my-icons/*.png";
      @include all-my-icons-sprites;

      And Compass will actually create your sprite automatically too, from the collection of images you provide in the “my-icons” folder. It will also improve the files size-wise, if there is room for that.

      You can also reference the size of your sprites when using them in your CSS code, so for instance if I want my English button to have the exact same size as my English icon, I can do for instance this:


      <a href="/english">English</a>


      .english_icon {
          @include sprite-replace-text-with-dimensions($icons-sprite-map, english); 

      (please note, this is Compass code, not some mixin I wrote myself)

      Which will produce something like this:

      .english_icon {
          display: block;
          text-indent: 110%;
          white-space: nowrap;
          overflow: hidden;
          background-position: 0 -286px;
          height: 20px;
          width: 30px;
          background-image: url('../images/icons-se31a1588e7.png');
          background-repeat: no-repeat;

      Not the automatic calculation of the background-position, automatic text replacement and the usage of the Compass-generated sprite-file.

      Sizes can also be referenced manually:


      width: image-width(sprite-file($icons-sprite-map, english));

      Extreme time-saver.

    • There are tons of LESS repos which include preset mixins for all kinds of things, like CSS transforms etc. They don’t do the automatic spriting that Compass does, which might be a deal-breaker, but it’s not as though there aren’t plenty of resources out there to augment a vanilla LESS project.

    • True, but with Compass you get a complete one-line install of a thoroughly road-tested collection of sweetness, with a great online documentation. All in one place.

      I just recently started using the sprites part. It’s one of those things you don’t understand how you managed without :)

    • Laurence: Thats exacly the point too: There are tons of LESS resources out there, like Bootstrap, but most of them reinvent the wheel in some way, like when defining something as basic as a clearfix mixin.

      Look at the Bootstrap mixins file for instance. Many of those mixins they wrote are your average bread&butter, and many are already in Compass. Prime example of reinventing wheels and repeating yourself.

      Having a pre-made mixin collection like Compass doesn’t add to your project weight either. A mixin is only added when you actually use it.

  52. Peter

    I chose Sass/Compass a few weeks ago – it’s awesome and really there is no turning back. Now the next question is:

    What is the best component ui package to use?
    We can scour the web for nice mixins or things like “fancy-buttons” and/or create our own – but why?

    I chose Bootstrap mostly for all of it’s components, but it becomes laborious to edit it’s partials when I need to – and then I worry if my edits are creating issues with other dependent components when I may need them in the future.

    • Peter

      And new grid designs like Suzy by the brothers will confirm Sass-Compass-Suzy’s place from now on…

    • While Suzy is nice and dandy, it uses fixed-width columns, and thus is not more of an “adaptive” grid rather than “responsive” in my opinion. But nice, nonetheless!

    • Susy IS a fluid grid system. You don’t have to set a max-width in pixels, you can just override it and set max-width: 100%

    • You are right: Column widths can be set in percent too. I stand corrected.

  53. If you’re looking to jump into using any of these pre-processors, including Stylus, a web app called Least ( might help get you started.

    Paste your raw CSS in the left panel, choose your output language (pre-processor) and type of indenting required, and click ‘Convert’. Simple as that.

    Least’s developer, @tokiwoki, calls it a five-hour project. All I can say is: Genius!

  54. I’m not sure what the “fear” of the terminal is with you guys, but literally there are only a few commands. No need to buy a $20 app to compile your CSS…

    sudo gem install sass --pre
    sudo gem install compass

    Go to your folder.

    compass init

    Creates everything you need for compass.

    compass watch

    Compiles your CSS in the background.

    And you’re done. Not sure what you guys are using an external app for. Granted, CodeKit does do other things than compile your SASS

    • Honestly, I didn’t find terminal that scary when I was working with Linux, but using the Windows Command Prompt is not something I enjoy. I can also setup LESS so that I don’t have to use any extra app or the terminal at all.

    • CodeKit reloads your browser automatically, with Adobe Shadow you can also get multiple other devices to reload accordingly. It also minifies and combines JS and Coffescript, and runs it through JSHint and JSLint, which often proves to be a timesaver with it’s warnings :)

  55. My issue with SASS is set up. My work computer is still running 10.5 – so when I went to set it up, I couldn’t update gems because ruby was out of date. When I went to update ruby, I needed RVM. When I went to install RVM via homebrew, it said bash was out of date. LESS was installed and running in a couple of minutes.

    • I was going to go with SASS after the article and comments, but my work computer also runs 10.5, and this sounds like a killer. I may end up waiting until I upgrade the OS or computer.

    • Thought I’d give this a go anyway, just to see how hard it would be getting everything updated. Have now wasted an hour of my life and am still nowhere near getting SASS installed. A shame, but that’s it from me.

      I’ll give LESS a go instead.

    • Apologies for talking to myself here. Just ignore me.

      I’m trying the Scout app, and so far it seems to be working. Much easier than going through all the hassle of updating everything on an out-of-date version of OS X.

  56. Jannis Gundermann

    Excellent comparison.

    One addition thing that I found cumbersome when working with LESS from time to time is the class like include statement.

    Where SASS has the:

    .my-selector {
    	@include arrow( top, 10px, black );

    LESS uses the slightly flawed:

    .my-selector {
    	.arrow( top, 10px, black );

    The problem with LESS is when your mixin is called something like “arrow” and the selector is also called .arrow in which case LESS simply has a compilation error and won’t compile anything.

    So this won’t work in LESS:

    .arrow {
    	.arrow( top, 10px, black );

    To me that alone shows one of the major flaws with their class like include statements. One that SASS doesn’t have because their @include always stands as its own without any use of class like .classname(); naming schemes.

    Notable also would be the SASS functions that offers much more control over your output and opportunities to work with your CSS variables that LESS simply doesn’t have (yet).

    To each their own I suppose, but in a comparison I think SASS deservedly wins the “Better than X” badge.

  57. Pat

    We moved to SASS a few months ago due to some of the reasons outlined in the article. However only in the last week or so have I really seen the power of Compass.

    Just some of the things I’ve found indispensable are:
    – CSS3 mixins,
    – IE filter fallbacks (< IE9) and SVG gradient fallbacks (IE9)
    – inline-images as base64 strings
    – cachebusting css images
    – A compass plugin called rgbapng which when you pass in an rgba value will automatically generate a 1x1px opaque image and inline it in your CSS for browsers that don’t understand RGBA.
    – passing hex values rather than RGB to get RGBA values
    – Ceaser mixins
    – Spriting has been a godsend!!!!

  58. Thanks Chris! Learned a ton from this article. Been meaning to get into the dif between SASS & LESS. Goes w/o saying, was just handed to me. Thanks!

  59. I think JavaScript compilable is a big win for LESS that’s missing from the list. It’s what makes possible live previewing of LESS editing in Scripts n Styles WP plugin (plug). This, incidentally, allows for improved error messaging. I can write LESS, see the results in real time, then publish the compiled CSS right from the blog’s admin. Obviously, I’m biased for LESS :-) Cheers!

  60. chris

    Ilove it when people that know what the stuff they are talking about compare two things. Your article is very good but … honestly i think that in the end such articles are useless if you summarize it by saying this is better because it won in 10 areas whereas the other only won 5. Ok 10 is more then 5, but what if the 5 points are much more important for a code or designer then the 10 ones. Second thing i don’t like when people only compare features is that they often forget the community.

    For example i love the Dojo Toolkit to do things in javascript. I think Dojo is superior in many ways compared to MooTools or JQuery. But in the end, what’s really important, is how much people use that Framework. Dojo is used by a very small minority of coders but jquery is used by most websites. This is so important because at work we often need something quick because a customer asked for it and wants it for yesterday. If i need a news slider, a cool widget that does this or that or something else … of course i can code it with dojo and put a a big number on the bill. The result is that the customer is happy because he got what he wanted but on the other hand he is not happy because you asked him to pay a lot.

    If i need to do the exact same script for jquery, first i do a google search an most of the time i find some code that does almost what i wanted, i do some changes and can put it only. The customer is very happy because his request was served very fast and also because i was really cheap.

    This is because the jQuery community is huge. The Dojo community is small. You can do everything in a very professional way in dojo, but with jQuery and now jQuery Mobile you most of the time don’t need to do anything yourself. So even if i prefer Dojo a lot, at we work we use jQuery for all our projects.

    • Paul

      I exactly think the same. SASS may be the better tool for the job, nobody uses it.

      Try to find good SASS tutorials and you will see what i mean. More and more opensource projects on Github use LESS to manage their CSS files, i have not seen any project using SASS so far. A lot of frameworks like the Twitter Bootstrap use LESS, so why bother trying to find the best solution, because in the end what really matters is how big the community is and how muc projects support it.

  61. Great post! LESS is good but the JS that’s needed turns me away from it. But I do have to say that CodeKit is one awesome piece of software!

    • There’s no JS required.

      As stated: You CAN include the JS-file to create CSS on the fly, but as everyone (should) know you shouldn’t rely on JS for styling.

      Use one of the applications posted (Codekit is my favorite!) to compile the LESS file to CSS and off you go.

      I use LESS, it has plenty of stuff that I don’t already use. From the feature set provided SASS/Stylus is more powerful, but still – it’s even mooore stuff I won’t use.

      Sprite handling looks nice at first glance, but I have yet to find an automated process that make it better then handrolling it. In some automated situations it’s probably great though, but there’s no use case for me.

      With LESS it’s super simple to get started. That’s the most important thing, start using one of them. I might graduate to SASS later, but for now LESS is plenty…

    • Joacim: If you use sprites, then Compass is your thing. It will create the sprite, make each image in the sprite easy to reference, and it’s also very easy to get the dimensions of the images you load into your sprite.

      If you’re not using it you’re missing out :)

    • Torkil: As I said – “Sprite handling looks nice at first glance, but I have yet to find an automated process that make it better then handrolling it. ”

      Compass just lists all images vertically, that’s not the optimal solution:

      I build my own sprites quickly using Sprite Cow:

      Not as fast as Compass, but mine are more efficient.

    • Pat

      @Joacim You can configure compass to create your sprites efficiently if you want. I use the “smart” setting which bunches all the sprites up together. By default there is no gap between the sprites but you can configure that be larger if you want. See here

    • @Joachim: Wrong. You can use four different types of layouts for your sprites, not just vertically:

      … and how can you possibly say that something that’s “not as fast” can be “more efficient”? :)

  62. Thanks Ken for “the point”. In my opinion the winner is Less because is implemented in JavaScript.

    Talking about community:

  63. 2 things:

    1/ unless Compass knows the stats of the site I’m developing for it has no way of knowing what prefixes to include. It can make an educated guess, but it won’t beat hand-authored styling. So that’s a poor win for SASS there.

    2/ I’m not sure that grouping selectors is such a good idea, because it can introduce selector weight issues by regrouping selectors. Making your css depend on source order (if selectors match and have the same weight the last one in the css wins) is of course a bad idea from the start, but you’d be surprised how common it is. Having a preprocessor regroup style could and will lead to unintended errors. So again, a poor win for SASS.

    If only people would speed up getting this stuff in the css spec itself, so the processing could be done by the browser. But nice write-up, never had much interest in SASS because of the whole Ruby deal and I’m pretty happy writing LESS so far, but it’s good to at least know what I might be missing out on.

    • Anahkiasen

      You can configure whiwh prefixes Compass uses with the configuration variables.

    • But it’s site-dependent. Sometimes there are enough visitors to warrant FF3.6 support (still needs -moz for rounded borders), sometimes there aren’t any and you can just eliminate it. What the different between removing one prop from your mixin and configuring Compass?

  64. Phil

    Has any one used csscrush yet?

    How does it compare?

    • Auto prefixing is really cool. Wonder why other preprocessors don’t do that and stick on the mixin solution. At least it could be an option.

  65. I’m all for preprocessors, I think they are a super efficient way to handle CSS. But here is my question. Suppose I write a SASS file, generate the CSS file, and then another colleague of mine modifies the CSS file (because they don’t use SASS). Now what? I’m stuck using the CSS file as is, rather than preprocess. I think preprocessing will only work if everyone in the assembly line will use the preprocess file. Any thoughts?

    • Peter

      Everyone on the team has to be ALL IN…. every time you edit the .sass it will over-write (locally) your colleague’s work… :(

      What I’ve done with this new project is ask the php dev to keep his styles in the style tags at the top of page – and I add his (usually minor work) to the sass file in the morning (they are in india and I the US so it works out okay in this situation.)

    • Interesting solution! I might try to adopt it. Because I usually work with a graphic designer, who designs the website, sends me the .psd files, and I develop it. The issue becomes when she tries to make minor changes to the .css files, like changing a font size by a pixel or something to that nature, and I worry that using .sass will actually end up slowing me down because of the going back-and-forth and trying to see what changes she made.

      But if I ask her to put the changes at the end of the .css file, then I can easily make the modifications I think.

      I think it would be super convenient if we could put the .sass file on the server, and have it compile server-side, so that both people could edit the .sass file. Because let’s face it, perhaps making a .sass file from scratch is difficult, but editing one would probably be relatively easy, and a task anyone could accomplish.

    • One trick is to use the “compressed” setting for compiling SASS, that way if a co-worker opens it there is an immediate visual reminder that they shouldn’t be editing this file =)

    • The first thing I let SASS generate in the CSS code is a comment saying “Do not edit this generated CSS file! Edit SCSS source files only!”

    • Coworking with SCSS/LESS is really easy: Just don’t commit CSS files to your repository. They’re now generated, and the source is the SCSS file. Build jobs (in combination with Jenkins) should take care of compiling CSS files for deployment, but the source repository is kept nice and clean :-)

    • I see. Chris, I think I’ll take your advice with the “compressed” CSS output. However, I do think it would be awesome if someone created an online SASS compiler, so that you could store the .sass file online, edit it, compile it online, and see the change instantly. As opposed to download the .sass file, edit it, compile it, and upload the newly-created .css file….

    • Pat

      Amit, there is this here if that’s what you mean?

      But this doesn’t just relate to SASS/LESS development, it’s never a good idea to edit your “live” files on the fly….You should really have a dev copy on your local machine or server, then once you’ve made your changes and tested them, push them up to live….

      Where I work we’ve starting using SASS and we decided it was all or nothing. It wouldn’t work if some people where editing the SCSS and others the generated CSS..Just to remind people the CSS directory has a big txt file named “DON’T EDIT CSS!!! USES SASS.txt”…

    • @Pat: yeah, I guess that’s what I meant!

      I agree with you that first working on a local dev copy is far superior than making modifications on the fly. And that’s how I always work. However, my client frequently likes to change minor details, like font-sizes, and perhaps a pixel of padding here and there. Therefore, I resort to a process where I have to keep re-downloading all of the CSS files in order to prevent undoing her changes by overwriting the files.

      Anyway, I may resort to that compiler, assuming it can render large .sass files as well! Thanks!

    • @Torkil: looks interesting! But what’s this about them being open-sourced and the site going down?

    • @Amit: What do you mean? That’s awesome news :)

  66. Danil Semelenov

    It’s worth to say that LESS and SASS utilize different paradigms. SASS is about usual imperative paradigm (ifs, loos, complex logic, etc.), while LESS tries to be more declarative and functional (guards, minimum logic flow, no ifs, no loops, etc.)

    SASS/Compass are powerful and have almost all you need for styling. LESS is intentionally limited, sometimes too much (no named/keyword arguments, e.g.) Positive thing about LESS: you can use it without any dependecies/compilers, just drop one tag (I found it useful for quit prototyping).

    I use both of them, sometimes struggling with their issues. Also tried Stylus in one project, but found it a little bit unpredictable and fragile. And not sure that throwing away colons, semicolons, keywords is a good idea in Stylus (it’s funny, Stylus developer rants about CoffeeScripts a lot, but implemented many its features in his Stylus).

    And yes, Compass FTW.

  67. LESS wins for me due to ease of setup and ease of use. We run a lot of expression engine projects and someone has built a handy EE plugin for LESS. You just tell it where your LESS files are, and where you want to compile your CSS and it takes care of everything else. Sure, the plugin parser isn’t perfect and it could *really* do with updating (hint hint Steven Milne ;)) but it meant that our team could switch to using LESS in a matter of minutes.

    Must admit though, SASS + Compass looks like a killer combination, i’d love to try it

  68. Rick T.

    i am using SASS for about a year now, and i think we get along so well, i might propose to her soon! :)

    – Rick

  69. I have used LESS and SASS and for development, LESS is easy-peasy-japanese to set up.

    SASS, well, I had my issues, even after installing the gems.

    I do have to say that syntax wise, I prefer SASS. I haven’t used the inheritance stuff yet, which you could say I am guilty of code bloating, but that’s because I didn’t quite grasped it yet (til now) and because well, I just read this and had a mini “A-HA” moment :p

  70. Good comparison :)

  71. chris

    regarding the @media nesting, LESS has this feature ( that lets you assign @media sizes to a variable. so you can do the nesting even easier than with SASS (imo) and you don’t need to use an alpha version. So your example would look like this:

    @phone: ~”screen and (max-width: 767px)”;

    .some-class {
    /* Default styling */

    @media @phone {
    /* Responsive styles */

    LESS +1 :)

  72. Preprocessing just doesn’t feel like ‘real’ code to me.

  73. What about performance?

  74. Benjamin Knight

    Clearly there’s a demonstrated need/desire for preprocessors which are sort of seen as a missing piece of CSS that we always wanted. Does it make sense for this to ever become part of the CSS standard itself?

    I imagine basically some sort of syntax could be agreed upon by the W3C and then browsers just process it natively.

  75. I may need to get SASSy on my next project, I started with LESS because it made sense but seeing some of the differences in nesting/extending SASS may be a better route for me to go. Hopefully the learning curve isn’t awful (doesn’t seem so at first glance).

    Great post Chris!

  76. I think something that will define who wins is how these pre-processors are integrated into IDE’s. The one that gets more easily compiled directly from the development environment well gain more users.

  77. mendeza

    +1 for Stylus. I’ve used both it and SCSS. You can’t go wrong with either, but Stylus has the edge.

  78. SASS runs almost out off the box on a Mac, so installation is not an issue when Ruby is already running.

    What’s puzzling me is that people still get the linear-gradient syntax wrong after it had been changed some months ago. In the unprefixed value, not the starting corner should be specified, but the ending point. See

    Chris isn’t really to blame here; it is Compass that generates the wrong code. (If it still does. Or has it already been fixed?)

  79. Here is more reason why I use LESS instead of SaSS:

    1. Ok there is a backport of Bootstrap to SaSS . Who is mad enought to add one more layer ?

    2. LESS is used in our large scale CMS for big CAC40 company
    => IT guys do not want any new language like Ruby. They want Java/WebSphere/Weblogic.
    => LESS is preprocessed/cached server side (in Java) because in real world files are modified, patch, …

    3. For debugging purpose LESS is JavaScript: So it works with jsFiddle, iPad Apps, SaaS site like WordPress … anythings that know plain old javascript.

    4. 2 languages (sass, scss) for SASS is one too many. And .sass talks to developers not designer. Do not forget the final goal of these framework is to fill the gap between CSS3 and next version.

    Many people chose SaSS because of Compass and because Bootstrap didn’t exists => big buzz. But now things have changed and the bootstrap commmunity becomes larger.

    • 1) If you need Bootstrap, then by all means use LESS, since Bootstrap is built on LESS.

      2) If your company already decided on using LESS, then by all means stick with LESS. It’s just silly to not use what your colleagues are already using. Btw: I use Sass and I don’t know one single line of Ruby. Not very scary.

      3) Debugging is sweet in Sass/Compass too, and it’s done server-side and outputs (very specific) errors directly on screen. Works even with Javascript switched off. Have you’ve tried it?

      4) That’s your opinion then. Not sure why you think “Sass talks to developers” any more than LESS does, as they are very similar. Is it because you assume you need to know Ruby to use Sass? Or because Javascript is much easier than Ruby? (you’d be wrong on both accounts)

      Comparing Bootstrap and Compass is like comparing apples and oranges. Compass is like a toolbox and Bootstrap is more of a blueprint/scaffold. As I said earlier: Had Bootstrap been based on Compass, it would have reduced it’s codebase considerably, instead of having to reinvent the wheel so much.

      And you assume too much if you think people chose Sass/Compass over LESS because Bootstrap did not exist.

      Doesn’t sound like you’ve even tried Sass/Compass yet?

      Anyways: LESS is a good choice too, and I recommend trying them both. And it’s not like you have to learn two programming languages; The syntax is almost identical.

  80. We established LESS in our company, due to various reasons. Some of us are still developing under Windows and are not familiar with the command line. SCSS Apps aren’t really usable under Windows (Scout crashes every now and then) and WinLess is an almost perfect counterpart to on Mac. So we can create an unique development environment for all our developers, regardless of OS.

    Also, i found it a lot easier to integrate LESS in our already established deployment process using Jenkins and ANT build files. The LESS Engine was as easy to deploy with Rhino as it would’ve been on Node, and creating an ant task for compiling was a no-brainer. And this is really important if you’re working on big projects with a lot of developers.

    Last but not least, Compass is really nifty, but we just don’t have the need for it. At least not yet.

  81. Michael Havard

    When I did my own evaluation of LESS & SASS I was a little put off by how complex SASS seemed and was confused by SASS formatting versus SCSS or how people were using Compass and SASS almost interchangeably. As the author stated, the documentation for SASS wasn’t as clear/usable as I would have liked. At the end of the day that left LESS the defacto winner. It did everything I needed it to, and although it didn’t do it in a technically pure manner (where developers give points for SASS), the outcome was generally the same.

    As always it’s a matter of preference, which sometimes comes down to a gut feel on comfort. People will get into wars defending their preferred framework. Which we’ve already seen here a little; people accusing each other of not giving x a chance or not even having used y; and other such ignorance.

    I think articles like this are good to get people thinking, to give them an introduction to a tool and have them look at things they might not have thought about. However, at the end of the day these individuals need to sit down and do the same evaluation themselves versus just taking the popular tool or the underdog because said it was technically better.

    The general trend (anecdotal) that I’ve see in the comments here and from other sites is that LESS is simple and does quite a bit on it’s own while maintaining a low barrier to entry. This would make it more ready for adoption by established shops and designers; People who don’t want to have to introduce a new language into the mix or just want a quick productivity boost.

    SASS on the other hand seems to have more traction among developers, like those already in Ruby, or those that have a fair amount of control over their environments and outputs. It seems to me that quite a few people using SASS also mention Compass, inferring that either Compass was their draw into the SASS world OR once they found SASS they found some gaps that Compass helped to fill.

  82. Great article & comparison. First things first: know your css before playing with a preprocessor.

  83. I’m going to try LESS from now on… Well-described.

  84. Bommer!! Before I dough into all this SASS, Compass and CodeKit, I thought that:

    @import "style.css";
    /* Containing: .selector { color:#A55A55; font-size:18px; } */
    .selector {

    Through all the cleverness, would just output:


    It will actually (..and after renaming style.css to style.scss) become ass stupid as:


    As I understand, not even by using frameworks in CodeKit, this is possible? ..or have I missed something?

    • It seems I then needs to throw it through a the CSS Compressor called CSSTidy that manages to perform optimizations at a world champion level like that :D

    • For others interested, I’ll eat my words and recommend NOT to use CSSTidy as it is very outdated, dead and doesn’t support A LOT of CSS3 like, multiple background/-image declarations for vendors, keyframe animations and media queries.

      A magic and pretty much self thinking CSS Compressor like that simply hasen’t been invented yet – and I’m pretty sure it never will be. – Because of those countless chances for breaking your code.

      So when maintaining stupid stuff as a sub-theme lazily, accept a little bit bigger output (caused by the overrides) and ALWAYS compress with YUI Compressor or similar.

      There wouldn’t be a need for such thing in any other cases anyway, if you did your job right.

  85. Hmmm i just newbie for CSS Style Web,May be i must bookmark your website :)

  86. Firsty, great post. Way to be unbiased. I currently use SASS and am going to look into Compass to improve my work flow.

    A lot of my colleagues use LESS and I’m dreading my manager choosing it over SASS so I have some converting to do! The SASS website needs a serious look into!

  87. K-Man


    how do you use Compass/SASS and WordPress? Compass outputs a screen.css while WordPress requires a style.css. Btw: i’m running on Windows

    How does LESS handle this topic?

    • Your can name your files whatever you want, there is no requirement in neither Compass or WordPress that your css-files need to be given a specific name.

    • *neither – nor. Gah.

    • I wrote something similar to this on a while back, essentially you can just create a new css file (or SASS/LESS) and call it to the wordpress style.css as an @import if you want to keep with the naming conventions.

      The only reason I opted for this is because most compilers like CodeKit and the likes strip off comments and WordPress prefers the comments in the style.css for identifying your theme.

  88. In most compilers I’ve seen, including CodeKit, you can configure whether you want to to strip comments or not.

  89. I’m honestly not seeing any point to this, learning another syntax, when you can already do conditional CSS in javascript.

  90. I have only ever used LESS. I admittedly chose it over SASS because of their website. I was able to learn LESS syntax pretty much at first glance and thus start using it on my projects without expecting any difficult learning curve or constant need to search the documentation. This was a crucial factor in not only selecting LESS over SASS but in trying out a CSS preprocessor at all. I commend LESS for breaking that barrier.

    After reading this article I can see why SASS may be considered a “better” preprocessor, however I am still unconvinced it is the better solution for me. Much like how a Mac delivers a better experience than a PC despite the fact that most PCs often provide more power and flexibility, I find LESS to be a better experience and simply more practical than SASS. I’m open to change that but for now that’s where I stand.

  91. Here’s a short gist that shows a simple comparison using LESS, Sass, and Stylus. Stylus wins:

    Sass vs Stylus vs LESS

  92. jacmoe

    Sass wins because it has Compass, and because it is the default css framework for Ruby on Rails. Let’s not underestimate popularity. :)
    It has tons of extensions which are only a gem install away.
    Ruby on Windows is dead easy to install.
    I tried to get into using Less, but it doesn’t even come close to Sass with regards to available plugins.
    I am lazy and do not like to reinvent any wheels.
    Sass-buttons, Suzy, Compass, Bourbon.
    And I can choose between two syntaxes: scss or sass.
    Scared of the command line?
    Just run ‘compass watch’ in a box and that’s it.
    It spits out css each time a scss/sass file has changed.
    And then you just upload the generated css to your server.

    How to get started?
    Install Ruby.
    And run this:
    gem install compass
    Or, if you are using Suzy:
    gem install susy –pre
    It will deal with all dependencies automatically.

    Thanks for giving me this opportunity to evangelize Sass/Compass :)

  93. I love LESS, especially used with SimpLESS. SimpLESS checks your .less code for changes and compiles vanilla CSS on the fly! Kicking myself for not trying it sooner!

  94. I’m pretty sure Team Treehouse uses SASS:

    And if I’m not mistaken that’s Nick Petit’s work. But Idk if he’s just a teacher there or not.

  95. Just one more vote for Stylus! Its simple syntax makes reading and writing mixins and extended classes a breeze.

    Stylus feels more like coding too, for example instead of creating a variable the ‘CSS’ way:
    $var: 5px
    You do:
    var = 5px

  96. Deepak
    Permalink to comment#

    anyone knows the css editor for LESS and SAAS? I use Adobe Dreamweaver CS5 but it doesn’t support yet..

    • Is it syntax highlighting you’re after? Both LESS and the SCSS-syntax of Sass are supersets of CSS, so you don’t need any particular syntax highlighter. Just use the CSS syntax highlighting.

      If you need a compiler for LESS or Sass, I recommend using the command-line as outlined in the tutorials, or look into Codekit.

    • Although I haven’t tried it myself, (I use sass on linux), there IS a less compiler for the PC (Windows), and since codekit is only for Mac, I thought I would post it here in case it helps. :)
      it is here:

  97. in less

    .loopingClass (@index) when (@index > 0) {
      .myclass {z-index: @index }
      .loopingClass(@index - 1);
    .loopingClass (0) {}
    .loopingClass (3);

    it will output three class having the same name, but…for what?

    .myclass {z-index: 3;}
    .myclass {z-index: 2;}
    .myclass {z-index: 1;}
  98. Chris Sanders
    Permalink to comment#

    I started out with SASS and I looked at LESS. However, SASS had more features and a stronger development community around it so I chose SASS.

  99. Permalink to comment#

    Awesome article =) I’ve been using LESS for awhile but never SASS… I think I’ll set it up and give it a go… It sounds way ahead of LESS.

  100. Alan Shortis
    Permalink to comment#

    I have been using SASS for a year or so now after finding the excellent Midscape Web Workbench extension for Visual Studio. It runs inside VS, includes compass and compiles CSS as you save each SCSS file. The generated CSS can then be included in the built in bundling and minification.

    Given the choice, I would always choose to write SCSS over plain CSS. Always.

  101. Permalink to comment#

    Searching a way to optimize writing CSS I came to LESS and SASS. I think the syntax of SASS very confusing, so I’ll probably stay with LESS or SCSS.

    However I find the article very well.
    Thanks for the explanation.

  102. Rick
    Permalink to comment#

    But does SASS have a pure PHP compiler?

    SASS seems nice, but I use JojoCMS which supports LESS files directly. A simple forced refresh and all the LESS styles get recompiled, no external tools needed.

  103. Mitali
    Permalink to comment#

    Great article, as always. Thank you so much. I was feeling a bit lost before i read your comparison. And great job breaking down the answer according to length.

  104. Permalink to comment#

    Well I was a LESS user, now I use SASS. Since SASS fits perfect with Ruby. And SASS has some color functions. I likes SASS functions and mixin (great libraries too like bourbon and compass) over LESS.

    LESS is easy to start and setup, while SASS is complicated at beginning to setup. But both have similar syntax. Im a fulltime SASS user since last 1 months.

  105. Lisum
    Permalink to comment#

    Great article. learned a lot about how to compare different tools.

  106. Art
    Permalink to comment#

    Time for pending issue update? ;-)

  107. In Sass, can I detect the color in variable if it’s light or dark? If yes How can I do that?

  108. Nexz

    If you are a web developer, you should learn both LESS and SASS.

    If you are working on a project, deciding on one, and you don’t have existing compatibility requirements, you should choose LESS.

    Here is why:
    One word, Node.js! It is Full Stack JavaScript platform. Not trying to show off but I like to say this; instead of using server side languages i.e PHP, Python, Perl, ASP, JSP, etc., it uses the same JavaScript. Advantages: it is asynchronous (more later), and non-blocking (all those server side lang just mentioned are blocking), both of which lead to scalability. Yes, it is Server Side JavaScript that can do I/O and that is non-blocking.

    You may say that current large sites that use blocking server side languages are also scalable. Yes, they are but in order to achieve that, they have to throw in excellent network design, and a lot of hardware (and async servers like nginx). Even then, I doubt they still can’t handle mobile connections/clients gracefully. And Node.js can and is designed with mobile in mind. There are things Node.js isn’t designed for, of course.

    Going back to LESS vs SASS, LESS is written in JavaScript and integrated into Node.js via LESS.js. SASS is written in Ruby. In essence, I will say if you are thinking long-term (i.e mobile), go for LESS. But if you already are using Ruby on Rails or alike, go with SASS.

    ps. I am not a web developer but comes from networks/servers/database background. And I am working on a project that supports traditional and mobile clients.

  109. Nexz

    Update on my previous comment

    My additional research shows that SASS is supported with Node installation, i.e libsass C library. Here is one link,

    So SASS can be used with Node. Yet I still stand my original decision, not because of ego but the following:
    1. libsass means you are embedding Ruby into Node so that SASS can be run under it
    1.1 This introduces version problems. libsass will be trailing Ruby compiler. Features supported with latest Ruby compiler might not be supported with libsass
    1.2 Other version problems may arise due to SASS framework you use

    Node.js is natively JavaScript. It means if you use LESS, it will integrate right into Node.js ecosystem. And modern mobile devices support JavaScript via mobile versions of modern browsers
    2.1 Imagine if you use SASS. That means mobile clients can’t change the layout (.css) on the fly without contacting back to Node servers (where libsass resides). In other words, you can’t directly drop in Ruby code on client devices
    Update of your SASS code means (re-)compilation of your code via libsass embedded inside Node. This introduces additional steps and at the least, latencies
    If you look at design of Node.js, it is one language at both client side and server side. When you drag Ruby into Node (even via libsass), you are going back to traditional paradigm which is server side programming using different language. Now, I am guessing a lot in Node ecosystem are built around this one-language assumption. Who knows what kind of problems you’ll run into if you use SASS.

    • Rick

      That’s all mostly moot because most projects using SASS or LESS generate and store the compiled code ahead of time. Usually add part of the build process but occasionally part of a server side routine. So blocking is never an issue and most of the time library versions don’t matter either.

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".