はじめに
毎年この時期になると、その一年のCSSについて世界のWEBエンジニアからアンケートを集計し、まとめられたサイトが公開されます。
その名も State of CSS。その2022年版が先日公開されておりました。
アンケート回答数でいうと14,310件、国別だとアメリカが11.7%・ドイツが5.9%・フランスとイギリスが4.2%となっています。日本は0.7%ですね。
そのため、日本のトレンドという側面はあまりなく、世界のトレンドとして見ていく形になるかと思います。
CSSフレームワークのトレンド
CSSフレームワークについての質問の回答で、毎年右肩上がりに順位をあげているのが TailwindCSS です。
「使用率」で言えば Bootstrap に次ぐ第2位ですが、「満足度」で言えば第1位という結果になっています。
※ 近年の評価の移り変わりなどもグラフでインタラクティブに見れるので、ぜひ他の結果も見てみてください！
2020年ごろから話題になり始め 次第に認知度も広まっている印象の TailwindCSS ですが、
実際にどのような点が良くてどんなアプリケーションに向いているのでしょうか？
弊社では最近 ChakraUI を採用するケースが増えているので、今回は TailwindCSS と ChakraUI を比較しながら TailwindCSS についてまとめてみたいと思います。
TailwindCSS とは
簡単にまとめると、以下のような特徴があります。
- Utility-firstという概念で、Utility-class1を用いてデザインシステムを構築するCSSフレームワーク
- UIコンポーネントは準備されておらず、Utility-classを使って独自のコンポーネントを作成していく
⇒ カスタマイズ性が他のCSSフレームワークより高い！
ChakraUI との違い
※ ChakraUI についてはこちらでも解説しているので、良ければご覧ください。
「Utility-firstのCSSフレームワークというと ChakraUI と同じでは？」とも思いますが、TailwindCSS と ChakraUI の違いはなんでしょうか。
大きな違いで言えば以下となります。
- 【ChakraUI】 UIコンポーネントが用意されており、それをカスタマイズしていく
- 【TailwindCSS】 UIコンポーネントは用意されておらず、Utility-classで独自にコンポーネントを作成していく
フレームワーク側がボタンやメニューなどのすでに出来上がってるUIコンポーネントを用意していてくれている ChakraUI に対し、TailwindCSS ではUIコンポーネントは準備されておらず、Utility-class使って独自のコンポーネントを作成しデザインを行っていきます。
また、TailwindCSS では Tailwind UI という UIコンポーネントライブラリ が別にあり、ある程度の型やテンプレートが提供されたものを使用することが可能です。
それぞれのコードの書き味の違い
以下、それぞれのコードを記述する時の特徴です。
ChakraUI の場合
import { Button } from '@chakra-ui/react'
<Button colorScheme='blue'>Button</Button>
ある程度キレイにデザインされたUIコンポーネントがすでに準備されているので、上記の記述のみでも使用できます。
もちろんスタイルをpropsで指定することでカスタマイズも可能ですが、場合によっては独自デザインのスタイルをあてる時にデフォルトのデザインが邪魔に感じることもあります。
ただ、その時は themeカスタマイズ機能 を使えばそもそものデフォルトスタイルをカスタマイズもできるので、使い方次第かもしれません。themeレベルでのカスタマイズは習熟・実装にコストがかかります。
TailwindCSS の場合
<button type="button" class="flex items-center justify-center rounded-md border p-3 border-blue-500 hover:bg-blue-500 hover:text-white">Primary</button>
UIコンポーネントが準備されていないので、上記のようにclassにインラインクラスのような形でスタイルを指定していきます。
そのため、完全に0の状態からデザインを実装していくことが可能です。
TailwindCSS のメリット
上記の書き方を見ると、『これだったら普通にCSS書いても一緒だし楽じゃん・・・』と思うかもしれません。
しかし、TailwindCSS を利用するメリットはたくさんあります。それをいくつかご紹介したいと思います。
1. CSSファイル容量を減らせる
Utility-first という概念で、Utility-classだけでスタイルを組むので、結果的にCSSを再利用する形になり、CSSのファイル容量を減らすことができます。
加えて、実際に使われているクラスだけを抽出する 『PurgeCSS』 という仕組みを取り入れることもできるので、最終的な出力されたCSSファイルは最小限に止めることが可能です。
2. コード記述量を減らせる
HTMLタグに直接Utility-classを記述することでスタイルを指定するので、 複雑なスタイルを描くような場合は、結果的に HTML+CSS の合計記述量を削減することができます。
3. クラス名を考える手間が削減される
こちらはUtility-firstの考え方に紐づく部分で、ChakraUI と同様なメリットです。
クラス名を考える必要がないため（コンポーネント名は考えないといけないですが）、inner とか wrapper などの命名は不要になります。
BEMなどのCSS設計記法も使用しなくて良いため、クラスの命名に割いていた脳を別のところに使えるようになります。
4. CSSの変更が怖くない
CSSは記述量が増えれば増えるほど、影響範囲が広くなり、少しの修正にも気を使わないといけなくなるケースが多いです。
しかし、Utility-classで書かれていれば、少なくとも他の要素のスタイルを壊してしまう心配がないので、影響範囲は最小限に収めることができます。
TailwindCSS のデメリット
上記の２つ目のメリット「コード記述量を減らせる」の反面、Utility-classを使用するとHTMLの記述が増えるのは事実なので、それが見た目的にどうしても許せないと思われる方もいるかと思います。
また、きちんとコンポーネント設計ができていれば問題は起こりづらいかとは思いますが、初めからコンポーネント設計をきっちりできる環境じゃないケースもあるため、そのような場合はコードが煩雑になる可能性は捨てきれません。
TailwindCSS を導入する際のポイント
JSフレームワーク(Vue,react など)が取り入れられて、コンポーネント管理できること
クラス名という目印がないため、きちんとコンポーネント化されていないと、その要素がどのような役割なのかがコード上のどこをみても分からない状態になってしまいます。
また、同じ要素を2つ3つとマークアップしてしまうと、むしろコード量が増えて本末転倒です。
しっかりとコンポーネント設計ができ、UIを作り込んでいける環境であれば、TailwindCSS は力を発揮できるでしょう。
デザイナーさんに TailwindCSS の概念を理解して デザインしてもらえること
こちらは必ずしも必要という訳ではないかもしれませんが、デザイナーさんがUtility-firstの概念を理解してくださった上で、UIをコンポーネント志向でデザインもらえる環境だと、最終的にうまく進みやすいように思います。
例えば、見出しのパターンはコンポーネント化して条件を渡すだけで変更できる範囲で検討してくださったり、など、コンポーネント化をする前提でのUI設計を フロントエンドエンジニア/デザイナー間 で協力して行けるとベストに思います。
まとめ
- 世界のCSSフレームワークのトレンドでは、
TailwindCSSが人気！ -
TailwindCSSは、ChakraUIと同じく utiliy-firstのCSSフレームワーク -
ChakraUIとの大きな違いは、デフォルトのUIコンポーネントを提供しているかどうか -
TailwindCSSを導入する際は、デザイナーさんにTailwindCSSの概念を理解してもらえるかどうかがカギ（デフォルトスタイルがないので） - 総じて、
TailwindCSSの方が学習コストは高めかも
最後に
弊社ではその時々の条件によって ChakraUI を採用したり、そもそもCSSフレームワークを使用せずに Emotion + cssProps で1からスタイルを構築しているケースもあります。
CSSフレームワークは（ものにもよりますが）スピード感のある現場などでは非常に重宝されますが、必ずしもそれが正義という訳ではなく、開発のスピード感やデザインの方向性・チームメンバーのスキルセットなどで、その時に適した形を選択することが大切かと思います。
本記事がCSSフレームワークの選定の際に、少しでも参考になれば幸いです。
-
.text-xsや.text-gray-600のように「このクラスを指定するとどうなるのか」というCSSのプロパティ名をもとにしたクラスのこと。CSSがコンテンツに依存せず、再利用性が高い。 ↩