このページは原文を AI が翻訳したものです。
数年前に初めてTailwind CSSに触れたとき、私の最初の反応は懐疑的でした。
<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
Click me
</button>従来のCSSの慣習——関心の分離、意味のあるクラス名、BEM——から来ていた私には、これはインラインスタイルへの退行に見えました。なぜ誰もが何十ものユーティリティクラスでHTMLテンプレートを散らかしたいのか、理解できませんでした。
当時はコンポーネントライブラリも扱いにくく、多くのインタラクティブなウィジェットは重いフレームワークのランタイムを必要とし、ダークモード対応も後付け感がありました。私はTailwindを「自分には向かない」と切り捨て、CSSモジュールとカスタムスタイルシートを使い続けました。
変わったきっかけ:メンテナンスの現実
最終的に考えを改めさせたのは、流行ではなく、成長中のサイドプロジェクトにおけるカスタムCSSのメンテナンス負担でした。
以前のCSSモジュールを使った環境では:
- 間隔やフォントの太さを調整するたびに、テンプレートとスタイルシートを行き来する必要がありました。
- ダークモードは別々のファイルにカスタムプロパティを維持する必要があり、エッジケースを見逃しやすくなっていました。
- 小さなリファクタリングでも、カスケードの微妙な問題で無関係なUIコンポーネントが壊れるリスクがありました。
Tailwindがバージョン4をリリースし、バニラJavaScriptとダークモードの使い勝手が改善されたとき、私は無視できない規模のプロジェクトで正式に試してみることにしました。
なぜ腑に落ちたのか
1. 一貫したデザインの制約
私が抱いていた最大の誤解は、Tailwindは単に「HTML内の簡略CSS」だということでした。
実際には、Tailwindは制約のあるデザインシステムです。space-y-4やtext-gray-600 dark:text-gray-300を書くとき、あなたはあらかじめ定義されたまとまりのあるパレットとスペーシングスケールから選んでいます。任意のピクセル値を発明したり、マージンが14pxか16pxかで迷う必要はありません。
2. カスケードの副作用ゼロ
ユーティリティクラスを使えば、すべてのスタイルは要素に直接スコープされます。あるビューのカードのレイアウトを変更しても、別のビューのカードが壊れる可能性はゼロです。
特定のユーティリティの組み合わせが頻繁に繰り返される場合、現代のCSSではそれを標準の@utilityや@layer componentsルールに抽出できます:
@import "tailwindcss";
@layer components {
.btn-primary {
border-radius: calc(infinity * 1px);
background-color: var(--color-violet-500);
padding-inline: --spacing(5);
padding-block: --spacing(2);
font-weight: var(--font-weight-semibold);
color: var(--color-white);
box-shadow: var(--shadow-md);
&:hover {
@media (hover: hover) {
background-color: var(--color-violet-700);
}
}
}
}3. 手間のかからないダークモード
アプリ全体にダークモードを実装するのは、かつてはカスタムプロパティのリファクタリングに数日かかる作業でした。Tailwindのdark:修飾子を使えば、ダークモードのバリアントはライトモードの定義のすぐ隣に配置できます。プロジェクト全体へのダークモード追加は、数時間で済むようになりました。
まとめ
Tailwindがすべてのシナリオに最適な解決策とは限りません。複雑なグラフィック、独自のアニメーション、高度に動的なレイアウトエンジンには、依然として生のCSSが必要です。
しかし、日常的なWebアプリケーション開発(フォーム、ダッシュボード、ナビゲーション、カード)において、TailwindはCSSクラスの命名や特異性の競合のデバッグといった頭の負担を排除します。スタイルシートの設計に費やす時間を減らし、機能のリリースに多くの時間を割けるようになりました。


コメントを読み込み中…