おさらい：Tailwind CSS
Tailwind CSSはUtility firstをコンセプトのCSSフレームワークです。CSS設計におけるUtilityクラスを各プロパティ毎に用意をし、htmlにマルチクラスでコンポーネントを作成していきます。
こんなボタンを作りたいときは以下のように当て込む
<button class="bg-blue-400 text-white border-0 px-7 py-3 rounded-lg">ボタン</button>
Bootstrapと違い、すでに用意されたコンポーネントから拡張するのではなく、自身が作成したいコンポーネントに対してクラスを当てるため非常にカスタマイズ性と自由度が高いです。
また、ユーティリティクラスで構成されるため、コンポーネントに対して命名の負担を減らせるメリットもあります。
そのためCSS設計やコンポーネントの設計において非常に力強い味方になってくれるフレームワークです。
どのタイミングでTailwind CSSを採用すればよいか
ではどのタイミングで使っていけば、Tailwind CSSの能力をフルに発揮できていくのかを考えていきます。
CSS設計が無秩序でありながら、デザイン性を持たせたい場合
例としてあがるのが、プロトタイプ作成などです。人に見せる前提だとしてもプロトタイプは操作性の確認・評価が目的になるため、CSS設計とは無縁です。プロトタイプ作成においてはTailwind CSSを入れておけば最低限のデザイン再現のため余計な思考を巡らせる必要はありませんし、HTML側だけを考えるだけでよいです。その他にもデザインにこだわりがないものなどにも、採用してもよいかもしれません。
また、VueやReactにおけるコンポーネント設計において、CSS in JSに変わるCSSフレームワークとして採用するのもよさそうです。Tailwindの特徴における、HTMLとCSSの関心の分離がJSファイルのみで行われ、コンポーネント名だけを考えればよいので、設計の負担が非常に軽くなりえます。
非常に堅牢なCSS設計を考えなければならない場合
上記とは逆で、拡張性と堅牢性をもたせつつも独自のコンポーネントを作成したい場合などもTailwind CSSは向いていると考えられます。
例としてはデザインシステムなどがあたります。Tailwind CSSという共通言語があるので開発メンバー内で意思統一が図りやすく、複雑怪奇な命名規則を考える負担も少なくなります。また、ボタンの色や幅などを拡張するにしても、HTML側だけを見ればよいのでCSSを考えなくてよいものとなります。
だが、静的HTMLの開発現場に使うのはよくない
非常に柔軟で自由と規律があるTailwind CSSですが、静的HTMLで開発が進む場合、採用は控えたほうがよいと思っております。ネックとなるのはやはり、マルチクラスゆえのHTMLへの記述量多さ。関心の分離が進みますが、記述量を多くし負担を増やしてでもやるべきことなのかは疑問が残ります。
上記のボタンを作るだけでも、HTMLを読み解くだけで負担になりますし、出来上がったHTMLは非常に冗長で難解なものになります。
そうならないために、@applyでまとめて設計をしていけばよいという声も聞こえそうですが、それでは通常のCSS設計とほぼ同じになってしまいます。
@tailwind base;
@tailwind components;
@tailwind utilities;
.btn {
@apply bg-blue-400 text-white border-0 px-7 py-3 rounded-lg;
}
<button class="btn">ボタン</button>
CSSファイル自体、スッキリすると思いますが難解性がHTML側からCSS側に移っただけですので、根本的な解決にはなっていません。また、細かなデザイン指定やピクセルパーフェクトが絶対の実装には不向きです。
優位点はユーティリティクラスが存在しているから拡張が楽になるぐらいでしょうか？
しかし、こんな事を考えるならば、普通にCSS設計をしていたほうがマシです。
終わりに
Tailwind CSSはユーティリティクラスが故に、関心と分離が進む非常によいフレームワークですが、採用に至っては慎重にならなければならいケースがほとんどです。
CSS設計とは程遠いコンポーネント設計やSPAなどには非常に最適ですが、コーポレートや独自性を持ったCSS設計の場合、Bootstrapのように元あるものから拡張していくケースのほうが、結果としてスムーズに進む可能性があります。
開発現場で何を目的とし何を完成形とするをじっくり見定め、フレームワークの技術採用を考えていきましょう。