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だけでコンパイルできるあたりがちょっと悔しい。