第28章 Tailwind CSS への批判と評価
Tailwind は広く使われていますが、同時に強い批判も浴び続けてきました。この章では、Tailwind を擁護するのではなく、主要な批判をできるだけ強い形で提示し、それに対する反論を並べ、最後に公平な評価を下します。読者が「自分のプロジェクトでどうすべきか」を自分で判断できるようにするのが目的です。
28.1 批判①「HTML が汚い」
批判の主張: Tailwind の最大の批判はこれです。class="inline-flex items-center rounded-md bg-blue-600 px-4 py-2 ..." のようにクラスが大量に並んだ HTML は、読みにくく、醜く、保守しづらい。要素の構造がクラスの洪水に埋もれて見えなくなる、というものです。これは見た目の好みの問題に留まらず、「ぱっと見て構造を把握できない」という実害を伴います。
反論: 第3章で見たとおり、これはトレードオフだという立場です。HTML が「にぎやか」になる代わりに、CSS ファイルの肥大化・命名・詳細度の戦いから解放される。そして、繰り返し現れる長いクラス列はコンポーネント化すれば、それが見えるのは定義の 1 か所だけになる（第6部）。
評価: この批判には、正当な部分があります。コンポーネント化の仕組みがない環境（生の HTML を手で量産するなど）では、「醜い HTML」は実害のある負債になります。一方、React や Rails の ViewComponent のように抽出手段が整った環境では、痛みは大きく緩和されます。つまりこの批判の妥当性は、プロジェクトの構成に依存する、というのが公平な見方です。「コンポーネント化できる環境かどうか」が分かれ目です。
28.2 批判②「インラインスタイルと同じでは」
批判の主張: クラスで見た目を直接指定するなら、style 属性に書くインラインスタイルと本質的に同じで、CSS の進歩を巻き戻しているだけだ、というものです。
反論: 第3章で見たとおり、style 属性だけでは :hover や @media を直接書けません。Tailwind はバリアントでこれらを扱えます。また、テーマの値をクラスで選べるので、規約に沿ったスタイルを組み立てやすくなります。
評価: 状態とメディアクエリを同じクラス記法で扱える点は、インラインスタイルとの明確な違いです。一方、インラインスタイルでも color: var(--color-brand) のようにトークンを使えます。一貫性は Tailwind だけの性質ではなく、どちらも規約と運用に依存します。任意の値を無秩序に散らす問題は Tailwind でも起こります（第27章）。
28.3 批判③「関心の分離に反する」
批判の主張: HTML（構造）と CSS（見た目）は分離すべきであり、見た目を HTML に書き込む Tailwind は、長年確立されてきた「関心の分離」の原則に反する、というものです。これは最も思想的で根深い論争です。
反論: Adam Wathan の主張（第2章）は、「分けるべきは HTML と CSS ではなく、再利用できるものとできないものだ」という関心の分離の再定義でした。.hero-title のようなクラスは、ファイルが分かれていても HTML の構造に CSS が依存しており、本当の意味では分離していない、と。
評価: ここはどちらが正しいと断定できない、価値観の対立です。「構造と表現の分離」を重んじる立場からは Tailwind は退歩に見え、「再利用性と変更容易性」を重んじる立場からは前進に見えます。重要なのは、これが技術的な優劣ではなく、何を重視するかの選択だと理解することです。本書は Tailwind を解説する本ですが、セマンティックな CSS（BEM など）の思想にも合理性があることは、公平に認めるべきです。
28.4 批判④「学習コスト」
批判の主張: 既存の CSS 知識があっても、Tailwind 独自のクラス名（flex はともかく shrink-0・inset-0・tracking-tight など）を新たに覚える必要があり、学習コストが高い。CSS を知っていれば素の CSS の方が早い、というものです。
反論: クラス名の多くは CSS プロパティの短縮形であり（第15章・第16章の対応表）、エディタの補完（第9章）があれば暗記は不要。一度慣れれば、命名やファイル往復が消える分むしろ速い、という反論です。
評価: 習熟期間や効果は、CSS の経験、エディタ環境、チームの規約によって変わります。「数週間で慣れる」「長期なら必ず速くなる」とは一律に言えません。小さな画面で試し、実装時間だけでなくレビューや変更にかかる時間も比較して、立ち上がりの費用に見合うかを判断するのがよいでしょう。
28.5 批判⑤「ロックインと移植性」
批判の主張: HTML が Tailwind のクラスで埋め尽くされると、後から Tailwind をやめるのが極めて困難になる。特定のツールにロックインされ、移植性が下がる、というものです。
反論: ユーティリティは結局ただの CSS クラスであり、最終的な生成物は標準的な CSS と HTML です。また、これは Tailwind 固有の問題ではなく、CSS-in-JS でも独自の命名規則でも、何らかの方式を採用すれば程度の差こそあれ移行コストは生じる、という反論です。
評価: この批判には現実的な重みがあります。Tailwind をやめる場合、HTML に散らばったクラスを別の方式へ移すのは大仕事です。ただし「移行が大変」なのはどんな CSS 方針でも同じで、Tailwind だけが特別に悪いわけではありません。公平に言えば、「採用は容易だが撤退は重い」という性質を理解したうえで選ぶべき、ということになります。導入前に「このプロジェクトで Tailwind を長く使い続ける見込みがあるか」を考えるのが賢明です。
28.6 計測できる効果の実態
主観的な論争だけでなく、計測しやすい効果も見ておきましょう。
- CSS サイズ: 第3章・第4章で見たとおり、既出のユーティリティを再利用するだけなら CSS は増えません。ただし新しい任意の値やバリアントを使えば増えます。採用前後で本番 CSS の圧縮後サイズを比較できます。
- 変更容易性: 「この CSS を消すと何が壊れるか分からない」という恐怖（第1章）が小さくなります。ユーティリティは局所的で、他へ波及しないからです。
- 開発速度: 命名やファイル往復の削減は速度向上につながり得ますが、効果は実測が必要です。同程度の変更作業にかかる時間をチーム内で比較します。
これらは仕組みから期待できる効果と、その測定方法です。規模・寿命・チームによって結果は変わります。小さく短命なサイトでは新規導入や学習の費用を回収しにくい場合がありますが、すでに Tailwind に慣れ、構成も用意されていれば、小規模でも利点を得られます。
28.7 結論: 向くプロジェクト・向かないプロジェクト
公平な評価を踏まえた結論です。
向いている:
- 中〜大規模で、長く保守されるアプリケーション。
- React / Vue や Rails の ViewComponent など、コンポーネント化の手段がある環境。
- デザインの一貫性をチームで仕組みとして担保したい場合。
慎重になるべき:
- ごく小さく短命で、新たな導入・学習の費用が効果を上回る静的ページ。
- コンポーネント化の仕組みがなく、長いクラス列を手でコピーし続ける環境。
- チームが強くセマンティック CSS の思想を支持しており、その合意がある場合（無理に変える必要はない）。
Tailwind は「あらゆる場面で最善」ではありません。強みと弱みを理解し、プロジェクトの性質と照らして選ぶべき道具です。具体的な採用判断のチェックリストは、次の第8部・第31章にまとめます。