UIデザイン・生成AIとの関係を交えながら「Tailwind CSS」について考察する
タイトルにもありますが、今回はUIデザインと生成AIとの関係からTailwind CSS(ユーティリティクラスを主に使用するCSSフレームワーク)について考えていこうと思います。
今更Tailwind CSSの話をするのか?と考える方もいらっしゃるかもしれませんが、スタイリングのデファクトスタンダードになり落ち着いてきた雰囲気がある今こそ、再考する時期かもしれません。
本記事では、あくまでTailwind CSSを多角的に観察し考える事が目的の為、具体的な導入方法やプロパティにはそこまで言及しないです。
ご了承ください🙏
📍今回の総論
考えていることをそのまま記事にしたら、かなり長い文章になってしまいました。
その為、先に本記事で結局何を言いたいのか書き起こしておきます。
- LLMとスタイリングの動向および、Tailwind CSSの動向を今後も注視していきたい
- UIデザインとTailwind CSSがどのように関係しているのかについて考えたい
- Tailwind CSSという技術に対する、デザイナーとエンジニアの認識の違いも意識していきたい
結局〇〇が正という絶対解は出せませんが、LLMの発展とUIデザインの進化および複雑化している状況下において、Tailwind CSSが今後どうなっていくのかについて注視していきたいというのが今回の総論になります。
具体的にどのような考えなのかに興味がある方は、以下の章も読んでいいただけると嬉しいです😌
📍Tailwind CSSについて
Tailwind CSSは、現代のウェブ開発において急速に普及しているオープンソースのCSSフレームワークです。従来のフレームワークとは異なる「ユーティリティファースト」の設計思想を特徴としており、効率的で迅速なスタイリングを実現します。
Tailwind CSSがCSSのデファクトスタンダードになりつつある現状
Tailwind CSSのGitHubリポジトリは、その人気と開発者コミュニティにおける広範な採用を示す顕著な指標として、非常に多くのスターを獲得しています。2025年3月現在、その数は86.4kに達しています。これは、Tailwind CSSが多くの開発者にとって価値のあるツールとして認識され、支持されていることを表しているかと思います。
リポジトリの詳細情報からも、年間を通じて活発なコミット活動が行われていることが確認でき、その成長が継続していることが伺えます。Tailwind Labsが開発する他の関連プロジェクト、例えばHeadless UIやPrettier Plugin for Tailwind CSSなども、非常に多くのスターを獲得しており、Tailwind CSSのエコシステム全体の強固さを裏付けています。
📍Tailwind CSSの特徴
🧷設計コンセプト
Tailwind CSSの中核となる設計コンセプトは、ユーティリティファーストであるということです。
ユーティリティファーストとは、ユーティリティクラスと呼ばれる個々のCSSプロパティに対応した細かなクラスの事をいいます。
Tailwind CSSは、標準で豊富なユーティリティクラスを保持しており、開発者はそのクラスをHTML(JSXなども含む)コードのclass属性部分に記述することで、直感的にスタイリングすることができます。
また、準備されたユーティリティクラスを使用することで、協業者間・プロジェクト内で、スタイルに関する共通認識を持つことができ一貫したデザインを簡単に実現することができます。
以下はユーティリティクラスの使用例になります。
className=部分に記述されている、inline-flex items-center
など一つ一つがユーティリティクラスです。
import React from 'react';
interface ButtonProps {
children?: React.ReactNode;
className?: string;
onClick?: () => void;
}
const Button: React.FC<ButtonProps> = ({
children = 'ボタン',
className,
onClick,
}) => {
return (
<button
className={`inline-flex items-center justify-center rounded font-medium transition-colors bg-blue-600 text-white hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2 px-4 py-2 ${className || ''}`}
onClick={onClick}
>
{children}
</button>
);
};
export default Button;
🧷主な特徴
豊富なユーティリティクラス
前述したようにTailwind CSSは豊富なユーティリティクラスを有しています。これらを組み合わせることで、複雑なレスポンシブデザインやインタラクティブなUIを直感的・効率的に構築できます。
- レイアウト、スペーシング、タイポグラフィ、色、Flexbox、Gridなど広範囲を網羅
- レスポンシブバリアント(sm, md, lg)や状態バリアント(hover, focus)など多彩なバリエーション
- ダークモード(dark)などのテーマ用のバリアントも存在
- tailwind.config.tsでスタイルのカスタマイズが可能
JIT(Just-In-Time)
Tailwind CSSの主な特徴の一つに、Just-In-Time (JIT) コンパイラの採用が挙げられます。JITとは以下の特徴を持つコンパイラ技術です。
- 必要なユーティリティクラスのみをオンデマンドで生成
- ビルド速度向上、CSSファイルの軽量化
- 柔軟なデザイン対応(任意の値が設定可能)
このJITにより、開発者はTailwind CSSの使用によるバンドルサイズの重さやパフォーマンスに関する懸念をせずともよくなったと思います。
Tailwind CSSバージョン3以降では、このJITコンパイラがデフォルトで有効になっています。
充実したエコシステム
そして、Tailwind CSSは、大規模で活発なエコシステムを誇っています。
- 公式ドキュメントが見やすくチュートリアルも豊富
- PlayGroundが存在する
- 関連プロダクトが多数
- TailwindUI
- HeadlessUI
- shadcn ui
- Next.js など
🧷従来のCSSフレームワークとの比較
特徴 | 従来のCSSフレームワーク (例: Bootstrap, Material UI) | Tailwind CSS |
---|---|---|
スタイリングのアプローチ | コンポーネントベース | ユーティリティファースト |
抽象化のレベル | 高い | 低い (プロパティレベル) |
カスタマイズ性 | 限定的 (オーバーライドが必要) | 非常に高い |
デフォルトコンポーネント | あり | なし |
CSSファイルサイズ (初期) | 大きい | 小さい (JITコンパイラによりさらに最適化) |
学習曲線 | 基本的なコンポーネントは比較的容易 | ユーティリティクラスの習得に時間を要する |
主な用途 | 標準的なデザインでの迅速なプロトタイピング | 独自のカスタムデザイン、パフォーマンス最適化 |
📍契約と制約(メリット/デメリット)
ユーティリティクラスを多用するTailwind CSSには、多くのメリットがある一方で、いくつかの制約やデメリットも存在します。
メリット | デメリット |
---|---|
開発速度の向上(HTML内で即時スタイリング可能) | 学習コストが高め(多数のクラスを覚える必要) |
クラス名を考える手間が不要 | HTMLが冗長になる可能性 |
デザインの一貫性を容易に維持 | 可読性が下がる場合がある |
高いカスタマイズ性 | 過剰なクラス使用によるメンテナンスの難しさ |
レスポンシブ対応が容易 | ビルドプロセス導入の必要性 |
CSSファイルが軽量化 | インラインスタイルに似た課題を抱える可能性 |
チーム開発が円滑になる | 動的スタイルの実装が複雑になる場合がある |
デザイン自由度が高い | Tailwind CSSへの依存(ベンダーロックイン)のリスク |
保守性向上(グローバルCSSの影響を受けにくい) | 基礎的なCSS知識習得の妨げになる可能性 |
Vanilla CSS[1]より自由度が落ちる |
上記でデメリットを挙げましたが、使用して見ないと感じづらい部分もあると思うので個人的には一度使用されてみる事をオススメします。「学習コスト」や「可読性の低下」、「HTMLが冗長になる点」などは正直慣れれば気にならなくなる気がしますし、他のユーティリティクラスを有するフレームワークにも言える事だと思います。
ただ、ここで気にすべき点は主に以下2点かなと思います。
- 基礎的なCSS知識習得の妨げになる可能性
- Vanilla CSSより自由度が落ちる
🧷基礎的なCSS知識習得の妨げになる可能性
Tailwind CSSが直感的に使える故に、他のフレームワークやVanilla CSSでのスタイリングのハードルが上がる可能性がありますし、Vanilla CSSまともに触ったことないけど、いきなりTailwind CSSを使う場合は、学習ハードルが上がる可能性もあります。(個人差あります)
生成AIを使ってコーディングをしていて、まともにスタイリングを学習したことがないと、自分の理想のデザインを実現することが難しい可能性もあります。そんな時にTailwind CSSやVanilla CSSへの深い理解が求められる気がします。
ただ人によっては、Tailwind CSSを深く理解する為に、Vanilla CSSを学習する機会も増える気がしますし、必ずしもTailwind CSSを否定する理由にはならないとは思います。
🧷Vanilla CSSより自由度が落ちる
また、本章の見出しに「契約と制約」とあるように、Tailwind CSSは、用意されているユーティリティクラスを使用してスタイリングするユーティリティファーストなCSSフレームワークです。
// 自由度
Vanilla CSS > CSSフレームワーク(Tailwind CSS) > UIコンポーネントライブラリ(MUI・shadcn uiなど)
上記はあくまで個人の意見です
いくら豊富なユーティリティクラスが用意されているとはいえ、やはりVanilla CSSよりは自由度という点で劣ります。
自由度という点と引き換えに、一貫性と効率性を上げているのが、Tailwind CSSです。とはいえ大体のデザインは実現できますが、本当に凝ったアニメーションやグラフィックを表現したい時は、Vanilla CSSやCCS In JSなど他のスタイリング手法をとった方が実現難易度が下がる可能性があります。
ただしこの課題はTailwind CSSをどれくらい理解・使いこなしているかにも依存します。
以下スタイリング自由度の図ですが、Tailwind CSSはユーティリティファーストである為、「Vanilla CSSよりはスタイリングの自由度は下がるけれど、MUIなどのスタイルも定義されているコンポーネントと比べると、カスタマイズの余地がある」そんな立ち位置かと思います。
📍日本/海外での具体的な使用例
🧷国内外で好まれるデザインの違い
Tailwind CSSの使用例を見る前に、日本国内外の好まれるデザインの違いを頭に入れたいところです。
前提として、地域で完璧にデザインの趣向を区別することは難しいです。なぜなら、同じ地域の中でも10人いれば10通り〜それ以上の趣味嗜好がある為です。しかし巷でよく言われるのは、以下の違いかなと思います。
- 日本のウェブデザインは情報量が多く、細部にまでこだわった表現が好まれる傾向がある。
- 海外、特に欧米のデザインは、よりシンプルでミニマルなアプローチが好まれる傾向がある。
🧷国内の具体例(どんな有名なサイト/アプリで使用されてるか)
日本国内においては、Tailwind CSSがいくつかのウェブサイトやアプリケーションで採用されています。具体例としては、以下のサイトが挙げられます。
Felo ai ホーム画面
note ホーム画面
近畿大学 コロナ時期のページ
🧷海外の具体例(どんな有名なサイト/アプリで使用されてるか)
海外においては、Tailwind CSSが多くの著名なウェブサイトやアプリケーションで採用されています。具体例としては、以下のサイトが挙げられます。
OpenAI ホーム画面
Shopyfy ホーム画面
🧷国内外の使用例を受けて、どんな時に使用できるか
上記の国内外の使用例やTailwind CSSの持つ特徴を踏まえると、このフレームワークは以下のようなUIを表現する際に特に有効であると考えられます。
- レスポンシブでモダンなレイアウト
- クリーンでミニマルなインターフェース
- 高度にカスタマイズされた独自デザイン
- 一貫したデザイン及びデザインシステム構築
- 迅速なプロトタイピングやMVP開発
国内外の例は上記以外もあると思いますが、自分が見た限りでは、モダンでシンプルなサイトが多い印象でした。アニメーションも併用しているサイトもありましたが、同じ形のオブジェクトを反復したり、しっかり一貫性・UIにある一定の法則があるサイトが多い気がします。
それは、Tailwind CSSが持つ一貫性故な部分も大きく影響していると思います。
📍生成AIとTailwind CSSの相性
🧷生成AIとTailwind CSSの相性は?
近年、大規模言語モデル(LLM)を有し、自然言語でのやり取りに優れた生成AIと呼ばれる技術が非常に注目を集めています。
特に、生成AIを活用したコーディング能力は凄まじく、まだ不完全な部分はあるものの、大企業でも活用事例が公表されるなど一部の企業から導入し始めているような状況です。このような状況において、Tailwind CSSの持つ特性は、生成AIとの相性の良さにより、生成AIコーディングをさらに効率的・生産的なものにしています。
本記事の最初で言及したように、Tailwind CSSのユーティリティファーストという設計思想は、一貫性のある予測可能なクラス命名規則に基づいています。
例えば、「青色の背景、白い文字、角丸のボタン」というデザイン要件があった場合、Tailwind CSSでは以下のようにclassNameにbg-blue-500 text-white rounded-lg py-2 px-4
を付与すれば実現できます。
const button = () => {
return (
<button
className=bg-blue-500 text-white rounded-lg py-2 px-4>
ボタン
</button>
)
}
このようにTailwind CSSでは、具体的なクラス名にスタイルが直接対応します。
その為、生成AIが大量のTailwind CSSのコードで学習することで、このようなデザイン要件とそれに対応するユーティリティクラスのパターンを学習し、自然言語による指示から適切なスタイリングを行うことができるようになっていると思います。
BEM等の設計手法を必要とするVanilla CSSの場合、ユーティリティクラスよりも圧倒的に自由で複雑なので、生成AIにとってはTailwind CSSの方が好まれそうです。
また少し脱線しますが、近年のWebサイトの複雑化により、CSSはそれ自体がより論理的に、言い換えるとプログラミング言語の論理的な考え方をより取り入れている気がします。
Tailwind CSSはVanilla CSSよりもさらに論理的にスタイリングを行う印象が受けます。論理的という事は、自然言語で説明しやすいとも言い替えることが出来るので、この論理的な点が、生成AIとの相性の良さに寄与しているかも知れません。
ただし、Tailwind CSSではHTMLが冗長になる傾向があるため、生成AIを使用して効率的かつ構造化されたHTMLを生成できるかどうかが重要なポイントとなります。この点は、LLMモデルの進化や開発者の技量なども多大に影響するのではないかと思います。
📍結論
Tailwind CSSは、ユーティリティファーストという斬新なコンセプトや優れた特徴に基づき、近年のフロントエンド開発において、スタンダードになりつつあります。
一方で、学習コストやHTMLの冗長化といった課題も存在しますが、適切な知識とベストプラクティス(コンポーネント化など)を適用することで、これらのデメリットを軽減することが可能です。
今後の展望として、生成AIを活用したコーディングが普及していく中で、Tailwind CSSのような明確な構造を持つフレームワークは、生成AIによるコーティンのスタンダードになるかもしれません(既になっているかもしれないです)。
これにより、ウェブ開発はさらに加速し、より多くの人々が自身のアイデアをウェブ上で表現できるようになるかもしれません。
だだ、少なくとも生成AIによるコーディングが不完全な間は、開発者自らがコードを理解する必要性があると思います。理想のスタイリングを実現するために、開発者も必要に応じてTailwind CSS及びVanilla CSSのキャッチアップを行っていきましょう。
📍参考資料
Tailwind CSS 公式サイト
Tailwind CSS GitHubリポジトリ
Tailwind CSS実践入門
-
フレームワークもライブラリも介していない、素のCSSのことです。 ↩︎
Discussion
こんにちは!現在、私はTailwindCSSを使用した大規模なプロジェクトをサポートしているので、このフレームワークのいくつかの特徴についてお話ししたいと思います。初心者の開発者には、やはり通常のCSSを深く学び、BEM記法を使ってクラスをモジュールに論理的に分割することを提案したいです。これはページやアプリケーションをコンポーネントに分割する際にもうまく機能しますし、最近の多くのフレームワークでは、各コンポーネントにスタイルの閉じた領域を作る機能(たとえば、Vueのscopedなど)があります。あなたがすでに指摘したデメリットとしては、1つのベンダーに依存してしまうことや、レイアウトが損なわれることがあります。特に後者はQAの作業を大きく困難にします。なぜなら、「Tailwind以外のクラスは使わない」というルールが無効になり、ページ内で目印となるダミークラスを追加しなければならなくなったり、QAがテストでクラスのグループに依存することになり、どちらも良くない選択です。テストは、スタイルが少し変更されただけで壊れることがあります。また、コードを書く時間は少なく、読む時間の方が圧倒的に多いですよね。ここでもTailwindは助けになりません。なぜなら、理解しやすい論理的なブロックの代わりに、レイアウトとクラスが混沌とした、読みづらい塊になることがあります。あるいは、レイアウト用に普通のクラスを作り、
@apply
(Tailwindの開発者自身が推奨していない、笑)を使ってTailwindクラスを追加する…普通のCSSクラスの代わりに。つまり、これでは本末転倒です。ここでは例として、TailwindとCSS+BEM記法を使用した2つのブロックを示します。あなたがプロジェクトを知らず、すぐにその見た目や内容を理解する必要があるとします。どちらがあなたにとって読みやすいですか?
TailwindCSS
CSS + BEM
確かに、Tailwindのコードはコンポーネントに分割できるかもしれませんが、そうしていないプロジェクトに出会うことがよくあります。さらに「楽しい」ことに、1つのファイルに全ページが詰め込まれ、300行以上のマークアップで構成され、その全てがTailwindの混沌とした塊になっている場合もあります。
だから、注意してください。Vanilla CSSやSCSSで作られたサイトをTailwindに簡単に移行できますが、その後のメンテナンスや元に戻すことが非常に難しくなります。
小さなプロジェクトや、急いで作る必要があってその後ほとんど触らない可能性が高いページであれば、確かにTailwindは良い選択肢です。
Val Savenさん
コメントありがとうございます!
本記事ではTailwind CSSに焦点を当てていますが、私個人としても、Tailwind CSSが絶対的にいいとは思っていません。したがって頂いたコメントには概ね同意します。
私自身、普段業務ではSass+BEMやVanilla CSS + BEMで書くこともかなりありますし、Vanilla CSSへの理解⇒ Tailwind CSSという風に学習している身なので、やはり先にVanilla CSSを学んだ方が様々な要因からいいと思います。
@applyディレクティブに関しても、Tailwind CSSのコンセプトに割と反対的な機能ですし、Tailwind CSSの設計者自身も使用を推奨はしていないです。従って緊急時以外は、使うべきでは無いと思いますし、頻繁に使う必要があるならば、そのプロジェクトはTailwind CSSに適していない気もします。
QAの観点やプロジェクト参画時に、スタイル含めコードが見づらく、理解に時間がかかる事も確かに懸念されます。
ただこの点に関しては、いくつか同時に考慮してもいい部分があるとは思います。
・私自身やコメントしてくれたVal SavenさんはVanilla CSSやBEMに既に馴染みがある。その為Vanilla CSS + BEMの方が理解しやすいと感じてしまう主観も入っている可能性。
・Tailwind CSSと生成AIとの相性の良さにより、今後細かいメンテナンス作業やプロジェクト参画時のスタイル含めコード理解が自然言語だけでできるようになっていく可能性。(現在はまだ完全では無いです…)
Tailwindからの移行が難しい点もその通りだとは思っていて、去年や一昨年に技術的負債問題としてよく取り上げられていました。
ただこの点に関してもLLMモデルの進化によって効率化されていく可能性はあると思います。半分願望みたいなものですが…
このようにVal Savenさんがおっしゃった事にはすごく共感できます。
ただTailwind CSSがかなり使われているフレームワークであることは事実で、生成AIとの相性もいい気がしています。主観ですが。
この場合、将来的にスタイリングという分野をどのように生成AIが実行していくのか?スタイリングをする手法としてユーティリティクラスがより多用されていくことになるのでは無いかと思いました。
願わくば現状Tailwind CSSが抱えているとされる課題が生成AIによって緩和・解決されていくといいなと思います。
sakuさん、ご返信ありがとうございます!
VanillaCSS + BEMに慣れている私たちにとってそれが簡単だと感じるというご意見、とても興味深いですね。これまであまりその視点で考えたことがありませんでした。
LLMやAIにとっては、HTMLとTailwindが一箇所にまとまっている方が扱いやすいというのはその通りですね。私もそう思います。また、AIがさらに進化すれば、レイアウトのブロック全体を更新のために渡して、迅速かつ高品質に処理できる可能性があるという点にも同意します。
私が言いたかったのは、ウェブ開発を学ぶときは基本から始めるのが大事だということです。例えば、JavaScriptを全く知らないままReactやVueを学び始めると、後で仕事での理解不足やセキュリティの問題につながることがあります。それと同じように、Tailwindを使って最初のサイトを作っている人たちが、その仕組みをしっかり理解していないケースをよく見かけますね。
@apply
について、私たち二人がその点を強調したのは素晴らしいと思います。残念ながら、次のようなコードを結構頻繁に見かけるんです:TailwindCSSの作者自身がツイートで、「@applyはただのトリックで、Tailwindに移行しやすくするためのマーケティング的な仕掛けにすぎない」と言っていますね。
QAについて、私の考えがうまく伝わっていなかったかもしれませんね。私が言いたかったのは、テスターは通常、特定の要素をidやclassを使って特定するということです。例えば、自動テストで特定のフィールドや入力欄のテキストが正しいかを確認する際に、 #submit-button や .user__firstname / .user__lastname のようなものがあるとやりやすいんです。
それと、LLMにとって便利なものが人間にとって不便にならないように注意することが大事だと思います。ここで機械語とのアナロジーが使えるかもしれません。コンピュータにとっては0と1が理解しやすいですが、人間にとってはアセンブラを使うのも難しいですし、特に若い開発者や現代の初心者にとってC言語や手動でのメモリ管理を理解するのはさらにハードルが高いでしょうねw。だって、高級言語やコンパイラ、インタプリタがあるおかげで、そういう低レベルの知識がなくても開発できるようになっているんですから。Tailwindはまるで機械語みたいです。素早く書けて、すべてが1箇所にまとまっていますが、後で読むのが難しいんです。
そういえば、2つの深刻な問題についても触れておくのを忘れそうになりました。
デザイナーがTailwindのシステム的なアプローチをサポートしていない場合、いろんな問題にぶつかる可能性があります。その場合、tailwind.configファイルで新しい値を追加するか、
text-[40px] font-semibold leading-[48px] tracking-[-.8px] m-0 sm:m-auto rounded-ui-modalDialog pt-11 max-h-[calc(100%-96px)] max-w-full sm:max-w-[calc(100%-96px)] !px-8
のようなコードを書くはめになりますね(これも実際の例です、はい)。BEM記法だと、
margin: 2rem
をmargin: 1rem
に簡単に置き換えられるモディファイアが使えます。でも、Tailwindでは「数が大きい方が優先」というルールがあるので、要素にすでにm-8
クラスがついている場合、m-4
を後から追加しても効きません。その結果、それぞれのクラスを明示的に指定しないといけなくなります(つまり、本来CSSで済むロジックをJSで繰り返すことになります)。例えば:
Val Savenさん
コメントありがとうございます!
自分もウェブ開発をしていく中で、より基本が重要だなと考えさせられます。JSとJSフレームワークの例も個人的に実感したことなのでとても共感できます。JSがあった上で生まれたJSフレームワークですし、Vanilla CSSがあった上でのTailwind CSSであることは、使用していくとより実感することですよね。
フレームワークやLLMが進化するほど、より基本および基本を習得している人の重要性は増しているように感じます。
ただ、ここで全く違う視点から見るとフレームワークなど応用技術を一度使ってから、基本の重要性を実感して「目的がある効率的な学習」をする可能性も否定できないので、基本→応用を染み込むまで繰り返すことが重要な気がします。まぁここに関しては、いきなり業務でやるのではなく、個人プロジェクトや自己学習でやることな気はしますが...
自分もこのツイート拝見しました。確かに言ってましたね。これにも関わらず、@applyを乱用しているプロジェクトを自分も見たことがあります...
一度使用してしまうと、他の方が理解しにくく修正しにくいことはもちろん、.cssファイルへのバンドルサイズやJITコンパイルの誤作動当の可能性もあるので、どうしても使用する場合は、少なくとも前述したデメリットは理解しておいた方がいい気がしますね。
すみません、QAに関してそこまでしっかりコメントできてませんでした。
確かに、QAのためにテストコードを書く際、idやclassら辺を参照することがありますね。idやclass属性などHTMLの属性は外部のCSSファイルからスタイリングするためのものではなく、テストにも使われる点も考慮すべきで、Tailwind CSSがその点を複雑にするこの課題に関しても、Tailwind CSSの使用者は認識しておいた方がいいですね。
テスト自体の重要性が年々増している点も頭に入れておいた方がいいですね。
ここに関しても、自分は完全に賛成です。LLMにとって便利=人間にとって便利とは必ずしもならないのは既知ですが、LLMにとって便利=人間にとって不便 にしない方がいいというのは、確かに注意すべき点だと思います。現状だと開発フローの全てをAIが完全に自律的に遂行できるわけではないですし、仮にそれが実現する場合は、このTailwind CSSに関する記事も不要の産物になるかとは思います。
できる限り LLMにとって便利=人間にとっても便利・理解しやすい状態にしておくことで、莫大なメリットがあると思うので、そうする方が合理的な気はしますね。
この点もコメントありがとうございます。私はデザインに興味があり、学習している身でもあるので、とても共感できます。マークアップやフロントエンド開発に精通していない、デザイナーの方は一定数存在すると思いますし、自分もそのような技術アセットの方を知っています。その場合に、いきなりTailwind CSSを導入するのは、正直エンジニア側が思っているよりハードルが高いのではないかと思います。
個人的に、そもそものCSSへの理解に加えて、Tailwind CSSへの理解、そして一貫性があってTailwind CSSの良い点が活かせるプロジェクトにおいて初めてTailwind CSSを使用するという選択肢の優先度が上がるのではないかと思います。
Tailwindでは「数が大きい方が優先」というルールがあることに関しても、確かにVanilla CSS + BEM記法だとシンプルに書けば済む問題というところもその通りですね。
色々コメントありがとうございます。自分も考えていたこととほぼ同じなので、とても共感できる部分がありましたし、改めて考えさせられました。
正直Tailwind CSSに関しては良い面も悪い面(癖のある部分)もあるというのが個人的な印象です。仮に使用する場合は、脳死で選択するのではなく、できる限り他のスタイリング手法と比較した上での選択をした方がいいのではないかと思います。この一言に全て集約されていると思います。
使うなと言っても、今後LLMには好まれているスタイリング手法の一つだと思いますし、Vibe Codingに盛り上がりで、CSSに知見が浅い方はその点を深く考えずに選択するケースは、どうあがいても増えると思います。そもそも非エンジニアと呼ばれる人々がコーディング及びスタイリングをするケースがLLMによって増えていってると思います。
色々コメントさせていただきましたが
Vibe Codingが進んでいく中で、この先私とVal Savenさんがスタイリング手法について考えている意見とは全く違う意見や技術が出てくることも大いにあるんだろうな〜と思います。