フロントエンド周りの技術は驚異的なスピードで進化し、また多様化しています。それらを全てマスターするのは途方もなく大変なので、ペパボでは、社内のエンジニア・デザイナが「最低限これだけはおさえておこう」というスタンダードを文書化することにいたしました。社内向けを想定した文書ではありますが、社内のみに留めず多くの方に役立てたいと考えたため公開します。
- この項目の担当 @horaotoko
1. はじめに
このページでは、身の回りにある多種多様な CSS フレームワークと、私たちはどうやって付き合っていけば幸せになれるのかということについて述べていきます。
CSS フレームワークの紹介や導入についての記事は世に多くありますが、そもそも CSS フレームワークをどうやって利用していくべきか？ということに関してはあまり言及されていません。おそらくは、プロダクトの兼ね合いでその使われ方は大きく左右されるため、一貫した利用方針が設定しづらいからでしょう。
しかし「運用しやすさ」という観点から、フレームワークの利用には一定の方針を設けるべきだと考えています。スタイルシートの書き方という意味ではなく、どんなときに、どんなフレームワークを利用すべきなのか？という意味です。方針を決めておくことで、CSS フレームワークがもっと扱いやすくなります。
2. CSS フレームワークの分類
どんなときに、どんなフレームワークを利用すべきかについて述べる前に、私たちが CSS フレームワークどのようにを捉えているのかについて述べ、頭を整理してみます。
(1) "レイヤー" で考えてみよう
CSS フレームワークを利用する最大の目的は作業時間を短縮することにあります。過去に誰かがつくった汎用的なコンポーネントなどを流用することで、自分で HTML や CSS を書く手間を減らし、作業時間を短縮するのです。たとえばグリッドレイアウトを実装したいとき、1から自分で書くのと、Susy のような既存フレームワークを使うのとでは、作業に費やす時間は大きく差があるでしょう。
CSS フレームワークの導入を検討する際には、前述のように、どこからどこまでフレームワークを活用してプロダクトを構築するかという「流用」をする範囲の決定をします。つまり、利用するフレームワークの種類を決める段階になります。範囲をザックリと定義してみると、下記の図のようになっています。
（図1 フレームワークの階層構造）
フロントエンド上で実装されるレイヤーとして定義してみました。コード上では、まずは初期化するためのスタイルがあり、それを利用してコンポーネントやヘルパークラスなどが設計されています。Sass版のBootstrapのコードを読むと CSS フレームワークが階層構造でつくられているのがわかるでしょう。それぞれのレイヤーに役割があり、フレームワーク導入の際には、上記のどのレイヤーを置換するかということを決めます。
あと、今回は話が少し大きくなってしまうので記述はしませんが、このなかにはユーティリティとかヘルパーと言われるクラスやミックスインが存在します。たとえば clearfix や button-primary なんかがありますね。多くの CSS フレームワークにはいわゆる便利ツールが内包されています。
さて、話を戻しましょう。大きく 3つのレイヤーに分解しましたが、これもさらにグルーピングしたいと思います。プロダクトのフロントエンド面の 土台になる層（ファウンデーション、レイアウト） と、クリエイティブ面でのプロタクト独自の特色を出すための 見た目（コンポーネント）になる層 に分けましょう。これを分けて考えることで、フレームワークの使い分けがしやすくなります。詳しくは後述します。
(2) 2つのグループに分類しよう
世の中には数多くの CSS フレームワークが出回っています。真っ先に思い浮かぶのは Bootstrap じゃないでしょうか。他にもいろいろと種類はありますが、私たちはそれらを吟味し、自分が作りたいものに適したツールを選択します。
さて、CSS フレームワークの導入を検討する際は、どのレイヤーを置換するかかということが導入基準になるという話をしましたが、今度はそのレイヤーという概念を使って、世の中にあるCSSフレームワークをバスっとふたつに分類してみます。
これまでに出てきた Bootstrap と Susy なんかは良い例でしょう。この 2つの違いは 複数のレイヤーにまたがったフレームワーク であるか ひとつのレイヤーに特化したフレームワーク というところにあります。
複数のレイヤーにまたがったフレームワークである Bootstrap は、ファウンデーションからレイアウト、コンポーネントの部分もまるっと実装しているのに対し、シンプルにひとつのレイヤーに特化したSusyは、レイアウトのレイヤー専門のフレームワークです。また中にはコンポーネントだけカバーしているものも、初期化機能だけカバーしているものもあります。
これらをこのパートでは、便宜上前者を フルスタックフレームワーク に、後者を 単機能フレームワーク と呼びたいと思います。図にすると以下のようになります。
（図2 フレームワークの階層と分類）
世の中には様々な CSS フレームワークがありますが、基本としてはどのレイヤーをカバーしているフレームワークなのかというところに注目すれば、うまく付き合っていくための対処ができるでしょう。
3. CSS フレームワークの使い分け - フルスタックと単機能
数ある CSS フレームワークがどのような構成になっており、そしてそれをどのように分類するかについて述べました。では今度は、実際にそれらをどのように利用するべきか、どのように付き合っていくべきかについてご紹介します。
(1) 使い分けの基本方針
先に簡潔に結論を述べると 土台になる層（ファウンデーション、レイアウト）の実装には CSS フレームワークを使ってもいいが、見た目となる層（コンポーネント）の実装の際はなるべく使わない ことを推奨します。
車輪の再発明をやめよう
上記、図1の線より下の土台レイヤーに関わるスタイルシートは、言わば車輪の再発明になりがちな部分です。イニシャライズやグリッドレイアウトなどは既に定型的な解決策が多く、自らが1からコードを書く必要がないこともしばしばありますし、もしなんらかの事情によってそれまで利用していたフレームワークが使えなくなってしまった場合でも、代替となるフレームワークに移行しやすいです。
基本的には、フレームワークを使ってみて、足りなかったり微調整したりしたいところがあればその都度コードを書き足していくという運用でよいでしょう。Sass が使えるような環境であれば変数を上書きすることで細かい調整も可能なので、なおさら自らコードを書く手間を省いていきましょう。
プロダクトの「見た目」は自分でつくろう
それに対して線より上のコンポーネントレイヤーは、他のレイヤーに比べてプロダクトに取り入れるリスクが高いと考えています。以下にそのリスクを書いてみました。
- UI がフレームワークに依存した見た目やインタラクションになる
- フレームワーク自体がアップデートされた際に UI の調整が発生する可能性がある
- フレームワークのスコープの関係で修正用のスタイルシートの管理が煩雑になる
フレームワークに依存したクリエイティブになることは、フレームワーク導入のデメリットとしておそらく以前から言われていることでしょう。「Bootstrap ライクな見た目」なんて言葉もありました。もし自分が関わっているプロダクトで独自の UI デザインを実装したいのであれば、コンポーネント機能の利用は避けるべきです。
とりわけ経年変化に対して弱いこともフレームワーク利用のデメリットとなる点です。プロダクトの見た目の大部分をフレームワークに依存してしまう場合は要注意です。
あまりにもクリエイティブがフレームワークに依存しすぎていると、フレームワーク自体のアップデート時に移行がスムーズに進まないことがあります。Bootstrap2 から Bootstrap3 に移行したときの悪夢を思い出してみてください。ローカル環境で確認したらあちらこちらで表示崩れが起きてて絶望するというのはプロダクトの継続にも精神にも悪影響ですし、なによりその修正に時間がかかって作業遅延が発生してしまうことは、大きな痛手となります。
また、ほかのプログラミング言語と違い、CSS の場合はページごとに読み込むファイルを分けるなどの対処をしない限り、どこのページであってもスタイルが適用されるといった独特な「スコープ」の問題があります。それによって大きいプロダクトになっていくにつれて、自分でも思ってもみなかったところでレイアウト崩れや、最悪プロダクトの機能を一部利用できなくなっているなどの状況に陥ることになる可能性があります。もし 100ページ以上もあるような web サービスならどうでしょうか。確認しなければならないページが大量に見つかるでしょう。
以上のリスクの点から、フレームワークのコンポーネント機能はなるべく使うべきではないと考えています。しかし、それでもコンポーネント機能は便利な一面もあります。そのため絶対に使うなとは言えませんし、利用するメリットの方が大きいのであれば、利用する意図をしっかりと認識したうえで使い分ける必要があります。
(2) フレームワークの種類ごとの用途
フルスタックフレームワーク
フルスタックフレームワークを使う場合は具体的には以下のような状況がいいでしょう。
- メンテナンスしない賞味期限が短いページをつくる ex)期間限定の特集ページなど
- お客さんの目に触れないページをつくる ex)業務改善ツールなど
- 新規プロダクトのプロトタイプをつくる
つまりは、制作しようとしているものの「見た目」に、フルスタックフレームワークが提供しているコンポーネントのスタイルシートが関与しても構わない場合です。具体的には、少ない手間である程度のクオリティのものを作る必要があったり、お客さんが操作せず重要な情報に関与しないページをつくったりする場合です。
たとえばこんなフレームワークたち。
単機能フレームワーク
利用にあたっての基本方針のところで述べたように、プロダクトの土台となるようなレイヤーのスタイルシートは車輪の再発明になりがちになります。よって土台となるレイヤーに CSS フレームワークを利用することは推奨できます。その際に便利なのが単機能フレームワークです。例えば以下のような場合では単機能フレームワークが有効です。
- いい感じにイニシャライズだけしてほしい
- 手っ取り早くグリッドレイアウトを実装したい
- ベンダープレフィックスをいちいちつけるのがめんどくさい
フルスタックフレームワークを利用していれば機能的には事足りますが、用途によっては都合の悪いこと（過剰すぎる機能や、既存 CSS や JS と競合するなど）があります。特に「見た目」となるレイヤーに影響が出てしまうリスクを考えると、単独機能のみを提供する、どちらかというとライブラリのような専用フレームワークを利用するほうが、プロダクトを管理しやすいでしょう。
たとえばこんなフレームワークたち。
単機能フレームワークはそれぞれ以下のような機能を提供しています。
- イニシャライズ
- スタイルの初期化をする機能
- ex. CSS Reset、Normalize.css
- ユーティリティ/ヘルパー
- レイアウト
- グリッドデザインやレスポンシブデザインを実装する機能
- ex. RESPONSIVE GRID SYSTEM、MUELLER、Susy
- コンポーネント（非推奨）