☕️ SassやStylusなどのCSS Preprocessorはそろそろ卒業準備が必要かもしれない

Sassって、2006年からあるんですね。久しぶりにWikiを見てちょっとびっくりしました。jQueryと同い年なんですね。

Sassをはじめとした、Scss, Less, Stylus、CSSプリプロセッサでAwesomeな言語は現在当たり前のように使われていると思います。私も何かを作る時はSCSSを採用しています。

しかしながら、近年の動向を考えるとあまり固有の機能を使わない方が、長く開発を行う上で良いのではないかと思うようになりました。主たる理由は3点で、IEを捨てて良くなったこと、CSSの標準機能の強化によりCSSプリプロセッサの優位性があまりなくなってきたこと、もう一つは移植のリスクを減らすことです。

そもそも、SASSやSCSSをなぜ私たちは使ってるのでしょうか。

CSSプリプロセッサでやりたかったこと

ネスト

これが、SCSSを選ぶ最大の理由です。ただしこれは近いうちに解決するかもしれません。 CSS Nesting Module というものが草案として出されていて、およそやりたかったことはこれが実装されれば解決します。

なにより構文がほとんど同じであるため、移植が容易です。

変数

はい、変数は便利でした。しかし、今ではCSS Variablesが存在します。SASSなどの変数はプリプロセスで完全に定数に置き換わってしまうため動的ではありません。一方で、CSS Variableはローカルスコープで動作し、さらにJavaScriptから読み書きが可能です。

プリプロセス的に使われる変数にメリットはすでに大きくありません。 配列？知らない子ですね。

@mixin @include

便利ですが、CSSにそこまでの複雑性が必要かどうかは検討の余地があると見ています。この機能は、大量のCSSを効率的に集約管理するために使われることが多いと思いますが、Reactをはじめとするコンポーネントベースのコーディングが当たり前になり、スタイルの使い回しが必要なケースもそう多くはなくなってきました。

また、展開結果が予測できないのはよくない点の一つだと思います。

.my-style {
  @include my-box(2rem, transparent, 0px);
}

こんなコードを見て、どのように展開されるか予測がつくでしょうか。いえ、元のコードの問題なのは確かですが、比較的高めのコモンセンスが求められるため、このような低品質なコードが容易に作り得ます。いくらコードジャンプがあるとはいえ、そのまま書いた方が早いわ！となるのも時間の問題です。

@for @while @if @each などの制御構文

本当に必要ですか？

たまにこういうことをしたくなる時が来ることを否定しませんが、そういう場合よりベターな解決策としてCSS-in-JSを使ったり、styleアトリビュートに即時的に書き込んだ方が生産的なのではないかと思います。たかが数行節約するために、エディタがセレクタを参照できず開発効率やリファクタリング時に苦労する羽目になるのはごめんです。

@import

これは便利です。JSやバンドラー側でも解決可能です。標準がCSSになれば特に優位性もなくなるかもしれません。

演算機能

演算機能は非常に便利でしたが、CSSでもcalcが登場しました。静的に決まってしまうプリプロセッサ側のものよりも、CSSのcalcは柔軟性があり、パワフルです。従って、標準機能を使う方が理に適っています。

将来のパラダイムシフトに向けて

上記で挙げたように、実はほとんどの機能はもう使わなくても良いものが多いのです。また、エッセンシャルな機能は標準CSSに取り込まれた、ないしは今後取り込まれていく予定のものです。

これまで、新しい機能が開拓されては標準システムに組み込まれるという流れが、Webの世界では何度も起きました。当然これからも同じことが起きると思いますし、デフォルトとされる技術もどんどん変わっていくことと思います。そのために、今、そして将来、CSSのプリプロセッサを選ぶ時に大切にするべきなのは、 「標準的な仕組みをできる限り取り入れ、独自機能をなるべく使わず、メリットだけを享受する」 ことではないかと思います。

かつてのCoffeeScriptの勇姿に敬意を込めて。