LESS vs Sass? It’s time to switch to Sass

sass vs less by zing design

By Zing Design

The Sass versus LESS argument has been done to death. In this article I’ll explain why Sass really is the best and why you should start using Sass if you haven’t already. If you are interested, I’ve also written about how to get started using Sass and the problems with pre-processors.

Before I begin my highly opinionated tirade, let me just mention that I learned LESS first. LESS is great for beginners: it’s really easy and quick to set it up. It’s very similar to plain CSS, so writing it is intuitive. Compared to CSS, everything about LESS was very easy and friendly, I was quite enjoying LESS for a while…

…Until I discovered the truly awesome power of Sass and Compass. Looking back, I like to imagine LESS as the training wheels for beginners, or perhaps a gateway-drug into preprocessed CSS. Sass is the next level, a tool for the slightly more experienced front-end developer.

Why Sass is better than LESS

  • Sass lets you write reusable methods and use logic statements; ie. conditionals and loops. LESS can do these things but in an inefficient and counter-intuitive way (ie. guarded mixins for conditionals, self-referencing recursion for loops). Like LESS, Sass comes with lots of very handy functions built-in, including color manipulation, mathematics, and parameter lists.
  • Sass users can utilize the awesome power of the Compass library. There are libraries available to LESS users, but nothing really comes close to Compass, which is regularly maintained and contributed to by a huge community. Compass has some really awesome features like dynamic sprite-map generation, legacy browser hacks and cross-browser support for CSS3 features.
  • Compass also lets you add an external framework like Blueprint, Foundation, orBootstrap on top. This means you can easily harness all the power of your favorite framework without having to deal with the mess of using multiple tools.

Problems with Less

LESS aims to be as much like CSS in style, syntax and structure. While this is a nice thought for easing users into writing it, there are a few issues which make it a lot less fun to work with than Sass:

Logic statements

In LESS you can write a basic logic statement using a ‘guarded mixin’:

.lightswitch(@colour) when (lightness(@colour) > 40%) {
  color: @colour;
  background-color: #000;
  .box-shadow(0 3px 4px #ddd);
}
.lightswitch(@colour) when (lightness(@colour) < 41%) {
  color: @colour;
  background-color: #fff;
  .box-shadow(0 1px 1px rgba(0,0,0,0.3));
}

The equivalent in Sass uses if statements:

@mixin lightswitch($colour) {
  color: $colour;
  @if(lightness($colour) > 40%) {
    background-color: #000;
    @include box-shadow(0 3px 4px #ddd);
  }
  @if(lightness($colour) <= 40%) {
    background-color: #fff;
    @include box-shadow(0 1px 1px rgba(#000,0.3));
  }
}

Loops

In LESS you can loop through numeric values using recursive functions:

.looper (@i) when (@i > 0) {
  .image-class-@{i} {
    background: url("../img/@{i}.png") no-repeat;
  }

  .looper(@i - 1);
}

.looper(0);

.looper(3);
//--------------- Outputs: --------------------
//.image-class-3 {
//  background: url("../img/10.png") no-repeat;
//}
//.image-class-2 {
//  background: url("../img/9.png") no-repeat;
//}
//.image-class-1 {
//  background: url("../img/8.png") no-repeat;
//}

In Sass you can iterate through any kind of data, which is much more helpful:

@each $beer in stout, pilsner, lager {
  .#{$beer}-background {
    background: url("../img/beers/#{$beer}.png") no-repeat;
  }
}
// ------------------- Outputs: ---------------------
//.stout-background {
//  background: url("../img/beers/stout.png") no-repeat;
//}
//.pilsner-background {
//  background: url("../img/beers/pilsner.png") no-repeat;
//}
//.lager-background {
//  background: url("../img/beers/porter.png") no-repeat;
//}

Custom functions

In Sass, you can write your own handy functions like so:

//Courtesy of Foundation... 
$em-base: 16px !default;
@function emCalc($pxWidth) {
  @return $pxWidth / $em-base * 1em;
}

In LESS:

@em-base: 16px;
.emCalc(@pxWidth) {
  //Ah. Crap...
}

Hmmm… Which would you rather use?

Problems getting started with Sass and Compass

It seems like the biggest problem that people have with moving to Sass are:

  • The added hassle of setting up the Ruby environment;
  • Crippling fear of the command line;
  • The inconvenience and time involved switching to a different tool;

To help with this, at Zing Design, we’ve written a tutorial for beginners eager to make the move to Sass and Compass which details every step to show just how easy and fast it is to get started, the awesome power of Compass, and how similar writing Sass is to other technologies.

If you’re already a Sass addict, take a look at our post about the problems with pre-processed CSS and the future of web presentation.

With the enormous popularity of Twitter’s Bootstrap, many designers and developers are moving toward this framework to fulfill their presentational needs. I’ve seen quite a few developers grumpy about the fact that it is built with LESS. As mentioned in another article, there are several forks of Bootstrap (like this one) which let developers customize their favorite framework in their favorite pre-processor language.

This article was originally published at https://www.zingdesign.com/less-vs-sass-its-time-to-switch-to-sass/

Previous

Dependency Injection in JavaScript

Private Variables in JavaScript with ES6 WeakMaps

Next

46 thoughts on “LESS vs Sass? It’s time to switch to Sass”

  3. I have used both LESS and Sass (scss) in multiple large scale projects. I started out with LESS on a few projects but then switched to Sass + Compass. Sass is awesome with all of it’s many features and I really started to like it. But, after a while Sass began to really affect my productivity … in a bad way. Like many other developers, I started to use tools like grunt to build preprocessed css, precompiled templates, and a number of other things. During one project the watcher was taking way to long (3 – 5 secs) to build the my css using Sass. I dont like waiting for this kind of thing and it started to really annoy me. For the next project, I switched back to LESS b/c I heard it was faster. And yes, it was much faster. To the point where i didnt have to worry about it. So, for me speed of compilation was more important than the feature set. The features you mention above are things that I only use on extremely rare occasions and I found that I dont really need compass. For some, Sass might be the right choice, but for me and my teams it’s not. I would try out the different preprocessors yourself and see which one you like, not which one has the bigger feature set.

      • Yeah but it seems that if you use gulp which use libsass to compile the scss code, it doesn’t compile statement like @extend.

      • It also doesnt make SASS any faster, it just allows other stuff to happen at the same time, the actual SASS compilation is still slow as hell.

        The ONLY time you should ever prefer SASS (when starting a new project) is if you really need those extra features that it provides. Whether you actually ever need them is another argument.

        Less has plenty of compass counterparts that are far easier, more intuitive and quicker to use. At the moment my preference is for Lesshat.

        Of the 3 points in the article, 2 are about Compass but Less has Lesshat (and others) so they arent advantages, and the top point about featureset is valid but if you employ OOCSS (or SMACSS) rules, even loosely, then it would be rare you’d ever need those extra features so that isnt an advantage either. So, no advantages and a few disadvantages, why are people wanting to go Sass again?

  6. Why “and Compass”?
    You can perfectly use Sass without Compass (and use Bourbon instead, for example).
    Sass+Compass is NOT a default bundle. That is also a reason why people don’t want to leave LESS : no big mess of mixins/docs coming with it.

  7. What a troll artical. At least take the time to make sure you have your facts straight and consider more than the very basics.

    > In Sass you can iterate through any kind of data, which is much more helpful:

    Incorrect, in less you can loop through anything too – lists in less are the same as lists in css, e.g. @var: a, b, c; you can then get the length and extract each item using the extract function.

    > Custom functions

    In less you can return values from mixins which does the same as a custom function. you can also provide your own javascript custom functions and javascript plugins to do AST modification.

    And that was just from a 1 minute skim read.

  9. Firstly, Prepros – https://alphapixels.com/prepros/ If you’re not using it, use it.

    Secondly, a major turn-off in Sass is the lack of dynamic imports. I.E. you cannot do this: @import “style#{$somevariable}.scss”;

    LESS mixins look nicer too – I much prefer
    body {
    .mymixin;
    }

    to

    body {
    @include mymixin;
    }

    The only place Sass has the upper hand is with the looping and the conditional logic. Sure, Compass is nice, but once you’ve got a white-label codebase to start your sites from, it’s hardly a game-changer.

  10. There wasn’t enough concrete evidence to sway me here. I’ve used both Less & Sass, and prefer Less. I’ve found it much easier to refactor existing CSS in to a Less file. I also like that less.js compilation negates the need to run a host-based compiler which is incredibly useful at times. Overall, I think both have their pros & cons and depending on many aspects of a project either one might be the best fitting solution. So why not learn both & know them well enough to understand which is right …

  13. Great artcile!!
    Makes three months that changed the LESS and SASS see the big difference in my workflow. LESS is not bad, but the SASS treated me better from a project, from this project started using it and never stopped!
    =D

  15. I recently tried giving SASS another chance because I was starting a new project and thought it would be a good time, however these are the main reasons why I sticked with LESS:

    – requires ruby

    – the grunt task is not pure-javascript, it’s just a shortcut to call the ruby compiler

    – given it just calls an external command, it can’t let me access the parsed tree of the document as a JS object before it converts it to CSS

    It’s not to mean there aren’t interesting things in SASS I’d like to use, but it just wasn’t a good fit for that project, maybe next time.

  16. I moved from LESS to SASS. The set up on SASS really put me off until I found the app called Scout. It really takes care of all the set up and processes everything really easily.

  17. What about the added step in your development workflow? The biggest issue for many people is that you can’t just make a change and reload the browser as you can with LESS (due to client-side js) — switching to SASS would add a lot of friction to this workflow.

    If only sass.js were a thing…

    • Make changes to your .scss file. Sass automatically generates the .css file (if you have it setup to watch), so you can do exactly that. Make change, reload the browser and see the change immediately. No need for sass.js.

  18. It depends on how big your team and requirements are, I prefer LESS, its better to know which one to use for which job.

  19. I would also stress the importance of Sass.app for those who are nervous about command-line CSS/Sass development.

    Sass.app has proven to be an indispensable tool for Sass development over here at Georgia Tech.

  20. For generatic mostly static websites, Sass is a no-brainer. For more complex web apps that don’t already have some other form of Ruby dependency, you really need to evaluate if you need the extra functionality that Sass / Compass provides, and if it’s worth the extra build complexity. Once you get into using Sass-based frameworks like Foundation, and need to manage versioning on Ruby, Sass, Compass, and Foundation across a dev team and build environment that is 99% likely to already rely on node, Less starts to look a lot more attractive.

  22. Just want to share my thoughts, I started with LESS, it was really intuitive and easy to roll, I did a large scale project with it and everything went smooth and fun, this was my first step into preprocessed CSS, next thing I wanted to build a project using the ‘foundation framework’ which built upon SASS, if you’re a mac user then I have to say SASS is much easier to install than LESS though they both are extremely easy to set-up in mac environment, next thing I discovered ‘HAMMER & ANVIL’, and my set-up today includes CODA2 as my KDE, HAMMER as precompiler, ANVIL as local server and SASS as my preprocessor for CSS, I save all my FOUNDATION \ BOOTSTRAP as ‘HAMMER’ templates and all of they’r design features as CODA snippets and when I need to start a new project it’s all done by clicking 1 button and everything is setup and ready to code, btw, i discovered ANTETYPE recently for MOCKUPS so basically I design a mock-up(you have bootsrtap design kits that you can dowload from antetype website) complete the fine tuning in photoshop and after the client approves I press this 1 button and start coding in whatever framework I feel like most suited for the design, I write all of this cause none of you mentioned ‘HAMMER & ANVIL’ so i thought I’ll share my workflow since I’m really happy with it and it makes me super productive, any thoughts or suggestions?

  23. Shouldn’t the LESS loop example output images 3.png, 2.png and 1.png not 10.png, 9.png and 8.png? Or am I missing something obvious?

  24. LESS is much, much faster to compile if you’re using a grunt based workflow (watch, etc). This lone fact trumps any other differences mentioned in this article.

  25. I think LESS and SASS are quite comparable, you can do similar things in both they both compile quickly enough.
    My main deciding factor is if I like prefixing my variable’s with $ or @.

  26. Frankly, I do not think that choosing SASS or LESS would really make a difference for our productivity. I spend 90% of my time using 10% of LESS features. Not because I do not know the library, but really because I did not feel the need.
    Rather than wasting our energy to compare these two great tools, we should focus on what is important: to convince those who do not yet use of preprocessors. And they are the majority.

  28. Guys, you don’t need to have Ruby to run sass. You have a fantastic super fast libsass C library for which one has node.js bindings. You can use bourbon mixins with this library.

  29. So…
    * You tinkered a bit with LESS a few years ago and haven’t it used since.
    * You have exclusively used SASS+Compass since.
    * You – sorry, but sooo obviously – didn’t bother to freshen up your LESS knowledge since (except maybe a quick google).
    * Which doesn’t stop you from using a condescending know-it-all tone throughout your post which is rather annoying concering your lack of knowledge regarding LESS.

    How exactly do you hope to really convince anyone to switch?

Comments are closed.