Zenn
🎨

CSSライブラリの選定って、どうしたらいいの？

2024/11/16に公開
CSS
Tailwind CSS
style
CSS in JS
tech

CSSライブラリの選定、どうしたらいいんだろう？

私は、Webアプリケーション開発の勉強をしているとき、
様々なCSSライブラリの話を目にしたりします。

  • TailwindCSSはいいぞ！
  • UIライブラリはデザインがある程度固まってるからやりやすいぞ！
  • 時代はZeroRuntime CSS in JSだぞ！
  • 結局どれもCSSのファイルにビルドされるんだから最初からCSSファイルに書けばよくない？

そのどれも間違っていないように見えます。
インターネット上には、様々な方の私見・所感や、ポジショントークが
様々な形式で点在しているので、何を信じていいのかわからなくなるときがあります
そんな、「CSSライブラリ、結局何を選んだらいいの？」と思っている方向けに
「もしかしたらこういうことを基準に選んだらいいんじゃないか？」という助けになれば、
と思い、とりあえずまとめてみたものです。私の所感をまとめているところがほとんどなので、
他の方の記事を見るときの息抜きに読むことをおすすめします。

TailwindCSSに思うところ

まず、TailwindCSSについての私の所感を書いていきたいと思います。

いいな～と思うところ

TailwindCSSのUtility Classのあり方

CSSファイルをいちいちいじらずに、class/classNameの内容をいじるだけで済みます。
CSSの1項目ずつを一つ一つ決めながら、一番良さそうなところを模索していくという段階に、
CSSファイルを開く手間なくすぐに移行できます。
ReactでHTMLの階層を書いたすぐ後にスタイリングに移れるのはスムーズで
良い体験だなと思います。

クラスをまとめられるところ

@layerと@applyを使って、UtilityClassをまとめたクラスを作成できます。

@layer base {
    .card {
        @apply ...;
    }
}

こういう感じでまとめられます。しかも、「まとめたクラスをさらに中に入れてまとめる」なんてこともできてしまいます。例えば、card,card-body,card-title,card-paragraphというクラスを作って、特定の場面で利用するということができます。
そして、別で作っておいた汎用的に利用するクラスをその中に入れて、デザインに統一感をもたせることができます。

拡張性

tailwind.config.{js,ts}に新しいカスタムプロパティを書き込んで、自分の好きなように拡張できるのはとても楽しいです。画像を背景にしてみたり、アニメーションを動かしたり、その部分のテキストにマーカーペンで線を引いたようなデザインにしたりと、やりたいことを好きなようにできるように拡張できるのは、自分の創造性を思うままにアウトプットできる楽しさを感じさせてくれます。

う～んと思うところ

一方、TailwindCSSには、個人的にこういうちょっとめんどくさいところがあると思います。

Utility Classを全部覚えきるのは困難

Utility Class、めちゃくちゃ多いです。
Utility Class全部覚えられるか！！ と思ったことは何回もあります。
そのため、「このCSSをTailwindCSSでやる場合ってなんて書くんだっけ」ってなる場面が非常に多いです、そのUtility Classの確認のために、TailwindCSSのドキュメント[1] を開いてはクラス名を確認しなければならないのが、TailwindCSSが嫌になるというほどではないものの、少し手間に感じてしまったことがあります。

HTML要素に、直にスタイリングの内容を書くこと

「さっきいいな～と思うってところにあったやんこれ！」って思った方、
実は、この直に書けるというところ、メリットの裏にはデメリットが潜んでいます。
最初は「スパスパかけていいな～！」と思い、だいたいのUIのHTMLを書き終えた後、
HTML要素に対して直接一個一個CSSを書いてるようなもんだよなコレ、ええんか？
という不安がありました。この不安は、
あとから「ちょっとデザインを変えたいな」と思った時に的中してしまいました。

そのデザインの変更のために、様々なコンポーネントのファイルの内容を確認しては、
所々の調整をしては別のファイルを見て、そのファイルの調整をしては別のファイルを調整して...
という非常に大きな手間を生み出してしまうことになりました。

これは、非常に緻密なスタイリングをしている場合は手間のかかり方が半端ではないものになるでしょう。例えば、relativeやabsoluteで相対位置で場所を決めていて、調整用にtopだかleftだかを使っている場合を想像してみてください。
そして、その調整用のtopとleftのスタイリングを要素に直接与えてしまっていると考えると...
少し想像したくないですね。

TailwindCSSに対する所感まとめ

もちろん、今回あげた「う～んと思うところ」の対策方法がないわけではありません。
それは、今度記事を書くときのネタにしたいのもあり、今回は説明しません。
ただ、このデザインを変更するときに非常に手間がかかったという出来事は、
TailwindCSSをうまく使うには、テクニックがいるということを実感する出来事になりました。

UIライブラリに思うところ

いいな～と思うところ

すぐ何かを作りたいときに、ある程度決まったデザインをそのまま使えるのは便利

デザインセンスに自信がない人や、デザインを検討・調整する時間より、機能の開発に時間をかけたい時には、UIライブラリを使ってしまった方が早く済みます。
色やサイズはある程度、パパっと後から変更が効くので、
スケルトンのようなデザインでおおまかに組んでしまってから
後から色を足すというテクニックが使えるかもしれません。

UIコンポーネントライブラリの場合、引数として色やサイズを指定可能

コンポーネントのsizeやthemeという引数に対して、ある程度決められた色や数値を渡して、
簡単に調整を図ることができます。「色やサイズはある程度、パパっと後から変更が効く」というのはこれのことです。

う～んと思うところ

オリジナリティは若干なくなる

逆にデザインセンスが高い人がUIライブラリを使うと、
自分のデザインセンスをフルに活かしきれないかもしれません。
デザインセンスをフルに活かしたいのであれば、
UIライブラリに頼らない方がよいと考えます。

UIライブラリに対する所感まとめ

急いでパパっとデザイン作って機能時間かけて作りたい！！という方には
おすすめなんじゃないかな…という印象が個人的に強いです。
一番デザインについて頭を悩ませる時間が減るライブラリの部類だと思っています。

ZeroRuntime CSS in JSに思うところ

いいな～と思うところ

多くがTypeScriptに対応していて、型がついているところ

型があるため、型によるサジェストが効くなどの、
型があることの恩恵をスタイリングの面で受けることができます。
何かを指定するときの数値が大きすぎるときには型のエラーで弾いたり、
数値以外にも文字によって指定可能なものを追加して、それをサジェストさせるなど
思い思いのスタイリングが型によってサポートされます。

propsやレシピという概念がだいたいのライブラリにある

動的なデザインにしたいとき、動的なデザインを実現するために、引数を受け取ることや、
TailwindCSSでよく見た、base-100とか、orange-100のような指定を引数として受け取るような
ものを作成する「レシピ」という概念があり、これも型によるサジェストが効くようになるため、
動的なデザインに対しても型の恩恵を受けることができます。

う～んと思うところ

学習コストが高いと感じたら、チーム開発では採用されづらいかも

私は、Webアプリケーションを作り始めるとき、テンプレートを引っ張ってくることが
よくあります。その場合、TailwindCSSがデフォルトで入っているものをよく見かけます。
既に入っているTailwindCSSを取り除いて、ZeroRuntime CSS in JSライブラリを
導入して、書き方を学びながら書いていくということが、そのライブラリで得られるメリットが
その学習コストに見合っているかどうかという部分で、採用されづらいかもしれません。

ZeroRuntime CSS in JSに対する所感まとめ

めちゃくちゃよさそう！！という印象はある一方
やはり、比較的新しいものであり、TailwindCSSが広まった後に
現れたこともあって、まだまだ自分の周りでは使っている人を見かけないです。
また、先述した学習コストのことも考えると、TailwindCSSに対して型を加えたり、
レシピの概念を加えるものが出たら、そっちのシェアが広がりそうだなと感じています。

「最初からCSSに書いちゃえ」に思うところ

いいな～と思うところ

ライブラリ選定をしなくてよくなる

何もライブラリを使わないということを決めていれば、
ライブラリを選定する時間も手間もなくなります。
頭を悩ませる時間も、導入する時間もないので、
パパっと開発に取り掛かれます。

ライブラリによって対応していない新しいCSSをすぐ使える

ブラウザの更新で新しいCSSプロパティが出たという情報を得て、
それをすぐに試したい時には、やはりCSS単体の方が良いでしょう。
ライブラリが新しいプロパティに対応するのを待つ必要がないので、すぐに動かして試せます。

う～んと思うところ

直に書くのはデザインセンスが必要

自らのデザインセンスでよいデザインを作っていくことを覚悟しなければなりません。
例えば、私の知っている方で、個人でWebアプリケーションを開発する度に、
CSS単体で良いデザインを作り上げてしまう方がいます。
その領域にいくまでには様々な努力をしてきたでしょうし、
自分もその域までいきたいなと思うことがありました。
オリジナリティを発揮しつつ、良いデザインを作り上げることは、
当然ですが、様々なことに気を付ける必要があります。
これはどのライブラリを使っていても同じことなのかもしれませんが
CSS単体だとその難しさはライブラリに頼らない分、大きいでしょう。

これまで触ってきたエコシステムの便利さは捨てるということ

「これまで使っていたエコシステムから受けていた恩恵はいったん捨てて
自分の力でCSSを書き、デザインを固めていく」ということです。
そもそもCSS単体の人はその覚悟も何も普段と変わらないでしょうが、
エコシステムの恩恵を享受してきた人からしたら非常に高いハードルになることは間違いないでしょう。

「最初からCSSに書いちゃえ」に対する所感まとめ

これをジャンジャンやっている人からしたら苦でもなんでもないですが、
エコシステムから脱却して自分の力でなんとかしてみよう！と思って始めてみると
かなり大変かもしれません。それでもやるという方は、頑張ってください...！

結び

結局、全部私の所感なので、参考にならなかったら読まなかったことにしても構いませんし
参考になったなら、書いた甲斐があったなというところでしょうか。

CSSライブラリの選定は、開発するものに関わる人や、作るものの内容を見て、
慎重に行うことになるでしょう。
この記事が、少しでも参考になったらよいなと思います。

脚注

  1. https://tailwindcss.com/ ↩︎

Discussion