Tailwind CSS を採用しない方がいいかもしれないユースケース

こんにちは。Gaji-Labo 横田です。今日は、Tailwind CSS を採用しない方がいいかもしれないユースケースを考えてみました。

併用するオリジナル CSS や他のフレームワークが存在する

たとえば Shopify のような SaaS の場合、テーマごとに独自の CSS が含まれています。また運用中のサイトやサービスであれば、オリジナルの CSS や、採用済みの CSS フレームワークや設計、ルールが存在します。このようなベースとなる別の CSS ありきに Tailwind CSS を後から導入する場合、 class 名に接頭辞をつけるなどの工夫で既存の CSS と区別しながら併用することはもちろん可能ですが、以下のような開発コスト・運用コストを同時に考慮する必要があると思います。

• @tailwind base; を読み込むと既存のリセット系スタイルに影響を及ぼすケースがある。結果、Tailwind CSS の機能を十分に使えない

• class 名が重複してスタイルが崩れたり上書きされる
• 既存の CSS でセレクタの詳細度が上がっている場合、Tailwind CSS と併用するために !important を多用するケースが出てくる
• Sass 等で変数として設定したい値を、既存の CSSと Tailwind CSS の config で二重管理するケースが出てくる
• 既存の CSS とのすみ分けが複雑なルールになる。とくにチーム開発の場合、ルールの共有を徹底しないとすぐに破綻する

@apply 機能を多用する CSS 設計が必要である

スタイルの再利用や共通化を目的とした CSS 設計が必要な場合、 Tailwind CSS の @apply 機能を使って独自のクラスで管理することは可能ですが、クラス名を考える必要がある、スタイルを変更する際の影響範囲が広い、CSS のバンドルが大きくなるなど、Tailwind CSS を使わないケースとコストが変わらなくなります。

この辺は以前もブログに書いていました。

Tailwind CSS のデザインシステムを必要としないデザインである

Tailwind CSS はデザインシステムを組み立てることをユースケースとしたフレームワークだと思います。 しかし、Tailwind CSS の導入を考慮していない、デザインシステムを必要としないデザインを開発する場合、そのデザインを再現するために Tailwind CSS の config でプロパティごとにカスタム値をひたすらに追加して独自拡張していくか、min-w-[1080px] のように毎回任意の値をマジックナンバーで指定する必要があります。

クラス名や CSS の設計を一から考える必要がない Tailwind CSS の利点を活かすことは実装視点のみで見ればメリットにもなりますが、再現したいデザインと Tailwind CSS のデザインシステムに差分が大きいと、かえって実装側で吸収する負担が増え、開発スピードやその後の運用コストにも影響します。

Tailwind CSS によるデザインシステムが、デザインを制限する場面も出てきます。

プロジェクトの状況に応じ、フロントエンドだけでなくデザイナー等とも協議した上で、Tailwind CSS の採用を決定する必要があると思います。

終わりに

これまで複数のプロジェクトで CSS フレームワークとしての Tailwind CSS の利点を実感しつつ、故に、採用には熟考が必要だなと感じました。Tailwind CSS の採用を迷われている方の参考になれば幸いです。