Sassよりlessを選んだ理由

どちらもほとんど触ったことがないのだが、lessを選んだ理由は大きく2つ。

Sassよりlessが学習コストが少ないというネット情報(未確認)
Bootstrapがlessを採用している

eclipseでless

私の開発環境はeclipse+aptana pluginなので、これで何とか。aptanaにはSassのエディタがあるが、ここがポイントにならなかった理由は後ほど。
eclipseには幸いなことにEclipse plugin for LESSというプラグインがあり、軽快に編集可能らしい。
このプラグインの利用には、更にXtextというプラグインが必要。
インストール方法はいろんな方が紹介してくれていて、おそらくどれでも失敗なし。

なお、記事作成時のeclipseはluna。
Windows版はpreiades、mac版は素のeclipse。

Xtext インストール

プラグインのインストールはどれもほぼ同じ手順。
Help -> Install New SoftwareでWork withの右端のAddで下記URLを追加。

いくつかプラグインがあるが、追加するプラグインはXtextだけで問題ない。
インストール後はeclipseの再起動が必要。

Eclipse plugin for LESS

手順は同じで下記のURLを追加して、プラグインを追加する。

LESSを追加すればよい。
こちらも、インストール後は再起動を促される。

ちょっと注意点

以上でlessの編集環境が整うのだが、プラグインがエラーを吐いてびっくりしたので記載。
既存のCSSを利用した場合など、.lessファイル内に@importと通常のLESS構文があるとエラーが出るので要注意。

lessのコンパイルにはgulpを使う

lessのコンパイルは、プロダクト化の作業で行うパターンと、HTML送出時にjavascriptで行うパターンがある。コンパイルなしのlessの状態では確認できないため、いずれかの方法を選択することになる。これはSassも同じ。つまるところ、エディタがあろうがなかろうが、そのままではブラウザでは読めない点で、大差がない。

手軽なのは当然、javascriptでのコンパイルで、書きさえすればブラウザ上でcssになって適用される。
だが、ここで問題なのは**「lessを使えないコーダーの存在」**だ。lessのまま放置するとコードを共有できない。
プログラマはいいんだ。すぐわかる、less。すでに書きながらだいたい分かってきた。

というわけで、後でコンパイルしてもいいのだが、どうせならリアルタイムとまでは行かないまでも、保存時にコンパイルできたら便利だ。どうやらeclipseは、コンパイル用のlesscコマンドさえあれば実行モードでコンパイルができるらしい。できるらしい。

いや、わからなかった。久々にわからなかった、やり方が。
eclipseのターミナルから実行可能であれば、それほどウィンドウがとっちらかったりしないので良しとする。ので、ターミナルから起動可能なタスクランナーgulpを設定して保存時にコンパイルしている。
ちなみに、gruntを選択しなかったのはgulpのほうが新しいこと、githubの星の数が1.5倍ほどあること(2015-07-15現在)。
これで、lessのコンパイルだけじゃなくて、もろもろ作業もできる。

gulpのセットアップはいずれ。
なお、atomを使うとpluginだけでコンパイルできるあたりがちょっと悔しい。