CSS Nite LP, Disk 26「CSS Preprocessor Shootout」でLESSについてのお話をしてきた。

当日の雰囲気や実況についてはハッシュタグを追っていただくとして、ちょっとだけプリプロセッサ選びについてのフォローアップをば。

CSSプリプロセッサはどれがいいの？

イベントのサブタイトルにもなっているCSS Preprocessor Shootoutの元ネタは、イベントページの冒頭でも紹介されている通り、Sass vs. LESS vs. Stylus: Preprocessor Shootoutという記事です。（英語ではありますが、この記事で基本的な文法は総ナメできます。）

CSSプリプロセッサの基本的な機能はどれも一緒で、それに+αの違いがある。それゆえに「どれがいいの？」というのを知りたい、というのがある反面、しゃべる側も、どれがベストという結論を強く押し出すのは難しかった。講演ではそれぞれの特長のお話なり、実際つかったときの経験談なり、注意点なり、またより深いところなど…という内容になった。

時間が限られていたことも含め、講演ではカバーしきれなかったツールの特長のようなところに触れつつ、Shootout(撃ち合い)ということもあり、僕個人としてひとつの結論を出してしまいましょう。

LESS

これからプリプロセッサはじめる人に勧めるならLESS。

なぜなら一番簡単だから。 そう宣言しつつも、以下必読。

まずは僕が講演で取り上げたわけだが、実もフタもないことをいってしまえば、Stylusの登場によって、LESSがSassと差をつけていたところがほぼ無くなっている、現状。 それはJavaScriptによる実装という点や、よりCSSに近い構文の簡潔さ、といったもの。

ただ唯一の特徴としてはクライアントサイドで実行できること。これは本当に手軽。しかし本番環境で使うのは基本的にはNG。ただちょいと補足すると、講演でもLESSファイルのコンパイルのコストがかかるため、と話はしたものの、実際には最初のコンパイル以後はCSSをlocalStorageに保存してキャッシュする。

とはいえど、初期の読み込みに時間もかかるわけですし、この機能が安定しているかどうかというのはわからない。（経験上、本番で基本的に使うことはないので）

なのでこのようにLESSについては深く語れば語るほど、機能として秀でた特長というのはなく、ただただシンプルであるということが特長となる。

今後はSassやStylusと大きな差をつけているExtendが実装されることで、世間的にはようやく横並びになるかもしれないが、それによってシンプルさというのも少し削られてしまうかもしれない。

なのでLESSが凌いで、LESSが圧倒的に支持をうけることは無いでしょう。これはLESSを徹底してマスターしていくべきかどうかの理由として、重要なことです。（のちほどのSassにおけるメリットとして詳細は書く）

こういった思いがあるゆえ、僕の講演でも、選択肢のひとつとしての可能性で締めさせていただいた。 しかし一方では、とりあえずCSSプリプロセッサを試したいという人には強くおすすめできる。それから他のツールにはいっていくのでも全然構わない。

Stylus

僕個人として使うならばStylus。

なぜならSassとLESSのいいとこ取りをしているから。

CSS（.styl）はLESSのように書けるし、SassのようなExtendもできる。透過的なMixinsも好み。

ただStylusを強くおすすめするかというと、難しい。その理由はStylusを使っている事例が、少なくとも日本（日本語）では少ないから。いくつかStylusを解説している記事もあるが、Sassと比べれば全然少ない。

それゆえに何かStylusのエラーなどにハマってしまった場合に、その解決策が見つかりにくい。なのでLESS/Sassをひと通り経験し、なおかつできればNode.jsに関連したツールを使っている経験があるような人の方が、問題なく使えそうなイメージはある。

またStylusセッションの終盤にあった通り、現在reworkというプロジェクトも走っているので、今後Stylusの立ち位置がどうなるかはわからない。 ※それでいうと、SassやLESSだってどうなるかはわからない。

Stylusはこのようにやや玄人好みであるといっても、他のプリプロセッサ同様のレベルで使う分には、Stylusからはじめても構わない。それが Ruby+gemではじめるのか、Node.js+npmではじめるのかの違いくらい。無論GUIのツールを使ったって構わない。が、Stylusに対応しているものはやや少ないので、GUIの選択肢は少し減るだろう。

Sass

総合的にみて、人に勧めるならば、Sass。

なぜなら、Sassについては機能的な言及はおいといて、単純に事例が多いから。

今回のイベントでもGREEさんやCookpadさんなどの大規模な事例もあれば、個人や中小レベルでの事例もある。そしてそれらのレベルではブログでもオープンに紹介されていることも多いし、日本語で解説された電子書籍だってある。

検索すればトラブルシューティングもできるし、Sassに関連する便利なツールなども多くある。その代表するのが先に紹介したCompass。サポートするGUIツールも多いから、とりあえず使いたいっていう人はそれらを使えばいい。

あくまでも勧めるならば、であり僕個人としては3つの中で一番好みではない。それはもう本当に好みのレベルの話で、メジャーじゃないものに手を出したい感もあるし、コンパイルが遅いと思っているからだ。 コンパイルの遅さの体感は人によって違うし、それぞれを比べるのは、iPhoneのキャリアを変えたときのSoftbank vs auの回線速度みたいなレベルだとも思う。

とはいえ仕事では基本的にSassを使う。なぜなら使える（使ったことがある）人が今の身の回りには多くて、引き継ぎや共通のライブラリをつくれるからだ。

まとめ

僕個人（というのは強調しておきたい）としては、

人に勧めるなら

1. Sass
2. Stylus
3. LESS

これからプリプロセッサはじめる人に勧めるなら

1. LESS
2. Sass
3. Stylus

僕が使うなら

1. Stylus
2. LESS
3. Sass

LESSの今後次第では、StylusじゃなくLESSになるかもしれないし、仕事でもLESSを推し進めていくかもしれない。（でもたぶんreworkに手を出す気もする）

でも結局CSSはCSS

イベントで数度繰り返していたが、CSSとしてちゃんと書けることがすべての前提。

料理だって、基本的な調理方法や下ごしらえ、またそのコツなどがそれなりに見についていれば美味しい料理ができる。

そこにすごく高機能な鍋なり、電子レンジなりの道具があれば、より美味しくつくれるかもしれないし、調理時間を短縮できてなおかつ美味しいものができるかもしれない。

逆に基礎がなくて便利な調理道具だけがあっても、それを使っても料理は上手くならないし、調理道具で事故を起こす可能性だってある。

（一方では、温めるだけで美味しい料理ができる、なんてものもあるが）

結局イベントと同じような結論で恐縮だが、

ちゃんとCSSを書け

それに尽きる。