The watch feature means a developer doesn’t even have to refresh the browser to see his changes go into effect.

Argue against this point

With LESS.js there’s no need for a Terminal to compile your CSS, it will compile in the browser and cache so it only compiles once until saved again.

Argue against this point

Handling of CSS3 within Sass / Compass is much better especially regards transforms and animations.

Argue against this point

The original ‘lessc’ is a Ruby gem. It still works, and LESS can run from Ruby, converting files and watching for changes.

The current LESS compiler runs in Javascript. This means it can run in nearly any browser on the internet (seriously, who turns Javascript off, or runs IE5?). The Javascript base also lets it run anywhere Javascript can run, which includes Adobe Air applications, and on the JVM with Rhino, which in turn means it can be called from any JVM language like Java, Scala, ColdFusion, Clojure, Groovy, and so on.

The Javascript core also supports NodeJS, which has been very quickly gaining support throughout the web development world.

Furthermore, there are unofficial, and very good, ports to other platforms.

The LESSPHP project (http://leafo.net/lessphp/) is on version 2.0, and still under continuous development. This PHP version serves LESS files from the web server, and has a command-line converter and file watcher much like the Ruby version.

The DOTLESSCSS project (http://www.dotlesscss.org/) brings a LESS compiler to the .NET world, which can intercept and compile less files through an IIS file handler, or programmatically in an ASP.NET application, or from the command line, again, like the Ruby version. This project is still under active development and has created some buzz in the .NET world. DOTLESSCSS means LESS can run with any CLI language as well, so it integrates with C#, VB.NET, C++, F#, Iron Python/Ruby/Lisp, and more.

Argue against this point

Less handles scopes as I expect it:

Sass | Less
-------------------------+-----------------
$color: black; | @color: black;
.scoped { | .scoped {
$bg: blue; | @bg: blue;
$color: white; | @color: white;
color: $color; | color: @color;
background-color: $bg; | background-color: @bg;
} | }
.unscoped { | .unscoped {
color: $color; | color: @color;
// Would be an error | // Would be an error
// background: $bg; | // background: @bg;
} | }
And their different output:

Sass Output | Less Output
----------------------------+----------------------------
.scoped { | .scoped {
color: white; | color: white;
background-color: blue; | background-color: blue;
} | }
.unscoped { color: white; } | .unscoped { color: black; }

https://gist.github.com/674726

Argue against this point

you may define default values into mixins so you need not pass arguments to call them, like:

.color(@color: red){//parametric mixin color: @color; }

.sometext{ .color; }

just fine ;)

http://lesscss.org/#-parametric-mixins

Argue against this point