実務で初めて分かったTailwind CSSのメリット7選

はじめに

プライベートでTailwind CSSをちょっと書いていた頃、別に言うほど悪くはないけどスタンダードなCSSやSassを置き換えるほど価値があるほどなのかな...と疑っていました。

しかしTailwind CSSが採用された中〜大規模チームに放り込まれて実装者・レビュアーを経験してから、その威力が次第に手にとってわかるようになりました。

今回はそこで感じたメリットを7個お伝えしようと思います。

備考

現在も含めた筆者のCSS歴・UIライブラリ歴はこちら。

• 生CSS
• Bootstrap
• Sass
• Emotion
• MUI
• Tailwind CSS
• shadcn/ui

1. シンプルに保てる

ざっくりと言えば誰が書いても同じになります。
細かく分けられたユーティリティクラスにより、書き方の差がかなり生まれにくいです。

例えばclsxでどのタイミングで結合するのか・どれだけ長くなってもワンライナーで書くのか、等その程度でしょう。

2. 複雑化しずらい

クラスの命名ルールから開放される

これは一体WrapperかContainerかOuterかどう命名するのが最善なのか？とかいう末端の問題について考える時間をすべてゴミ箱に追いやることができます。

CSSがHTMLに依存しない

• 特定のHTMLを意識した複雑なセレクタでCSSが書かれることがなく、常に絶妙な読みやすさのスタイルがHTMLに紐づくだけです。
• HTMLとCSSのどちらがどちらを知るべきかは賛否両論なものの、リッチなUIにはHTMLがCSSの制約を受け続けることは令和の時代には受け入れたほうが良いでしょう。

クラスの入れ子が多重化しづらい

• 子へと孫へとセレクタを飛ばそうとするとちょっと面倒な書き方になるので、必然的にそのような実装が必要以上に濫用することは避けられます。
• つまりビギナーにありがちな「面倒だから全部子or子孫配下に書いてそこを膨れさせればヨシ！」が起こらず、本当に適するか否かで子要素以降へのスタイル指定が使われるという理想の状態なのです。

---

これらはレビュアーとしても時間の節約になり、より有り難みを実感します。 過去案件で4〜7重もの入れ子が常態化していた頃の精神状態とは大違い

3. 環境構築が楽

これは好みの問題レベルであり僅差かと思いますが、ESLintのエコシステムで賄えるTailwind CSSのLintやソート用Formatterの方が、Stylelintのそれより何となく楽に感じます。

4. 身体にやさしい

何度もタブを切り替えたり2ペインを開いたり行ったり来たりしなくて良く、目と手にやさしいです。
横長のclassNameは確かに美観を損ねますが、エディタの行を折り返すかclsxで分割するかしてとっとと慣れましょう。

5. ちょうどいい薄さ

単体の宣言に対応するクラスと共に、複数の宣言が必要なspace-x/y-{n}やline-clamp-{n}などのユーティリティも必要最小限であり、かつ内部構造も把握しやすいです。
これだけの薄さを徹底されていると「ここはTailwindに依存せず生で！」と考えるケースもないので楽です。
また腐ってもmixinか他の何かに容易に置き換えられるでしょう。

もう1つ特筆すべき点として、コンポーネントではなくCSSのレイヤーに抽象化が閉じていることです。
いくらコンポーネントベースとはいえど、それだけでマークアップの汎用性を解決できると考えるのは黄色信号です。

（ここでは割愛しますが、数個ほどのCSS宣言を添えた汎用コンポーネントを、JSXに何も制限がないまま作れますか？ジェネリクス・refのforwarding・自由な要素への入れ替えを幾多ものUIライブラリのように両立できますか？もしそんな実装が朝飯前だとして、どうチーム開発に導入していきますか？）

6. 教えやすい

これは昔に抱いていた印象と打って変わって意外なのですが、書き方に幅が生まれない・ドキュメントが充実している、ということがあり結構レビュアーとしても教えるのが楽です。
富豪的なUIライブラリと比べてそうなのは当然として、通常のCSS・Sassと比べても同様に感じます。

具体的には、CSSはわかるけどあまり専門的に書いてない・自信がない・くらいの初級者には教えやすいです。全くの入門者には厳しいかも。

7. デザインシステムにフレンドリー

大げさに言えば、適当に補完通りに打ってればデザインシステムに沿って実装できます。
これが99%ピクセルパーフェクトを要求されたことはないですが恐らくその場合でも、最低限トンマナを担保したガワを準備しておく場合でも実力を発揮します。

FigmaやXDが全て完璧ではありません。デザイナーさんが（我々エンジニアと同様に）保守を怠ったりミスを発生させたりする・技術的制約などの様々な考察によりUIを再度詰めなければいけない、等のときにエンジニア手動で動くものを提案する場面はよくあります。そのときTailwindは頼もしい味方になってくれます。

備考

これまでTailwindを褒めちぎりましたが、あくまでもどれだけTailwindの導入が合っているか・どれだけTailwindで賄えるかはPJの特性に合っていることが大前提です。

例えば...

• 疑似セレクタを多用するスタイル
• サードパーティライブラリのCSSを上書きする
• フロントエンドにロジックが寄る高機能なGUI

のような場面ではキツいかもしれません。
そのような壁に直面したとき、CSS Moduleやインラインスタイルといった別の技術も含めて判断する腕は当然のごとく求められるでしょう。

結論

個人的には少なくとも一般的なWebアプリのユースケースの8割程度なら、Tailwind CSSがない世界には戻れません。
CSSエコシステムとフレームワークの中間に位置するような絶妙な使い心地にはもう虜になりました。