2024年のCSSの書き方、ワークフローとツールについて

Post on:2024年1月18日

CSSには大きく変わるタイミングが何度かありました。レスポンシブ対応、メディアクエリ、Flexbox、CSS Gridなどはその大きく変わったタイミングでしょう。

そして、2024年もこれらと同様に大きく変わりそうです。CSSのネスト、:has()疑似クラス、subgrid、コンテナクエリ、ビューポート単位などの新機能がすべてのブラウザにサポートされました。

2024年のCSSの書き方として、より保守しやすいCSS、ワークフロー、ツールについて紹介します。

2024年のCSSの書き方、お勧めのワークフローとツール

How I'm Writing CSS in 2024
by Lee Robinson

下記は各ポイントを意訳したものです。
※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。

はじめに

2024年のCSSは、素晴らしいの一言に尽きます。

  • CSSのネスト、:has()疑似クラス、コンテナクエリなど、さまざまな新機能がすべてのブラウザにサポート。
  • 強力で高速な新しいCSSのツール。
  • CSSの読み込みパフォーマンスを最適化する多くのフレームワークとコンパイラ。

この記事は、CSSのエコシステムと現在使用しているツールについて私の考えをまとめたものです。

すべてのブラウザにサポートされるCSSの機能は他にも、<easing-function>, subgrid, ビューポート単位（lvh, svh, dvh）, カラースペース, @layerがあります。詳しくは、当ブログの記事をご覧ください。

デザインの制約

ユーザーエクスペリエンス

Webサイトのアクセス時にスタイルシートを読み込むときの素晴らしいエクスペリエンスとは、どのようなものでしょうか？

  1. スタイルシートは可能な限り、高速に読み込まれるべきです（小さなファイルサイズ）。
  2. スタイルシートは変更されない限り、再ダウンロードしない（適切なキャッシュ）。
  3. ページのコンテンツは、レイアウトのずれがまったくないか、最小限である。
  4. フォントは可能な限り、高速に読み込まれレ、レイアウトシフトを最小限に抑える。

デベロッパーエクスペリエンス

わたし達のツールは、より良いユーザーエクスペリエンスを生み出すのに役立つものでなければなりません。デベロッパーエクスペリエンスは重要ですが、ユーザーエクスペリエンスより優先されるものではありません。

わたし達が使用するスタイリングツールのDXは、より良いUXを生み出すためにどのように役立つでしょうか？

  1. ファイルサイズを小さくするために、使用されていないスタイルを削除し、CSSを圧縮・軽量化します。
  2. ハッシュ化されたファイル名を生成し、安全で普遍なキャッシュを実現します。
  3. CSSファイルをひとまとめにすると、ネットワークのリクエストを減らせます。
  4. 名前の衝突を防ぎ、視覚的な退化を回避します。

より保守しやすく、書いてて楽しいCSSにするにはどうすればよいでしょうか？

  1. UIのコードを削除するとき、CSSの削除も簡単にできる。
  2. デザインシステムやテーマへの準拠が簡単にできる。
  3. TypeScriptサポート、オートコンプリート、lint機能によるエディタのフィードバック。
  4. エラーを防止するためのツールフィードバックをエディタ内で受け取る（タイプチェック、lint）。

2024年のCSS

2024年のCSSはツールを使用せずに、優れたスタイルを書くことがこれまでになく簡単になります。

以下では、クロスブラウザに対応したモダンCSSの機能の多くをビルドステップなしで使用しています。SassやLessはもう必要ないかもしれません。

デモのキャプチャ

デモページ

ということは、ツールはもう必要なくなるのでしょうか？
一部の人にとってはそうです、と言えます。

ビルドステップ

前述のデザインの制約を満たすためには、ビルドステップが必要になる可能性があります。

なぜなら、すべてのユーザーがブラウザの最新バージョンを使用しているとは考えられないからです。しかし、もっとも重要なことは、まだサポートされていない機能をクロスブラウザで使用したいと思うことが常に存在することです。

@supportsルールでブラウザのサポートをチェックすることができますが、それは問題の一部を解決しているにすぎません。CSSの最適化を人間の力に頼るのではなく、機械に任せてみてはどうでしょう？

コンパイル

コンパイラを使用すると、次のワークフローが簡単になります。

  1. 使用されていないスタイルを自動的に削除し、ファイルをひとまとめにしてネットワークのリクエストを減らし、ベンダープレフィックスを追加し、スペースやコメントを削除して、ファイルサイズを最小化します。
  2. 一意のファイル名を自動的に生成し、フレームワークがコンテンツを変更されないようにキャッシュヘッダを設定できるようにします。
  3. ターゲットブラウザ（Browserlist）を指定し、それらのブラウザで動作するモダンCSSををコンパイルするために構文を下げます（Lightning CSS）。

ストリーミングCSS

あなたは飛行機を予約するためにGoogleにアクセスしたとします。Googleはあなたの意図を事前に理解することはできないため、最初のUIには検索ボックスが表示されています。「飛行機 ニューヨーク行き」と検索すると、Googleは日付を選択するためのフライトウィジェットを表示します。

Googleが事前に考えられるすべてのウィジェットを表示することは不可能です。通貨換算、タイマー、スポーツのライブスコア、ほかにもたくさんのものがあります。これらのウィジェットのUIとスタイルは、動的にストリーミングされる必要があります。

React（とNext.js）は現在、ストリーミングSSRとCSSでこのパターンをサポートするようになりました。Reactモデルでは、スタイルに依存するコンポーネントとしてUIを定義しています。ページ上の何かに影響を与えることなく、ウィジェットのスタイルを安全にストリーミングするにはどうすればよいでしょうか？

スタイルはスタイルがスコープされる、つまりアトミックである必要があり、そのスタイルが意図するDOMコンテンツよりも早く読み込まれた場合でも、ページ上の要素のスタイルが変更されることはありません。

たとえば、CSSモジュールにはそれをインポートするコンポーネントにスコープされたスタイルルールを持ちます。Tailwind CSSではアトミックユーティリティクラスを使用します。このクラスはクラスが使用される前に読み込まれる1つのスタイルシートにコンパイルされます。StyleXはアトミッククラスも生成しますが、グローバルスタイルはストリームの最初に読み込まれない限り、ストリーミングではうまく機能しません。

お勧めのCSSツール

CSSモジュール

CSSモジュールはバニラCSS上にある、小さいながらもインパクトがある機能拡張です。

わたし達が望むUXの制約と、DXの制約のほとんど（すべてではありません）を実現します。CSSモジュールはすべてのモダンなバンドルとフレームワークで利用できます。既存のCSSセレクタをコピペすると、変更を加えることなく動作します。

アトミックスタイルを生成することはできません。多くのテーマの使用はサポートされていません（CSS変数のみ）。また、スタイルのコードはTypeScriptファイルの外部に存在するため、タイプセーフティやオートコンプリートは利用できません。しかし、そういった制約はあまり問題ないでしょう。

CSSモジュールをサポートするLightning CSSはViteで使用されており、Twilwind CSSとNext.jsでもまもなく使用される予定です。PostCSSやAutoprefixerのようなツールは、より高速でオールインワンのRustツールチェーンに置き換わろうとしています。

Tailwind CSS

Tailwind CSSはコンパイラを使用して、使用されるクラスだけを生成します。ユーティリティのCSSフレームワークには多くのクラス名が含まれますが、コンパイルされた単一のCSSファイルには使用されるクラスのみが含まれます。

Tailwind CSSのコードのみを記述すると仮定すると、バンドルが使用されるTailwind CSSクラスの合計セットより大きくなることはありません。すべてを使用する可能性は極めて低いです。これは生成されるCSSファイルのサイズの上限が決まっており、最適なパフォーマンスを得るために縮小・圧縮、およびキャッシュされることを意味します。

Tailwind CSSは、スタイルだけを書く必要はありません。Tailwind CSSのクラスは、デザインシステムに準拠したCSSの通常のユーティリティにすぎません。たとえば、Tailwind CSSとCSSモジュールを組み合わせて使用することもできます。

Tailwind CSSにトレードオフがないわけではありません。これと組み合わせるツールがたくさんあります。

  • VSCode integration: VSCodeでオートコンプリート、リンティング、構文ハイライトができます。
  • Prettier integration: クラス名の自動ソートができます。

Tailwind CSSについてもっとも物議を醸している部分は構文です。愛されてもいるし、嫌われてもいます。私はTailwind CSSを使用して何かを作ってみるまで、Tailwind CSSの良さを理解していませんでした。そのため、まだの人はTailwind CSSをまず使用してみることをお勧めします。

デモのキャプチャ

デモページ

StyleX

ほとんどのCSS-in-JSライブラリには、2つの問題があります。

  1. パフォーマンス: コンポーネントはJavaScriptで記述されたスタイルをCSSに変換し、レインダリング時にドキュメントに挿入する必要があります。これには大きなコストがかかるため、StyleXのような「ゼロ ランタイム」ライブラリへの移行が進んでいます。
  2. 互換性: 既存のCSS-in-JSライブラリの多くはReactのストリーミングサーバーレンダリングのサポートを追加していますが、アプリケーションの一部をReact Server Componentsに移動するなど、他のパフォーマンス最適化とはまだ互換性がありません。

このような問題を解決するために、Vanilla ExtractやPandaなどの「ゼロ ランタイム」CSS-in-JSライブラリが作成されました。

そして、StyleXもこれらの問題を解決する最新のCSS-in-JSライブラリです。StyleXをさらに詳しく知りたい方は、「Thinking in StyleX」をご覧ください。

このデモページは、私が初めてStyleXを使用したものです。オープンソースとしてはまだ新しいものですが（そしてエコシステムもそれを反映しています）、新しいライブラリではありません。Facebook、Instagram、WhatsApp、Threadsなど多くのメタサイトを動かしています。

しかし、やはり名前を付ける必要があります。buttonWrapperContainerなど。

終わりに

CSSは楽しいですか？
はい、とても楽しいです。そして、これから何が起こるかも楽しみです。

あなたなら何か違うものを選んだでしょうか？ また、何か見逃したものはありますか？ @leeerobに知らせてもらえると、嬉しいです。

sponsors

top of page

©2024 coliss