Tailwind CSSがちょうどいい感じだった件
Next.jsとの組み合わせで使っていてなかなか良いと感じた。
実際使ってみた感想としては
- CSSのクラス名を考える作業から解放される
- ゆえにアドホックにサクサク書ける
- 同じスタイルを2度以上使う場合はその部品をコンポーネント化すればDRYにできる
うむ快適。
Tailwind CSSをなぜ使うかという話は以下の解説が詳しい。
「CSSのユーティリティクラスはメンテナンス性の面でアカンやろ」と昔から思っていたが、ReactやVueでHTMLパーツのコンポーネント化が当たり前になった世界では「ユーティリティクラスで十分じゃん」となるのだな。
使う手間の軽い比較
一般的なCSSではクラスに意味のある名前を付けてスタイルを当てていく。
<h3 className="article-section-header">
...
</h3>見慣れた感じ。
きっと親のdivにはarticle-sectionクラスが当てられていて、このh3の次にはarticle-section-bodyかarticle-section-contentみたいなクラス名の要素があるに違いない。CSS設計だ。
CSSのクラス名は名前空間などなくすべてがグローバルなので、ほかとかぶらない名前にする必要があるほか、その場のノリで名前を付けていくと割とすぐにカオスになってエントロピーが増大していくので、CSS設計は必須である。
このCSS設計というやつはやってるとそれはそれでけっこう楽しいのだが、まあまあ頭も時間も使うし、時間をおいて久しぶりに修正するときに思い出すのにも時間がかかってしまったりするのが難。コストがかかるのだ。
一方でTailwind CSSのユーティリティクラスを使った書き方では以下のようにスタイルを当てる。
<h3 className="mt-1 py-2 text-xl text-left color-white bg-black">
...
</h3>クラス名を考える労力がなくなり、ウェブサイトの実装に注力できる。
style属性にCSSをアドホックに書いていくのと感覚は変わらなくて非常に楽。
じゃあstyle属性にCSS書いていくのでいいじゃん、と思うかもしれないがきちんとアドバンテージはある。
短く書ける、ということもあるが、大きいのはレスポンシブ対応がなされていることだ。
また同じh3がたくさん並んでるときはどうするの、というメンテナンス性への懸念に関してはコンポーネント化でDRYにすれば問題なし。
むしろコンポーネント化の指標にもなっていいのではないか、くらいな勢いだ。世は大コンポーネント時代。
（なお素の手書きHTMLで使うとまったくDRYにできないのでメンテナンス性がひどいことになる。採用場所を間違えてはいけない）
余談
CSS in JSは？
CSS設計からの解放、という点ではCSS in JSでもいいのだが、コンポーネントに対応したCSSファイルが無限に増えていくのでしんどいなというかんじです。
とか思っていたらEmotionなんかはコンポーネントのファイル内にCSSを書けるのでいいかも。
自分は「CSSまったくわからん」というくらいにはCSS書けるので、細かく調整するならEmotionの方が簡単でええわ、となる可能性もあるかもですね。
渡した値をもとに動的にスタイルを生成するような用途でもCSS in JSが有利？
一方でコンポーネント化しないとCSSを当てられないという点で、手軽さの面ではTailwind CSSより劣るように思われる。
IE11対応
Tailwind CSSはIEに対応していないので要件にIE11が入っていると使えない。
しかしまあIE11対応は早晩負債になるしかないものを生むので、富豪な開発リソースがない限りはやめよう。
特に予算圧力があるプロジェクトでコスト見合いするなら真っ先に落とすべき要件となる。
ノーモアIE11対応。
VSCodeで入れると便利な拡張
Tailwind CSS intelliSense
クラス名補完。
Tailwind CSSのクラス名うろ覚えでもサクサク書けるぞ。
Tailwind Docs
Ctrl + Shift + Pを押した後に調べたいスタイルに関連するっぽいキーワードを入れてEnterキーをッターンするとAPIドキュメントがブラウザで開く。
CSSのプロパティとTailwind CSSのクラス名が一致してないやつを探すのに便利（line-heightがleadingだったりとか）
