What is the smarter language that is smarter than CSS?

SASS

LESS

Node vs Ruby

Ruby comes pre-installed on far more machines than Node.js does. Given that these are tools for designers, this makes it harder to install Less than Sass for server side compilation.

Argue against this point

Line-tracable debugging support in Firebug

The FireSASS Firebug extension means that with supported compilers (such as LiveReload or the Drupal Sasson theme), you don't have to give up Firebug - an essential tool for most front-end coders.

Without FireSass, Firebug use for any compiled CSS language will only allow you to trace to the compiled css line number, leaving Less without adequate debugging tools. NOTE: A FireLESS extension was developed, but has had poor support, and I've never seen it actually work.

http://nex-3.com/posts/92-firesass-br...

Argue against this point

SASS support nested media queries

From the SASS reference:

.sidebar {
width: 300px;
@media screen and (orientation: landscape) {
width: 500px;
}
}

will compile too:

.sidebar {
width: 300px;
}
@media screen and (orientation: landscape) {
.sidebar {
width: 500px;
}
}

Unfortunately, this doesn't work (yet) in LESS.

Argue against this point

Conditions in CSS

Hi Guys,

i really like the simple approach behind less and would like to have conditions like they are possible in scss or sas:

f.e. you ask the user in a cms to setup a color:

And then you need to calculate the textcolor from this color, you will need something like a condition to ensure, that the contrast is still big enough to read the text.

#footer-container {
@if lightness($main-color) < 10% {
color: lighten($main-color,15%);
} @else {
color: darken($main-color,20%);
}

}

Thanks in advance
Kay

https://github.com/leafo/lessphp/issu...

Argue against this point

Mixins produce a more elegant and compact endresult

Less:
.test{...}
.test2{.test}
produces:
.test, test2{...}

Sass:
@mixin test{}
.test2 {@include test}
produces:
.test2 {...}

Besides the fact that the 'mixin' names do not appear in the endresult (kind of namespacing which avoids occasional nameclashing), it also has the advantage that all the not used mixins do not get included in the end result.

Argue against this point

The less watcher not as convenient as you think at first

The Less javascript watcher is very nice, but when development is over you have to edit your templates and change the links to point to the real CSS files instead of the less files unless you want to have a javascript dependency.

If you use a tool like [LiveReload](https://github.com/mockko/livereload) in combination with the sass watcher, there's no markup changes required to have live updates in your webpage.

Argue against this point

Global scope

That Sass uses global variables has never bothered me. The advantage IMO, being that it's just as complex as it needs to be in order to get the job done neatly, without complicating things beyond what is necessary. I can't think of a time where I've wanted Sass variables to have more sophisticated scoping.

Argue against this point

Scoping

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

ability to use nesting instead of, or in combination with cascading

LESS gives you the ability to use nesting instead of, or in combination with cascading. Lets say we have the following CSS:
#header { color: black; }
#header .navigation {
font-size: 12px;
}
#header .logo {
width: 300px;
}
#header .logo:hover {
text-decoration: none;
}

In LESS, we can also write it this way:
#header {
color: black;

.navigation {
font-size: 12px;
}
.logo {
width: 300px;
&:hover { text-decoration: none }
}
}
Or this way:
#header { color: black;
.navigation { font-size: 12px }
.logo { width: 300px;
&:hover { text-decoration: none }
}
}
The resulting code is more concise, and mimics the structure of your DOM tree.

http://lesscss.org/

Argue against this point

Node as easily installed as Ruby.

Making the argument that Ruby is installed on more systems is an argument from authority. The same argument could have been made 5 years ago against Ruby v. PHP, and look where we are today. I'd make the counter-argument that configuring Ruby with gems can be just as difficult with versioning as installing Node. Not a valid argument for SASS.

Argue against this point

Platform Support

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

Sass only has a server watch feature

The confusion lays with the fact that LESS has Two features referred to as "watch," since in addition to it's server counterpart, it also has a browser mode.

Sass has tooling to allow watching files for changes and browser plugins, just like LESS does. So on those things they are roughly equal.

LESS has a browser version in addition to watch systems on the server and plugins, to which Sass has nothing comparable.

http://lesscss.org#usage

Argue against this point

Learning Curve

LESS has a smaller learning curve for designers and developers because the familiar CSS syntax feels very natural. There is almost nothing to learn. SASS's python-like syntax is terse and strange to someone who already knows CSS.

Argue against this point

LESS has a clear, and superior, mixin syntax

An 'explicit' mixin definition in LESS is `.mixin() {...}`.

Selectors `.mixin {...}` or even `#mixin` or `#mixin>.partial{...}` can be optionally used as 'implicit' mixins.

You can use implicit mixins if you so desire. Sass doesn't have this useful feature.

The counter point argues that only having an explicit mixin is better then having both explicit and implicit mixins is better, but it's obviously not: it's just more limited.

Arguments refuting the opposing point:
"Sass has a less ambiguous/confusing mixin syntax
"Less uses `.mixin-name`, where the dot notation is already used in CSS to denote classes.
"Classic Sass uses `+mixin-name`, and SCSS uses `@include mixin-name`, which are clearly distinguishable at a glance from class notation."

First, the mixin notation is actually `.mixin()` which is not used in CSS. The dot is used, but so is the plus.

The Sass and SCSS syntax use `@mixin mixin` and `@include mixin` directives which are certainly more verbose, and you can use those if you get easily confused (it'd be better to simply comment your code). Of course in Sass, those directives can be replaced with `=` and `+` which are hardly more clear then `.`!

As for distinguishing at a glance, the mixin in LESS is invoked by `.mixin();` which is easily recognized as different then a rule definition by its lake of a rule body filled with CSS declarations, a thing that CSS authors can recognize very easily. Even if it wasn't, the Sass syntax isn't necessarily more obvious when it's invoked via `+mixin`.

So, LESS has just as clear a syntax, and additionally, the ability to use use regular classes as implicit mixins makes it a superior syntax.

http://sass-lang.com/docs/yardoc/file...

Argue against this point

Ecosystem

LESS has a large (possibly larger), active ecosystem. Consider the ports to PHP (LESSPHP) and .NET (www.dotlesscss.org), and the fact that LESS runs in Ruby, Javascript, NodeJS, and anything that can compile Javascript including Java. The exact size of the ecosystems are impossible to judge.

Argue against this point

Classes as implicit mixins considered beneficial

Enabling the CSS author to optionally convert an explicit mixin of the form `.clearfix() {...}` to an implicit mixin `.clearfix {...}`, has the benefit of being able to use `.clearfix` as a class in HTML ... because it is a class. It saves time, space, and clarity to not have to type `.clearfix(){...} .clearfix{ .clearfix() };` to get the same effect. Additionally, defining a mixin is conceptually very much like defining a class or id rule, and so the syntax is instantly familiar and comfortable.

On the concerns about the Principle of Least Astonishment: This concern is hardly justified.

Refutation:

Defining an implicit mixin, to a CSS author's mind, is still defining a mixin. Even promoting a regular class to a mixin by using it as such, is understood to the author as being a mixin. This user will be no more astonished that a change to a mixin propagated then a change to a variable. An author who understands the concept of variable usage will not be surprised. This is the "expected user" that the "Principle" is concerned with.

If such an accidental usage of an inappropriate class as a implicit mixin, and it's subsequent change were to propagate unexpectedly, it wouldn't propagate *in unexpected ways.* This would not rise to the concern of the Principle of Least Astonishment; it'd merely be a mistake, not of understanding, but of organization or memory.

Argue against this point

Mixins produce a more elegant and compact endresult

For the sake of comparing bullet points from one side to the other, LESS and Sass both have mixins, and using them creates "a more elegant and compact endresult."

I'm not sure about the content of the Sass sides point, since it's content is fairly incoherent, but I'll try to be fair by assuming what it meant.

It's possible that the author of the Sass bullet point meant it to be Mixins in general are great and why, and both have mixins, but forgot to post the point to the LESS side also. The other possibility is below.

From what I can make out, it could be the Sass proponent intended to suggest the following: "LESS creates an unintended and useless selectors/rules when mixins are used, and Sass does not." That's just plain wrong.

LESS has a useful feature that lets you *optionally* include a mixin as it's own class. It's optional, so no mixin definitions are included in the output unless you want it too.

So, yes. Mixins are awesome. LESS has them, Sass has them.

Argue against this point

LESS Control Directives

LESS allows for the use of control directives for including styles only under some conditions or including the same style several times with variations.

LESS has Pattern-matching and Guard expressions.

In addition to normal matching, LESS can Match on arity (serve different rules based on number of arguments):
`.mixin (@a) {
color: @a;
}
.mixin (@a; @b) {
color: fade(@a; @b);
}`
And Gaurd conditionals with advanced functions that inspect variables:
`.mixin (@a) when (lightness(@a) >= 50%) {
background-color: black;
}`

And much more.

Argue against this point

Is an argument missing?

Please contribute - sign in and add the argument yourself.

Is an argument inaccurate, incorrect or has it been debunked?

Please contribute a counter-argument that gives a reasonable response to the argument with a web address to a reference for further reading.

Does the text of an argument misrepresent it in a biased or inaccurate way?

Please tweet @stef on Twitter to start a conversation about how to fix it.

Embed this debate

Mash this debate

Get this debate as JSON(P)