Tailwind CSSを使わないモチベーションを整理する@2022-09

他の記事からの抜き出し

ウェブアプリ開発にTailwind CSSを導入してみた

良かった
- 決められたユーティリティクラスを使うのでクラス名を考えなくて良い
- どのフレームワークに対しても使える
- CSSが増えない
- テーマの設定によりデザインルールから逸脱しない
- 情報が多い
良くなかった
- 付与クラスの量が多くなり可読性が落ちる

それでも私がTailwind CSSではなく、CSS Modulesを推す理由

NextでBuild-inサポートされている
- webpack依存というのもほぼwebpackを既に導入してるんだから問題ない
ファイルが増えてめんどくさいが
- 確かに面倒
- ただし、ファイル管理の面倒臭さと責務の分離はトレードオフ
- jsxファイルはできるだけ「state、propsのデータの流れとレンダリングロジック」に集中できる見通しの良い状態が良い
Tailwindではしんどい状況は（少ないが）確実に存在する
- その回避方法を考えたり、ハック的な処理が増えたり、これは良くない
Tailwindで出来ることはCSSでできる
- 当たり前だけど
スタイルが完全にTailwind依存になる
コードが汚くなる

TailwindCSSは複雑性を足すだけで、何もしていない（和訳）

ユーティリティクラスは段階を踏んだインラインスタイルにすぎない
HTMLはページの構造にのみ関心を持つべきでページのスタイリングには関心を持つべきではない
可読性が悪い
標準CSSの多くの機能が使えない
@applyを使って関連するクラスをまとめることができる？それってユーティリティクラスを壊してない？
CSSより良いものはすでにある
- CSSプリプロセッサ（SCSS）、CSS-in-JS、リンター、ベストプラクティス
- これらはコードに具体的な利益を提供する

Tailwind CSSが私には合わなかった理由 | コリス

汚いHTMLを推奨している
@applyに互換性がない
TailwindのデザインシステムとトークンはCSS変数で置き換えられる
divとspanの乱用を推奨している
結論：Tailwind CSSが好きなら使用すればいい。しかし、目指すべき未来であると私に納得させようとするのはやめてください
- not for me

コメントから抜粋

この記事が多分大多数の肌感に一番近いんじゃないかな。「分かる、すげー便利、とてもすごい！でも俺には合わないんだ」
Tailwind CSSは好きだし個人開発では使いますが、本番投入しようとまでは思わないですね。他のチームメンバーに慣れてもらうのが大変だろうと思ったのが理由です。本番では記事で触れられているようにcss、scssでいいと思っています
Tailwind CSSはCSS界のjQueryになってしまう可能性があるね

整理

技術的負債

Build-inサポート、技術負債などは大事な視点だけど、どんな状況でもそれが一番の理由にはならない。

素のHTMLで使う場合→Tailwindは使わない

Tailwindは付与クラスが多いので、コンポーネントベースじゃない素のHTMLを書いていく場合は採用するメリットはない（コピペ量が増えるので）。
コンポーネントベースならそこはデメリットにはならない。

CSS Modulesとの比較→CSS Modulesは使わない

コンポーネントベースの開発なら、確かにスタイルとマークアップを分離する意味は無いと感じた。
今までCSS Modules派だったが違うと感じてきた。CSS Modulesは単純にファイル数が増えるのが面倒。クラス名は大きく見ればDOM要素に意味を持たせる=コンポーネント化するものだと思う。
マークアップ自体がコンポーネント化した上で更にクラスにも意味を持たせるのは確かに違う。 CSSとHTMLの分離が、技術の分離にすぎない関心の分離になっているのは確かにそう。
そこをメリット・デメリットに上げるのは違う。

CSS-in-jsとの比較→Tailwindは使わない

css-in-jsもtailwindも独自だが、よりCSSに近いのはcss-in-js。
Tailwindを知らない人（僕）が加わるハードルが高い。
1年後の自分がメンテナンス出来る気がしない。 css-in-jsもtailwindもjsによってエンハンス出来ると思うが、どちらもできるならcss-in-jsで良い。
考えることは少ない方が良い

結論

Emotionを採用