スタイリングライブラリをどう選ぶか Tailwind、Chakra、PandaCSS、Vanilla Extract…

いろんな選択肢がありますが、素のCSSを CSS Modules で書くのが良さそうというのが現状の結論です。

これからその理由を解説していきます。

CSS が十分進化している

まず1つ目。CSS 自体がどんどん進化しているという点です。

最近では、ネイティブの変数（--var）や Nesting、コンテナクエリ、カスケードレイヤーなど、

今までライブラリで補っていた機能が標準化されてきています。

そのため、あえて外部ライブラリに依存せずとも、

CSS そのものだけで十分戦える時代になっています。

ライブラリに依存せずとも便利に書いていけるなら、それが一番いいですよね。 HTML, CSS, JS で大規模で複雑なフロントエンド開発ができるようになれば、それが一番です。

その中でも CSS は、ライブラリに頼らずになんとかできる一番の候補な気がします。

また、素のCSSに慣れておいた方がライブラリが解決しようとしている課題の背景が分かるようになり、ライブラリを使った現場の時にもより深い理解を得て開発ができます。

型サポートについて

とはいえ、CSS Modules のままだと型補完が効かないため、開発体験としては物足りません。

現代のフロントエンド開発において型の恩恵が受けられないのは非常につらいです。

そこで導入するのが happy-css-modules

これを入れると

• 補完が効く
• コードジャンプで正確な定義元にいける
• 静的型チェックが効くため、CI などで自動で落とせる

CSS に型をつける上でのライブラリの比較はこのセクションが非常に分かりやすいです。

CSS in JS ライブラリがフィットする場面

もちろん、ライブラリを使うことで得られる恩恵もあります。

たとえば PandaCSS や Vanilla Extract のようなツールを使えば、デザイントークンを型で縛って「一貫したテーマ」を維持できます。

先に組織や要件的な面で Zero Runtime CSS in JS ライブラリがフィットしない場面を考えてみます。

• 要件的にそもそも事前にスタイルが build できない場面が多数あるプロダクトではフィットしません。事前にビルドしておいたトークンを使い回すという思想に反するので、綺麗にスタイルを書くことができなくなります。また、色数が豊富で局所的にスタイルが変わる箇所が頻発するようなプロダクトにも不向きです。これらのシナリオでは PandaCSS や Vanilla Extract の意図したところとは外れていくので、エスケイプハッチを多用することになり、メリットを感じにくくなります。
• CSS in JS ライブラリはそれぞれの書き方を学習するコストもそこそこあるので、メンバーが頻繁に入れ替わる組織や AI への学習といった観点でも大変になることが多いです
• MVP やモックですぐ動くものが欲しくて、作った後に一旦捨てて本開発の前にはある程度整える期間が設けられているプロダクトでは tailwind を使うのがいいでしょう
  • すでに採用事例や情報が豊富なため、AI のために基盤を整える必要がほとんどありません

逆に、どんな場面で CSS in JS ライブラリが活躍するかというと

• デザインシステムに対する理解がエンジニアはもちろん、それ以外の職種も込みで組織全体にあること。
• 一定の学習コストが発生するが、それをすぐにキャッチアップできること、また何かしらの Zero Runtime CSS in JS ライブラリを使った経験があり、背景や思想を理解できていること

このような組織では

• デザインシステムのための基盤を作る作業が高速
• variants, patterns といったよくあるスタイル定義方法が簡潔に書ける
• 何より、ビルド時に型を静的解析して CSS を生成してくれるため、スタイルの当て方のミスはほぼ0になる (素のCSS+型付与より厳密)

のでライブラリ側のメリットを受けて進められて、プロダクトのグロースが非常に高速になります。

まとめ

• CSS は進化しており、ライブラリ依存の必要性が減っている
• 型の恩恵を受けたい場合は happy-css-modules を導入
• 素の CSS 記法を扱うことで汎用スキルを身につけられる
• デザイントークンの強制はないが、その分柔軟性が高い

この構成で、まずは最小でシンプルな環境を整えましょう。