プロジェクトの特性別・CSSスタイリング手法の個人的な選び方

公開タグ:

Webサイトを作るときのスタイリング手法にはCSS設計、CSS Modules、Tailwind CSS、CSS-in-JSなど、色々あります。

どれを採用するかは、プロジェクトの技術構成や規模、寿命、メンバーの知見がどの程度かによって変わります。

この記事では自分だったらどういう基準でスタイリング手法を選ぶかを書いていきます。

まず結論から

  • スコープを閉じられない → CSS設計
  • 命名を統一しきれない → Tailwind CSS
  • テンプレートファイルに書ける → スコープ付きのstyle
  • 書けない → CSS Modules、型で守りたいなら CSS-in-JS
  • 迷ったら依存が少ない方

手法選択のフローチャート

フローチャートにするとこんな感じです。

スコープを閉じる仕組みがあるか
├ ない → CSS設計
└ ある
  └ 命名を統一しきれるか
    ├ しきれない → Tailwind CSS
    └ しきれる
      └ テンプレートファイルにスタイルを書けるか
        ├ 書ける → スコープ付きのstyle
        └ 書けない
          └ 型でスタイルの逸脱を防ぎたいか
            ├ 防ぎたい → CSS-in-JS
            └ そこまで不要 → CSS Modules

上から順に見ていきます。

ケース別の採用手法

スコープを閉じる仕組みがないとき: CSS設計

素のHTMLやWordPressのクラシックテーマ開発などが該当します。スタイルのスコープを閉じられないケースです。

この場合はスコープを命名で表現するしかないので、CSS設計を使います。一般的によく使われるのはBEMでしょうか。個人的に好きなのはPRECSS（新しいタブで開く）です。

デメリットは実装者に命名の労力を要求することです。規約を決めても守られなければ意味がありません。とはいえStylelintで規則をある程度強制できますし、今だったらAIを使うこともできます。ただしリンターで押さえられるのは形式の部分だけです。どんな名前をつけるかの揺れは人数が増えるほど防ぎにくくなります。

なお、ビルド環境を用意できるならこの環境でもTailwind CSSを使えます。命名の労力そのものをなくせるので、こちらも選択肢になりますね。

命名を統一しきれないとき: Tailwind CSS

複数人で開発していると命名は揺れます。CSSの知見にばらつきがあればなおさらです。

Tailwind CSSを採用すればクラスの命名自体が不要になります。命名の属人化がなくなるのは複数人での開発では大きなメリットです。ブレイクポイントや単位のrem統一といったスタイリングの基盤も自動で整います。このあたりを自前で用意しなくていいのは楽ですね。

デメリットはCSSとしての可読性が低くなることです。あと任意値を使うとエラーなしでデザイントークンから簡単に外れてしまうのも難点ですね。また、マークアップ全体がTailwind CSSの書き方に染まるため、他の手法への乗り換えは大がかりになります。

テンプレートファイルにスタイルを書けるとき: スコープ付きのstyle

AstroやSvelte、VueのSFCならテンプレートファイル内に直接スタイルを書けます。マークアップとスタイルが同居してくれるので、個人的には可能ならこれを選びたいです。

スコープが閉じているのでクラスの命名でスコープを表現する必要はありません。ただしスコープがあるとはいえ、何かしらの命名規則はあったほうがいいと思います。シンプルに英単語のハイフンつなぎでもいいですし、CSS設計手法から拝借するのもよいでしょう。

個人的にはPRECSSの命名規則を採用しています。階層の区切りがアンダースコアで、複数単語はキャメルケースというルールです。

書けない・型で守りたいとき: CSS-in-JS

ReactやNext.jsではテンプレートファイル内に素のCSSを書けません（Next.jsではstyled-jsxを使えば可能にはなります）。その中でスタイルに型を持ち込みたいならCSS-in-JSが選択肢になります。定義されていない値を型で弾けるので、スタイルの逸脱を防げるのが強みです。

複数人開発かつコンポーネント指向が強いプロジェクト、個人的にはStorybookのようなUI管理ツールを採用するレベルの規模感のプロジェクトに向いていると思います。

ライブラリの選択の候補としてはPanda CSS（新しいタブで開く）やStyleX（新しいタブで開く）あたりでしょうか。styled-componentsのようなランタイム方式はReact Server Componentsとの相性が悪く、選択肢から外れつつあります。

デメリットはビルドツールへの依存が増えることです。また、Tailwind CSS同様、他のライブラリに乗り換える場合にコストがかかります。長く運用するプロジェクトほど無視できないコストになります。寿命が長いなら依存の少ない手法を選んでおくのが無難ですね。

書けない・型は不要なとき: CSS Modules

ReactやNext.jsでTailwind CSSを使わないときの選択肢です。

スコープ付きのstyleと同様、何かしらのクラス名の命名規則はあったほうがいいと思います。

まとめ

この記事では自分だったらどういう基準でスタイリング手法を選ぶかを書きました。

  • 採用する技術やプロジェクトの規模や寿命、メンバーの知見がどの程度かによる
  • 迷ったら依存が少ない方を選ぶのがいいのでは

私個人としては、スコープ付きのstyle + PRECSSの命名規則、という方法でスタイリングすることが多いです。最近のプロジェクトはほぼAstroですし、実装も保守も私一人だけ、CSSも苦ではないからです。

スタイリング手法に唯一の正解はありません。プロジェクトの特性から考えていくと選びやすくなるのではないでしょうか。