全体のドキュメント構造を表すHTMLと全体のスタイルを表すCSSを別々に管理する古典的手法が誤った関心の分離であることには同意するが、だからといってTailwind CSSがやっているようなものは好きになれない。

（ここでは簡単のため仮想DOMの是非については述べず、HTMLとJSXなどを区別しない。それは本題ではない。）

まず、私はコンポーネント指向での設計はよいものだと思っている。Webページをコンポーネントの集まりとして捉え、各コンポーネントがそれぞれでHTMLとCSS（そしてJavaScript）を持つというのは、より本質的でよい関心の分離であると考える。開発者と利用者が実際に関心を持っているのは常にコンポーネントであり、その実装言語などではないはずだ。（例えばスタイルのおかしな部分があったとして、それは「この部分のスタイルがおかしい」であって「スタイルのうちのこれがこの部分でおかしい」ではないはずだ。）この考えは同時に、HTMLが全体のドキュメント構造を表したり、CSSが全体のスタイルを表したりするものが好きになれないということにも繋がる。HugoなどのHTMLテンプレートエンジンがこれに含まれる。

しかしこれは、HTMLにインラインでCSSを書いてスタイルを定義したり、HTMLのクラス名としてCSSを書いたりすることを好ましく思うことと同義ではない。Tailwind CSSは好きではない。なぜなら不要だと思うから。前述した古典的手法、つまり「それがHTMLであるかCSSであるか」によってのみ分離することは誤った関心の分離だと思うが、だからといってコンポーネント内でその両者が同じ文脈で書ける必要はないと思っている。コンポーネント内であればHTMLとCSSは分かれていていい。Vue SFCやSvelteがやっているようなもの、もしくはCSS Modulesでいい。これに尽きる。

よくTailwind CSSのメリットとして、スタイルに一貫性を持たせられることが挙げられているように思う。しかし一貫性を持たせる方法なんてものは他にもいくらでもあって、その中にはCSS変数もある。CSSが標準としてサポートしている方法だ。

また、記述量が減ることもメリットらしいが、モダンな開発環境であればエディタの言語サポート機能によって記述量なんてどうとでもなる。むしろ大量のクラスが横並びになる状況と従来のCSSではどちらのほうが読み書きしやすいだろうか。

メディアクエリが書き易いという意見もある。（そしてこれをインラインCSSとの差別化ポイントであるとして、Tailwind CSSを擁護するものがある。）しかしこれこそCSS Modulesでいいはずだ。ある特定のメディアクエリが使いたいとき、クラス名としていちいちmx:なんていう接頭辞を付ける必要は、CSS Modulesではない。可読性もそちらの方が高いだろう。

なお、Tailwind CSSで書いたスタイルの再利用性が低いとの批判は、私は本質的ではないように思っている。再利用するのはコンポーネントで、スタイルではない（し、クラス名でもない）。同じスタイルを使わないといけない場面とは、同じコンポーネントを使わないといけない場面だ。

ではなぜTailwind CSSが流行っている（もしくは流行っていた）のか。きっとこれには従来のBEM命名法にあった面倒が関わっていると思う。つまり、「セレクターの詳細度を常に意識して、一意でわかりやすい名前によって名前空間を分けなければならないストレス」があったのだろうと思う。けれどこれはCSS Modulesが解決した。コンポーネントごとに機械的に名前空間は分けられる。ならCSS Modulesで構わない。

Tailwind CSSの、CSS ModulesやCSS変数に対する優位性がわからない。少なくとも今はまだ。いつかわかる日が来るかもしれないが、少なくともそれはTailwind CSSのよさについて説き伏せられたときだろう。