Tailwindとvanilla-extractとPanda CSS

Tailwind

ユーティリティファーストを広めた第一人者

Pros.

シェアが一番大きい、フレームワークに導入する際のドキュメントも豊富

正規表現ベースなのでビルドシステムへの依存度が小さめ (次のバージョンで変わるかも？)

デザイントークンの強制がし易い

短縮表記が多く、ボイラープレートが少ない

Cons.

クラス名がクソ長になりがち

LSへの依存度高め、typoや表記ミスに気づきにくい

書き方が独特で、CSSを学んだ後に別途Tailwindの書き方を学ぶ必要がある

ゼロランタイムだがバリアントやスタイルのマージなどをしようとすると別のライブラリが必要で、それなりのサイズになりがち

vanilla-extract

ゼロランタイムのCSS-in-JS

Pros.

ビルド時に記述内容を直接評価しているので、ほぼなんでもできる

バリアント宣言などにもライブラリ内で対応している

CSSがファイルごと別々に作られるので、ビルド時の最適化はし易い

CSSをほぼJSにしただけなので、CSSで書ける記法はほとんど使える

TSの型付けが優秀

Cons.

シェアが小さく、ドキュメントになっていることが少ない

ビルドシステムへの依存度が非常に大きい、マイナーバージョンアップだけで壊れることもある

CSSがJSで書ける以上の機能はないので、リセットCSSやデザイントークンなどを整備したい場合は自分でやる必要がある

スタイル宣言とコンポーネントの部分を分ける必要があり、本質的ではないクラスの命名が必要になる

原理的にスタイルのマージが難しい

吐き出されるCSSがアトミックではないので、書き方によってはCSSの肥大化を引き起こす可能性が高い

Panda CSS

ビルド時生成 + 薄いランタイムの組み合わせによるCSS-in-JS

Pros.

ビルド時処理によってランタイムを薄くしつつ、ランタイムでスタイルマージやバリアントの仕組みを提供しているので低コストと利便性を両立している

CSSの書き方に寄せつつ、疑似セレクタやメディアクエリなど短縮表記が用意されている

デザイントークンなども用意でき、設定によってはそれの使用を強制することも可能

逆に自由に記述できるようにすることも可能

ビルドシステムへの依存は多少あるが、基本的にはPostCSSへの依存だけ

TSの型付けもある

CSSっぽく書くが、生成されるスタイルはアトミックなので、CSSの肥大化が起きづらい

Cons.

シェアはまだまだ小さい、ドキュメントも少なめ

ビルドシステムへの依存が小さいとはいえ、フレームワークによっては面倒な対応が必要になることもある

例) Qwik

公式のドキュメントが読みづらい(主観)

型付けが弱い、デザイントークンを使うのが大変、など

全くのゼロランタイムではない、というか普通にランタイムのビルドサイズは大きい

cascade layerにガッツリ依存しているので、cascade layerに非対応な古いブラウザだとそもそも動かない

Base line 2022のNewly Availableなので非対応なブラウザを切るという選択が取りづらい