Tailwind CSSの概要と導入のメリット

はじめに

本記事では、Tailwind CSSについてまとめています。
すでにbagelee内でTailwind CSSについて言及されている記事があるため、今回はなぜTailwind CSSを推奨する話があるのかについて深掘りしたいと思います。

bageleeの運営会社、palanでもTailwind CSSを積極的に使っていきたいと考えているので、少しでも興味のある方は一緒に学んでいきましょう！

過去のTailwind CSSについての記事はこちら↓

Tailwind BuilderでReactのコードを出力しながらTailwind CSSを学んでみる

Tailwind CSSとは

Tailwind CSSは、デザインシステムを簡単に作るためのユーティリティフレームワークです。

ここのユーティリティは、FLOCSSのオブジェクト内のUtility（細かい調整のためのスタイル）と近い意味であり、Tailwind CSSの1つのクラスは、1つのスタイルを持ちます。

HTMLにクラスを追加する行為が、スタイルを追加することになるので、CSSのファイルを開く必要がなくなります。

スタイル追加の例

上の画像のように、作りたいスタイルに合わせてHTMLに直接Tailwind CSSのutility classを付けていきます。
最初はクラス名を一つひとつ確認する必要がありますが、一度覚えてしまえばスムーズに記述できそうです。ホバーやレスポンシブ化のためのutility classもあります。

導入することで解決する課題

デザインと実装の見た目が一致している状態を理想とすると、「デザインと実装の同期が簡単にできる状態」「デザイン、実装側に共通のルールがある状態」が必要になります。
つまり、それぞれのプロジェクトでデザインシステムがある状態がベストです。

とはいえ、毎回デザインシステムを0から作成するのはコストがかかりすぎるため現実的ではありません。また、0からではなく、従来の思想を取り入れながら作成しようとすると課題があります。

例えば、atomic designを用いようとした場合。
atomic designとは、最小のパーツであるatom（原子）からmolecules（分子）、organisms（生体）、templates（テンプレート）、pages（ページ）とコンポーネントを作成していくことで統一性のあるUIデザインが可能になる手法です。

（引用元：Atomic Design Methodology）

小さな単位からオブジェクト化するため、変更が容易になりデザインと実装の見た目も一致しやすくなります。どの粒度までを一つのコンポーネントにするかを考えるフレームワークとしても有名ですが、毎回のプロジェクトでチーム内の共通認識を作るのは、フローが定着するまでが難しく、課題といえます。実装でコンポーネントの粒度が変わってしまうと、CSSの構造とAtomicの構造が一致しなくなり理想の状態を維持することが出来ません。

似たような課題として、CSSの命名規則であるBEMが挙げられます。
どこまでをblock（一つのコンポーネント）とするか、デザイナーとエンジニアでの粒度が異なってくるため認識のすり合わせが必要です。

utility classを基盤として自分たちでデザインシステムを作ることができるTailwind CSSでは、上記の課題をクリアすることができ、柔軟性を維持したまま統一性のあるデザインが可能になると考えられます。

期待している未来

palanでは、disrupt markup (マークアップ作業を極力減らすこと)を目指しています。

デザインツールとして主にFigmaを使用しているので、 プラグインのfigma to codeなどを社内でテスト運用しています。精度はまだ低いのですが、将来的にutilityの設定やコンポーネント、HTMLやReactなどのコードもそのまま書き出せるようになれば、デザインと実装の見た目が常に一致している状態に近づけるのではないかと期待しています！

まとめ

Tailwind CSSはデザインシステムの補助となる、ユーティリティフレームワークです。

従来のデザインシステムに不満がある一方で、自分で新しくデザインシステム作ることにハードルを感じている方にはおすすめです！

デザイナーでどんなスタイルがあるのか気になった方は、Figma内のCommunityにあるTailwind CSSのUI Fileを見てみるのもいいかもしれません。（アップデートは終了しています）