まずは、古い記事やLESS派の人がよく誤って書いてること
- LESSの方がコンパイル作業が楽
- いやいや、今やSCSSには「SCOUT(Mac/Windows 無料)」「CodeKit（Mac Lion以降/有料/LESSやCoffe Scriptも対応）」などのアプリがあり、LESSにおいてのLESS.appと同等にGUI環境で使えます。それらのアプリを設定し起動しておくだけで、指定フォルダを監視、更新時に自動でコンパイルしてくれます。簡単です。
- LESSの方が、SCSSよりも記述が簡単。学習コストが低い
- いえいえ、学習コストはそんなに変わらないと思いますよ。LESSもSCSSも変数やミックスインなどの基本機能を使いこなせるまでの学習コストはかなり低いです。うまく使いこなすには慣れが必要なのは双方同じです。それぞれ高度なテクニックを使おうすると学習コストは上がるでしょうが、初めから無理に使う必要はないでしょう。
LESSの方が優れている点
less.jsを使えば動的にコンパイルしてくれる
lessファイルをリアルタイムにCSSにコンパイルしてくれるless.jsが使えます。開発時に気軽に導入できて便利、lessの大きなアドバンテージですね。監視アプリを立ち上げる手間とコンパイル待ち時間（１〜２秒…しかし結構長く感じる）を省いてくれます。（※本番アップ時には、速度UPのため、圧縮済のピュアCSSを使うこと）
LESS中でスクリプトの実行が可能
これはSCSSではできないLESSならではのアドバンテージ。@height: `document.body.clientHeight`;`みたいに要素や値の中でJavaScriptが実行できちゃいます。ただし、キャッシュ機能が付いてるとはいえ、動的にCSSを生成するよりもピュアCSS（コンパイル済みの）を用意しておいた方が初めの処理は軽く速いわけで、使うかどうかはケースバイケースでしょう。
参考：» Node.jsでLESSファイルを動的にコンパイルする – 5509
参考：Sass でもこんなのを作っておられる方がいる。
sassを動的にコンパイルするconnectのミドルウェア「connect-external-sass」 – hokaccha.hamalog v2
LESSを取り入れてるフレームワーク
Twitter製CSSフレームワーク「Bootstrap」、node.js上のWebフレームワーク「Express」など、LESSを採用している。
SCSS（Sass）の方が優れている点
「継承」が使える
ミックスインでも継承と同等のことはできます。しかしミックスインは呼び出されるたびに継承元のプロパティをコピーするので、コンパイル後のCSSが冗長になりやすい。継承は継承元のクラスに要素自身のセレクタを付加してくれるのでコード量も少ない簡潔なCSSに仕上げることができます（バージョン3.2では、プレースホルダー（%fooのように、頭に%を付ける）で継承元のセレクタ自身を消せるようになりました）。うまく使えば、いい感じでOOCSS的な使用もできるでしょう（Sassの存在意義への補足 – hail2u.net）。
例えば、 clearfix で考えてみる。まずは継承元クラスとして clearfix を定義。
.clearfix {
*zoom: 1;
&:before,&:after {
display: block;
height: 0;
visibility: hidden;
content: "\0020";
}
&:after {clear: both;}
}例えば #sample に clearfix を設定したい場合はこう記述。
#sample {
padding: 10px;
outline: 1px solid #999;
@extend .clearfix;
}コンパイルしてできたCSSはこうなる。無駄なくスマート。
/*継承*/
.clearfix, #sample {
*zoom: 1;
}
.clearfix:before, #sample:before {
display: block;
height: 0;
visibility: hidden;
content: "\0020";
}
.clearfix:after, #sample:after {
clear: both;
}
#sample {
padding: 10px;
outline: 1px solid #999;
}SCSSの .clearfix を %clearfix としておくと、下記の .clearfix の部分を消すことができます。
/*継承*/
#sample {
*zoom: 1;
}
#sample:before {
display: block;
height: 0;
visibility: hidden;
content: "\0020";
}
#sample:after {
clear: both;
}
#sample {
padding: 10px;
outline: 1px solid #999;
}ミックスインを使用した場合は・・・冗長。無駄が多い。
/*ミックスイン*/
.clearfix {
*zoom: 1;
}
.clearfix:before {
display: block;
height: 0;
visibility: hidden;
content: "\0020";
}
.clearfix:after {
clear: both;
}
#sample {
padding: 10px;
outline: 1px solid #999;
*zoom: 1;
}
#sample:before {
display: block;
height: 0;
visibility: hidden;
content: "\0020";
}
#sample:after {
clear: both;
}HTML中で .clearfix を指定するやり方もありますが、HTMLでスタイリングのための記述は文書構造とデザインを分けるという意味でもなるべく避けたい。
<div id="sample" class="clearfix">
内容
</div>LESSでも継承が使えるよう、独自に拡張して配布されている方がいます（LESSにextendを実装してみた – hokaccha.hamalog v2）。本家に採用されるのも時間の問題かも。
優先度の低いデフォルト値が使える
うまく使えば便利なケースもあるかも（自分は使ったことない）。
ネスト内にメディアクエリを記述すると、外に出してうまく処理してくれる
SCSS記述時に便利。コンパイル後にメディアクエリ記述がところどころに散らかってしまうのが難。
#site-title {//スマートフォン以外
font-size: 150%;
@media screen and (max-width: 480px){//スマートフォン
font-size: 110%;
}
}↓ コンパイル後
#site-title {font-size: 150%;}
@media screen and (max-width: 480px){
#site-title {font-size: 110%;}
}共通の便利機能
変数やミックスイン以外の便利機能
一行コメントに「//」が使える
地味だけど、これだけでCSSプリプロセッサを使う価値があると思う。/* */コメントに比べ、//コメントは入力が楽だし、/* */コメントと //コメントをうまく使い分ければコードの見通しをよくできます。/*! */ とするとコメントを削除する圧縮設定でコンパイルしてもコメントを残してくれるというのもいい。Coda のコードナビゲータペインに表示させるための記述 /* !コメント*/ と紛らわしいので注意
/* !テーブル */
/*-------------------------------------------------*/
/*変数*/
$color_table_line: #666;//テーブルの線
$color_th_text: #333;//thのテキスト
$color_th_link_text: #333;//thのリンクテキスト複数のCSSを、1つのCSSに統合できる（パーシャル）
別ファイルのSCSSやLESSを、コンパイル時に読み込んで 統合（マージ）したCSSを生成できます。CSSでの @import と全く同じ記述法なので直感的に使えます（SCSSの場合、読み込SCSSのファイル名は冒頭に”_”を付ける）。複数のファイルを1つに統合することで、HTTPリクエスト数を最小限に抑え、Webページの表示高速化にも有効。reset.css、CSS3プロパティ、共通で使いまわすCSSを外部化しておけば、複数のサイトで使い回しが効きます。
要素名やプロパティ名の中でも変数が使える
「インターポレーション（interpolation #{$変数名} ）」を使えば、要素名などでも変数が使えます。
で、どっちを使う？
自分は両方試してみた結果、SCSSを使っています。ミックスインでなく継承を使うことで、よりスッキリしたCSSが吐き出せるのが最大の理由です。
ちなみに、Googleトレンドでチェックしてみたらこんな感じでした（日本と米国、複合ワードで”CSS”を付けた）。この検索ワードが適切かどうかはわかりませんが。
