
SASS vs. LESS - cobychapple
http://css-tricks.com/sass-vs-less/
======
micheljansen
I think the individual comparisons are good, but the conclusion is wrong. Yes,
Sass is technically superior to Less; it can do a lot of things that Less
cannot. That does not mean that you should use Sass over Less.

The truth is, for 99% of use cases they are exactly the same. Sass is a bit
more mature and it allows more programming, so it is potentially more powerful
than Less, but that also allows it to deviate for CSS further, which is not
necessarily a good thing if you have to work with people who only know CSS.

I personally use Less because it helps me develop faster. Less is implemented
in JavaScript, which means it can run in the browser. Less.js' "watch mode" is
awesome for speeding up development: save your .less stylesheet and the
browser immediately shows the new styles. This is something SASS cannot do
and.

Finally, to correct some factual errors in the article: Less _does_ allow some
programming, loops etc. It's just incredibly awkward and barely useful, but
you can use JavaScript (I used that to make this:
<https://github.com/micheljansen/dynamicgif.less>). Also, the "Helping with
CSS3" point is moot if you use <http://lessprefixer.com/> and keep that
updated.

~~~
ahoge
>Sass is technically superior to Less; it can do a lot of things that Less
cannot. That does not mean that you should use Sass over Less.

No, this does mean that you should use Sass. This is how technical decisions
are made. You create a list of categories with weights and then you score all
available options and add their points. You then use the one with the most
points. Y'know, the best one.

>This is something SASS cannot do and.

Sass also has a watch mode. Well, you'll need Ruby, but so what?

If you use a static website generator (like Middleman) for your quick and
dirty prototypes, there is zero overhead involved. You use "example.css.scss"
as file name and reference "example.css". That's all you have to do.

~~~
Tloewald
I think making CSS more like a programming language is a bad idea. Insofar as
LESS lets you do dumb programming tricks in your faux CSS it's a bad idea. I
think SASS is going in the wrong direction of putting more ability to create
convoluted rubbish in the hands of people who create enough convoluted rubbish
with simpler tools.

And I think the signs of activity on LESS vs. SASS reflect not that SASS is in
mor aggressive development, although it might be, but tha LESS is more popular
but the developers are more cautious in adding features.

~~~
ahoge
>I think SASS [...]

Based on what? Sass helps me to write cleaner, better organized code.
Furthermore, it reduces typing work. It's great, really. There is a reason why
more and more people are using it.

Did you see the vendor prefix debacle? With Sass/Compass, vendor prefixes
aren't an issue anymore. Everyone who used Sass/Compass correctly was not part
of the problem.

How do you handle sprite sheet generation? How do you handle cache busting of
your background images? How do you handle vendor prefixes? These things are
very annoying to handle if you have to do that manually.

~~~
Tloewald
You don't need dumb programming tricks to handle vendor prefixes. What I'm
against is making CSS more complex.

------
SkyMarshal
He uses SASS and SCSS interchangeably. For anyone else not familiar with the
difference:

 _"Sass consists of two syntaxes. The original syntax, called "the indented
syntax" uses a syntax similar to Haml.[2] It uses indentation to separate code
blocks and newline characters to separate rules. The newer syntax, "SCSS" uses
block formatting like that of CSS. It uses curly brackets to denote code
blocks and semicolons to separate lines within a block. The indented syntax
and SCSS files are traditionally given the extensions .sass and .scss
respectively."_

<http://en.wikipedia.org/wiki/Scss>

Also:

 _"Sass and LESS both use the standard CSS syntax. This makes it extremely
easy to convert an existing CSS file to either preprocessor. Sass uses the
.scss file extension and LESS uses the .less extension. The basic Sass or LESS
file can be setup like below:

...

As you may have noticed, this is just regular CSS, which compiles perfectly in
both Sass and LESS. It’s important to note that Sass also has an older syntax,
which omits semicolons and curly brackets. Although this is still around, it
is old and we won’t be using it past this example. The syntax uses the .sass
file extension and looks like this:"_

[http://net.tutsplus.com/tutorials/html-css-
techniques/sass-v...](http://net.tutsplus.com/tutorials/html-css-
techniques/sass-vs-less-vs-stylus-a-preprocessor-shootout/)

------
astrofinch
What about stylus?

<http://learnboost.github.com/stylus/>

<http://visionmedia.github.com/nib/>

More?

<http://news.ycombinator.com/item?id=3945633>

Some compiler geek should create a tool to translate code from one
preprocessor to another, so mixin support would not be an issue.

~~~
snprbob86
We've used both Stylus and SASS. I've even contributed a few patches to
Stylus. Ultimately, we decided that Stylus is a bit of a failed experiment in
syntax/punctuation minimalism; SASS is much nicer to work with.

The key problem is that Stylus doesn't make a clear visible distinction
between control structures, mixins, and other meta-level constructs. With
Stylus, you can trivially override built-ins and it's very difficult to "go to
definition", so to speak. SASS has very obvious symbols which call out the
presence of preprocessor stuff. This makes it much easier to visually scan
stylesheets and map what you're seeing in the inspector to what you're seeing
in the source files.

Simply put, because the gap between CSS and the preprocessor language is so
narrow, it makes sense to call out differences. Unlike, say, C and x86, it's
too easy to look at Stylus and CSS side by side and be confused by their
similarities.

~~~
astrofinch
Do you know if the Stylus compiler works any faster than the SASS one? Long
compile times were an issue for me when I was using SASS a year or so ago.
Although come to think of it, maybe I could've hacked a workaround by
splitting my CSS into more than one SASS project.

~~~
snprbob86
During an experiment, I hit the 4095 selector limit in IE <= 9. Even with that
combinatoric explosion of preprocessing hackery, compilation still only took
about 2 seconds with SASS. Sooo, I'm not really sure what problem you're
having :-)

------
Vekz
I've always considered SASS the only true successor to CSS.

LESS and SCSS are syntactically conservative. I feel they retain the
grammatical conventions of CSS (curly braces) as a way to ease the learning
curve for conservative developers.

They introduce developers to the powerful features (mixins, variables) of
extended CSS. But retain their familiar CSS curly bracket syntax.

Eventually it makes sense for said conservative developers to take the next
step and adopt SASS's clean syntax.

~~~
bad_user
I like braces.

There is also another advantage to Less/SCSS, which is that existing CSS files
are already compatible, so you can start a gradual migration without effort.

This means for instance that an outside designer, that does not know Sass, can
come in and contribute directly to the codebase without his workflow being
disrupted and without me having to tutor him in Sass. This is how design works
anyway - you start with a bunch of PSDs that get accepted, you transform that
into static HTML and CSS (that have to be emailed around and approved), then
you start adding dynamic features, you then go back to the designer to fix the
design in case the dynamic content doesn't blend well, then you start
refactoring the HTML/CSS to be clean and easy to maintain ... but this is only
the last step, because the other steps, like getting the design right, are
more important.

When you say that Sass should be the true successor to CSS, you're thinking
like a programmer. I also wish that Gimp would be the true successor to
Photoshop, but that won't happen.

~~~
goblin89
> There is also another advantage to Less/SCSS, which is that existing CSS
> files are already compatible

Not sure about SCSS, but in my case Less choked on some complex hacks like IE
filters. Not arguing about their evilness, but the fact remains—not always you
can simply rename .css to .less and gradually start using new features. (In
the end I kept CSS as is, with a separate Stylus file with overrides and new
styles. SCSS wasn't an option, and I have a feeling it also suffers from these
issues.)

------
ricardobeat
That was an awkard conclusion on "Active Development". The total number of
issues and pull requests on LESS dwarfs that of SASS, so a larger number of
open/pending ones is natural. Some more numbers:

    
    
        Watchers:
          SASS: 1022
          LESS: 5480
    
        Forks:
          SASS: 138
          LESS: 731
    
        Total issues:
          SASS: 390
          LESS: 809
     
        Total pull requests:
          SASS: 62
          LESS: 199
    

That's a clear win for LESS in my book.

~~~
zalew

        Number of commits in the last month in LESS: 11
        Number of commits in the last month in SASS: 35
    

that's the important part.

~~~
ricardobeat
Simply looking at commits/month doesn't tell us anything. Want to compare size
of commits? Lines affected? Comments vs code? Code vs tests? I think the
general picture is much more favorable for LESS. If anything, there's a
hundred people ready to pick up development at any time.

~~~
zalew
> a hundred people ready to pick up development at any time.

I really wish that was true. From my experience, almost every time I jump to
the forks sections of libraries I'm using (or interested in using) I'm
disappointed when I see that 99% of thos forks contribute nothing. Forking by
definition was a serious move, now (on github/bitbucket) it's not - most of
the time it's just one-click copying the project to your own collection and
it's just noise when I'm really looking for an alternative fork. Just my 2
cents why I'm not impressed by numbers of forks as a project sustainability
measure, it's not an opinion on less/sass specifically.

~~~
ricardobeat
I've seen this argument a few times. Forking on github is just the fastest way
to try something out with the codebase and/or make a pull request. That was
happening before, in a smaller scale, you just couldn't see it. I think the
number of forks directly reflects the size of the community and traction.

I agree that it's hard to find _real_ forks, watchers are a good indicator but
you can't search/filter by that. On the other hand, meaningful forks tend to
change their name the moment they detach from the original.

~~~
zalew
You certainly have a point, I just too often came across projects updated 1
year ago or earlier with 50 forks and any further support in there. Maybe code
hosting providers could by default hide from the project page the ones that
haven't contributed anything (I know they won't do it, they like the big
numbers).

------
creativityhurts
LESS became popular thanks to Twitter Bootrstrap and to the fact that you
don't need Ruby to use it, which is a big plus for Windows users.

I use them both on daily basis, SCSS & Compass for a Sencha Touch project and
LESS & Bootstrap for web dev work, along side with CodeKit to compile them and
the major difference that I see is the speed of compiling. The projects I work
on are both pretty large and with many .scss/.less files but LESS compiles way
faster for me and this is a big plus.

Also, LESS is pretty useful for rapid prototyping since you can use the
less.js and skip the compiling part altogether.

~~~
talmand
I use SASS on Windows with no issues and it was rather easy to get up and
running. Granted it did require the installation of Ruby of which I only use
it for this, but that's a small price to pay.

~~~
Silhouette
Indeed. IMHO the concerns expressed by some here about relying on Ruby are
greatly exaggerated.

For anyone who is curious, the steps required to use SASS on Windows are
something like:

1\. Download RubyInstaller from rubyinstaller.org and run it. (This is a self-
contained Windows installer for Ruby and the related tools/documentation.)

2\. Run "gem install sass" at a command prompt. (This downloads and installs
SASS itself, including SCSS.)

Personally, I'd love it if Ninite picked Ruby up as an option, because I
already install many other tools that way in a single step. However,
installing Ruby manually is no harder than installing any other piece of
Windows software you download, and installing SASS on top is literally a one-
liner.

Unless you're developing on a relatively old and low-powered system, I don't
see any downside to having the extra software installed either: it's just
another tool, occupying a few MB of hard drive and a few characters in your
PATH, and IME it's perfectly friendly toward development toolchains for other
languages.

~~~
talmand
Your two-part explanation is accurate. The Sass team was nice enough to even
point you to RubyInstaller right there on their download page.

------
jay_kyburz
So, at the point CSS becomes a programming language of its own I'd rather just
use java script. Somebody should come up with some way to define you style
data in JSON, then parse and process the data on load.

~~~
duncans
<http://www.w3.org/Submission/1996/1/WD-jsss-960822>

------
charlesr
Sass also has Susy, which is just a _superb_ grid system. I can't adequately
express in words how much I love this grid system. It's mahtava.

<http://susy.oddbird.net/>

------
latchkey
This is a really good writeup and I really appreciate the bit at the end about
pull requests and issues as I do feel that developers should stay on top of
their communities. That said, I like the mixin syntax of Less better and my
favorite project Bootstrap uses Less, so I'll stick with Less.

~~~
eropple
Agreed on the syntax, but for me the bigger issue that keeps me with LESS is
that I have no interest in using a Ruby project for something integral to my
build process because then I can't hack at it without a bottle of antacid. I
don't work in Ruby and I have a strong desire not to; on the other hand, while
I don't claim to _like_ it, I'm quite comfortable with JavaScript and can work
with LESS's code if I need to (and it has come up in the past).

~~~
tomeric
This is one the reasons Hampton Catlin (the original author of Sass) created
libsass, a port of Sass to C for portability. Check it out:
<https://github.com/hcatlin/libsass>

~~~
astrofinch
Is it safe to assume that this compiles CSS much faster than the original?

~~~
eropple
After some brief testing: definitely. Faster than LESS by a good bit, too.

I'm not sure I'm going to use it, because of the compiled dependency (I'm on a
Scala/Vert.x stack and I like being able to just check it out and hit "go"),
but it's at least a practical option for me and I'm glad it exists.

------
c4urself
Good write-up

Not sure on my history here but i'm pretty sure i remember only the SASS
variant being available (no braces among other things) while LESS stuck to a
more css-like grammar. later SCSS came along which was CSS grammar for SASS.

It seems like I've run into more projects using LESS -- anyone know of any
statistics?

------
brikis98
IMO, SASS ~= LESS, but Compass > *. Damn shame that Twitter Bootstrap went
with LESS.

~~~
lobo_tuerto
Then there is this:

<https://github.com/thomas-mcdonald/bootstrap-sass>

All the twitter bootstrap mixins available to you in sass format.

------
Pkeod
It's Sass not SASS.

<http://sass-lang.com/>

------
leetrout
The author makes the point that LESS uses the `@` for a variable identifier
while SCSS uses `$` (and that he feels this is better) but CSS4 spec today
says it will use `$` for parent selectors.

<http://www.w3.org/TR/selectors4/#subject>

I don't do a lot of FE dev but I can count the number of times I've used `@`
on one hand. However, I could see myself making use of `$` as a parent
selector quite often. How would SCSS adapt to this?

------
mambodog
As far as I'm concerned, Less, Sass and Stylus all provide the features for
the way I like to write styles (DRY, with composability) so the main thing
that influences which I'll use on a project is how easily it fits into the
workflow. That means Stylus for Express projects, Sass for Python/Flask.

When I'm at my day job I use Less (well, more specifically Lessphp) for the
simple reason that there's a Drupal module for it, which integrates very well
with building Drupal sites.

------
wvs
That looping construct in LESS is rather reminiscent of C++ template
metaprogramming. Or ML/Haskell without higher order functions.

------
tferris
This comparison distracts from better stuff out there:
<http://therain.posterous.com/sass-scss-lessthey-all-suck>

~~~
xutopia
I find that harder to read than if it had a : separating the attributes.

~~~
pygy_
You can use it if you want, punctuation is optional.

<http://learnboost.github.com/stylus/>

