2020/07/31
最近のCSSフレームワーク動向の復習
自粛が始まってから考えるのは天下一品のことばかりです。
今回は弊社の小泉が「最近のCSSフレームワーク動向の復習」というテーマで話しました。
群雄割拠なCSSフレームワーク界隈、BootStrap等のCSSフレームワークをおさらいしつつ、最近話題の Tailwind CSS が提案しているユーティリティーファーストCSSという設計思想についてゆるくご紹介します。
ボタンやフォーム、ドロップダウンメニューなど、様々なコンポーネントがあらかじめデザインとコーディングのされた状態で用意されています。
学習コストが低く、これを使うことで簡単にwebサイトをつくることができます。
有名なところだと BootStrap や Semantic UI など。少し特徴が異なるものに BULMA があります。
Twitter社が開発した、おそらく最も有名なCSSフレームワークです。
webサイトを構成する様々なコンポーネントやJavaScript用の拡張などが、HTMLおよびCSSベースのデザインテンプレートとして用意されています。
MITライセンスを採用したオープンソースのUIフレームワーク。
BootStrap同様、多くのテンプレートが用意されており、セマンティック(意味のある)な形でCSSを設定できるのが特徴です。
ここ数年で注目されるようになったフレームワークのひとつ。
このフレームワークが他のものと異なるのは、JavaScriptのフレームワークを提供していない点です。
いわゆるCSSフレームワークというのは、スタイルと一緒に JavaScript のフレームワークも提供していて、それによってドロップダウンなどの挙動を設定しているのですが、実際の案件で使用する際に、それがむしろ冗長で必要がない時があります。
そういう場合このフレームワークだと、スタイルだけ使って、挙動部分は自分でJavaScriptを書いて適宜設定することができます。
ここまで3つ紹介してきましたが、つまりCSSフレームワークというのはUIコンポーネントの集合体のことで、「あるCSSフレームワークが作成したコンポーネントを元に、それぞれの制約に従いながらwebサイトを作らなければならない」というのがCSSフレームワークを利用する上での考え方になります。
しかし最近、ユーティリティファーストCSSという思考のもと、新しいCSSフレームワークが登場しました。
ボタンなら
書きやすくなったインラインCSSといった感じです。
今まで言われていたCSSフレームワークというのは、CSSの書き方がわからなくてもコンポーネントを使って簡単にwebサイトを作ることができるというアプローチでした。
しかし、実際にフロントエンドエンジニアが使用する時、BULMAの話で少し出たように、CSSフレームワークに定義されているデザインや設定のままでは対応できないことが多く、そうなると単純なプロパティの設定だけ提供してくれた方が柔軟に対応できるんじゃないかという考え方です。
そしてそれを取り入れたフレームワークが Tailwind CSS です。
ユーティリティファーストのCSSフレームワーク。
コンポーネントがない代わりに豊富なユーティリティクラスが用意されています。
全てのプロパティがセレクタとして提供されているイメージです。
昔はHTMLのテンプレートエンジンといったものがなかったので、CSSでコンポーネントの設定を行っていました。
例えば、カードやカルーセルなどのセマンティックなセレクタを作り、HTMLでそれらのセレクタを付与して見た目を変更する、カードのクラスのCSSを変更するとそれが全体に適用されるといったふうにコンポーネントの管理をしていたのですが、昨今の Vue.js や React を用いたフロントエンドの開発環境では、コンポーネントの概念は既にそれらが持っています。
なので、コンポーネント化はそれらを用いながらHTML側で行い、 CSS は抽象化したユーティリティクラスをコンポーネントの中に書けばいいのではないか、というところからこのフレームワークが生まれました。
そのために共通化であったり、名前付けをするのはもう少し後にしたいと思うことがあるかもしれません。
そういう時にこのフレームワークを使って先に実装を済ませてしまい、後からコンポーネント化しようというのが使用する上での考え方になります。
というわけで、これだけを使って昔ながらの静的なページを作ろうとすると、書いたものをコピペしながらまた書いてといったような無駄なことになってしまうので、テンプレートエンジンであったりコンポーネント化の仕組みがある上で成り立つフレームワークであると考えられます。
これまでのCSSフレームワーク、BootStrapやSemantic UI、BULMAなどを案件で使おうとすると、要件に合わせるためフレームワークの設定を上書きしなければなりませんでした。そんなことをするなら自分で一から作った方が都合がいいです。
CMSやバックエンドのものをチャチャッと作る時には便利ですが、サービスサイトなどには向きません。
その点、ユーティリティファーストCSSは導入しやすいのかなと思います。
とはいえ、こちらも他のフレームワークと同じように、ある制約の中で提供されているのは変わりません。そのためデザインによって対応できない時には自分でセレクタを追加する必要があります。
そういうことにならないようにデザイン・設計段階でフレームワークについて共有してルールを決めておき、そのルールから逸脱しないように進めていくことが肝要です。
実際に案件で使用する際は、デザイナーと密にコミュニケーションが取れる状態、またはデザインと実装者が同じ場合が望ましいでしょう。
今回は弊社の小泉が「最近のCSSフレームワーク動向の復習」というテーマで話しました。
群雄割拠なCSSフレームワーク界隈、BootStrap等のCSSフレームワークをおさらいしつつ、最近話題の Tailwind CSS が提案しているユーティリティーファーストCSSという設計思想についてゆるくご紹介します。
CSSフレームワークとは
なんとなく大げさな名前がついていますが、要するにスタイル設定が詰まったライブラリのことです。ボタンやフォーム、ドロップダウンメニューなど、様々なコンポーネントがあらかじめデザインとコーディングのされた状態で用意されています。
学習コストが低く、これを使うことで簡単にwebサイトをつくることができます。
有名なところだと BootStrap や Semantic UI など。少し特徴が異なるものに BULMA があります。
BootStrap
Twitter社が開発した、おそらく最も有名なCSSフレームワークです。
webサイトを構成する様々なコンポーネントやJavaScript用の拡張などが、HTMLおよびCSSベースのデザインテンプレートとして用意されています。
Semantic UI
MITライセンスを採用したオープンソースのUIフレームワーク。
BootStrap同様、多くのテンプレートが用意されており、セマンティック(意味のある)な形でCSSを設定できるのが特徴です。
BULMA
ここ数年で注目されるようになったフレームワークのひとつ。
このフレームワークが他のものと異なるのは、JavaScriptのフレームワークを提供していない点です。
いわゆるCSSフレームワークというのは、スタイルと一緒に JavaScript のフレームワークも提供していて、それによってドロップダウンなどの挙動を設定しているのですが、実際の案件で使用する際に、それがむしろ冗長で必要がない時があります。
そういう場合このフレームワークだと、スタイルだけ使って、挙動部分は自分でJavaScriptを書いて適宜設定することができます。
ここまで3つ紹介してきましたが、つまりCSSフレームワークというのはUIコンポーネントの集合体のことで、「あるCSSフレームワークが作成したコンポーネントを元に、それぞれの制約に従いながらwebサイトを作らなければならない」というのがCSSフレームワークを利用する上での考え方になります。
しかし最近、ユーティリティファーストCSSという思考のもと、新しいCSSフレームワークが登場しました。
ユーティリティファーストCSS
ユーティリティファーストCSSとは、プリミティブなユーティリティセットから複雑なコンポーネントを構築しようという考え方のことです。ボタンなら
.button 、フォームなら.formのように提供されていたコンポーネントはなく、フォントの色が白かつ太い場合なら.text-white .font-bold というふうに、インラインCSSのようなクラスを指定していき、コンポーネントに関しては実装者が作成するという形式のフレームワークになります。書きやすくなったインラインCSSといった感じです。
今まで言われていたCSSフレームワークというのは、CSSの書き方がわからなくてもコンポーネントを使って簡単にwebサイトを作ることができるというアプローチでした。
しかし、実際にフロントエンドエンジニアが使用する時、BULMAの話で少し出たように、CSSフレームワークに定義されているデザインや設定のままでは対応できないことが多く、そうなると単純なプロパティの設定だけ提供してくれた方が柔軟に対応できるんじゃないかという考え方です。
そしてそれを取り入れたフレームワークが Tailwind CSS です。
Tailwind CSS
ユーティリティファーストのCSSフレームワーク。
コンポーネントがない代わりに豊富なユーティリティクラスが用意されています。
全てのプロパティがセレクタとして提供されているイメージです。
昔はHTMLのテンプレートエンジンといったものがなかったので、CSSでコンポーネントの設定を行っていました。
例えば、カードやカルーセルなどのセマンティックなセレクタを作り、HTMLでそれらのセレクタを付与して見た目を変更する、カードのクラスのCSSを変更するとそれが全体に適用されるといったふうにコンポーネントの管理をしていたのですが、昨今の Vue.js や React を用いたフロントエンドの開発環境では、コンポーネントの概念は既にそれらが持っています。
なので、コンポーネント化はそれらを用いながらHTML側で行い、 CSS は抽象化したユーティリティクラスをコンポーネントの中に書けばいいのではないか、というところからこのフレームワークが生まれました。
案件への取り入れ方
フロントエンドの実装で大変なのは、セレクタ名を考えることだと思うのですが、実装を始める前に、あるコンポーネントをトップだけで使うのか、それとも汎用的に使うのかなどを決めるのは難しいです。そのために共通化であったり、名前付けをするのはもう少し後にしたいと思うことがあるかもしれません。
そういう時にこのフレームワークを使って先に実装を済ませてしまい、後からコンポーネント化しようというのが使用する上での考え方になります。
というわけで、これだけを使って昔ながらの静的なページを作ろうとすると、書いたものをコピペしながらまた書いてといったような無駄なことになってしまうので、テンプレートエンジンであったりコンポーネント化の仕組みがある上で成り立つフレームワークであると考えられます。
これまでのCSSフレームワーク、BootStrapやSemantic UI、BULMAなどを案件で使おうとすると、要件に合わせるためフレームワークの設定を上書きしなければなりませんでした。そんなことをするなら自分で一から作った方が都合がいいです。
CMSやバックエンドのものをチャチャッと作る時には便利ですが、サービスサイトなどには向きません。
その点、ユーティリティファーストCSSは導入しやすいのかなと思います。
とはいえ、こちらも他のフレームワークと同じように、ある制約の中で提供されているのは変わりません。そのためデザインによって対応できない時には自分でセレクタを追加する必要があります。
そういうことにならないようにデザイン・設計段階でフレームワークについて共有してルールを決めておき、そのルールから逸脱しないように進めていくことが肝要です。
実際に案件で使用する際は、デザイナーと密にコミュニケーションが取れる状態、またはデザインと実装者が同じ場合が望ましいでしょう。
今週のお茶菓子
