なぜ Sass ではなく Stylus なのか

mimizuku

Mimizuku Advent Calendar 8日目の記事です。昨日に引き続き CSS に関する話題です。今日は Stylus について。

なぜ Sass ではなく Stylus なのか

これ最初にこの内容で書こうと決めたのって11月中旬くらいなのですが、正直いってもう全然覚えていません(終了

とはいえ最初に Stylus にしようと思ったきっかけは覚えています。きっかけはとろゆにさんの「Sass から Stylus に移行しようと本気で決意しました。」。ちょうど Sass 版 Basis で@extendの扱いに悩んでいるときでこれはええやん!と。結局今となっては Stylus の@extendを活かした書き方をしていないのでアレですが…。ということで、なぜ Stylus かというのは僕自身もうよくわからないので、実際に Stylus を使ってみてのメリットとかデメリットとかを書いてみたいと思います。

File globbing が超便利!

もうこれはまじで便利すぎます。File globbing って何かというと、@importするときにワイルドカードが使えるっていうものです。

最近は CSS もコンポーネント思考になってきてコンポーネントごとにファイルを分割して@importしましょうって流れじゃないですか。で、そのとき Sass だとワイルドカードが使えないので新しいコンポーネントをつくるたびに一々呼び出し元のファイルに@importを追記する必要があります。受託で1つのサイトを作る場合、コンポーネントはかなりの数になるので、この作業だけでもうんざりするぐらいめんどくさく思うことがあります。

そこで Stylus。Stylus はワイルドカードが使えるので、例えば呼び出し元で@import component/*みたいに書いておけば component ディレクトリにファイルを放り込むだけで勝手に import してくれるのです。追記の必要一切なし。すばらしい!

一応 Sass の場合でも gulp プラグインがあってワイルドカードが使えるようにすることもできるのですが、制約があったりドキュメントがあまり詳しくなかったりして断念したことがありました。Stylus のほうは特に考えずに使えたので素直さでみればメリットが大きいかなと。

と、絶賛していますが Stylus の File globbing もちゃんと読んでくれない場合があります。確かディレクトリ名と同名のファイル名が読まれないとかだったような…。もう詳しくは忘れてしましましたが'resolve url nocheck': trueにしないとダメで、またinclude css: false'じゃないとダメだった気がします(これは Stylus 本体の問題か Gulp プラグインの問題かまでは検証していません。あしからず…)。

プログラミング言語っぽく書ける

これは人によって違うと思いますが、僕は Stylus のほうがプログラミング言語っぽく書けるなという印象で、そのほうが僕的には書きやすいと感じます。例えば変数の定義も Sass だと

.foo {
    $width: 10px;
    width: $width;
}

のように普通のプロパティと似たような書き方でわかりにくいなぁと感じてしまうのですが、Stylus だともっとプログラミング言語っぽくかけます。

.foo {
    width = 10px;
    width: width;
}

変数以外にもifとかforとかの構文が Stylus のほうがプログラミング言語っぽくて好みです。

短く書ける

例えばミックスインを定義したり使うとき、Sass だと次のようになります。

@mixin foo() {
    width: 10px;
}
.foo {
    @include foo();
}

@mixin@include…めんどくさい! Basis をみてもらうとわかりますが僕はわりとミックスインを多用して楽したり仕組みを考えるのが好きです。だからこの@mixin@includeとかをたくさん書かなきゃいけないのが結構ストレスなんですよね。Stylus だと省略して次のように書けます。

foo() {
    width: 10px;
}
.foo {
    foo();
}

しかも Stylus では既存のプロパティと同名のミックスインを定義したり、既存のプロパティを使うときと同じ書き方でミックスインを include できるので、さも CSS を拡張したかのように書くこともできます。

position(position, top, right, bottom, left) {
    position: position;
    top: top;
    right: right;
    bottom: bottom;
    left: left;
}
.foo {
    position: absolute 10px 10px 0 0;
}

すばらしい!

ちなみに、普通の CSS の部分、コロンとか()とかも省略できます。

ヨーダ式だと正しく評価されない?

メリットを書いたのでデメリットも。前置きとして、僕は CSS プリプロセッサについては動けば良いというスタンスなので、おや?と思うことがあっても特に検証したり深追いしたりはしていません。ということでこれから書くデメリットも僕が間違っているのかもしれませんし、もしかしたら Sass でも似たようなバグがある場合があるかもしれません。なのでゆるーい感じで流し見くらいがちょうど良いかもしれません…^^;

まずヨーダ式です。ヨーダ式は if 文とか書くときに変数を右側に書く書き方のことです。例えばこんな感じ。

if ('absolute' == position) {
    ....
}

特にこだわりがあるわけではないのですが、最近はこれのほうが良いといわれている?っぽいのでなるべくこう書くようにしています。Stylus でもヨーダ式で書いていたんですけどなぜかうまく評価されないことがありました。で、逆にしたら普通に動くという…。なんで?

デバッグがめんどくさい

Sass には@debugという便利な機能があって、@debug $width;とかして現在変数の値が何かとかをコンソールに出力することができます。でも Stylus にはこの便利な機能が無いのです。似たものでwarnとかerrorがあるのですがどちらも引数の型が文字列型じゃないとダメで、もし数値なんかをわたしちゃうとそこで強制終了。10px とか #fff とかが入っているともうだめです。複数一気に流して値を確認したいとかがでいません。めんどくさすぎる!なのでcontent: widthみたいにしてデバッグしていますがいちいち CSS には書き出されるしごちゃごちゃになるしでデバッグは本当に困ります。

まとめ

ということで僕的メリット・デメリットを書いてみましたがいかがでしょうか?File globbing だけでも感動するほど便利だと思うんですけどねー。Sass に比べて開発が活発ではない?ような感じもあって、将来的な発展を考えると Sass のほうがやっぱり良いんじゃね?と思うこともありますが、Mimizuku も Basis も個人プロジェクトなのでなるべく自分が楽をできるものを使っていこうということで Stylus を使っている感じです。とはいいつつ、Mimizuku も Stylus 版 Basis も全く使われる気配が0なので、ひよってまた Sass に戻すことはあるかもしれません^^;

明日は Mimizuku からちょっとそれて Basis の CSS 設計について書こうと思います。ではではー

MW WP Form

MW WP Form はショートコードベースのフォームプラグインです。多くの機能を持っており、例えば、多くのバリデーションルール、問い合わせデータの保存、そしてグラフ機能集計などを使用することができます。

さらに詳しく
Habakiri

Habakiri

Bootstrap ベースのシンプルな WordPress テーマ。レスポンシブ、多くのカスタマイズ機能。圧縮された CSS・JS を使用する高速化対策。Microformats 対応。Sass、クラスベースの functions.php。

さらに詳しく
basis-stylus

Basis

軽量なレスポンシブ Stylus/CSS フレームワーク。Flexbox ベースのグリッドシステム、疎結合なコンポーネント、バーティカルリズム。

さらに詳しく