Closed8
メモ：CSS in JSとは何か
ピン留めされたアイテム
TK記事書いた。
TK今新しいアプリケーションの立ち上げをしていて、CSSフレームワークの選定をしている。
たくさんのオプションがあるなか、最近はCSS in JSのフレームワークが数多くある中、そもそも"CSS in JS"ってなんだっけ🤔って立ち返って、色々記事を当たりながら整理してみようと思う。
TK
なにか
- JavaScript を用いて CSS を記述するアプローチ
- コンポーネントに属する CSS 定義をバンドルするライブラリ
- CSS はコンポーネントに定義され、外部の CSS ファイルに依存することなく、コンポーネント単体で独立して動作する
何を解決しているか
- グローバルな CSS を利用している場合、CSS の定義を変更した際にどこへ影響があるか分かりづらい（CSS 設計が必要になる）
- =>あるコンポーネントの CSS 定義を変更しても他のコンポーネントへの影響がなくなる
メリット
- カプセル化（上記と同じ）
- メンテナンス性
- 細かいCSS設計（セレクタ階層、命名規則）が不要に
- 動的スタイリング
- 移植性
- 他のプロジェクトで簡単に共有再利用できる
デメリット
- 可読性
- 生成されるクラス名が読めない
- CSS in JSの記法が独特（ライブラリによる）
- 移植性
- CSS => CSS in JSは難しい
- 学習曲線
- パフォーマンス
TK
パフォーマンス
- サイトの負荷パフォーマンスを気にするならば、ランタイムCSS-in-JSは使わない。単純にJSが少ない＝サイトが速い。
Don’t use runtime CSS-in-JS if you care about the load performance of your site. Simply less JS = Faster Site. There isn’t much we can do about it. But if you want to see some numbers, continue reading.
SPAでのstyled-components vs linaria
- linaria
- ゼロランタイムcss in js
- ビルド時にCSS in JSのコードからCSSを抽出してくれるツール
- ゼロランタイムcss in js
- Lighthouseを使ったパフォーマンス計測では、Linariaが両ページともにすべての項目で読み込み時間が短かった。
TK
- JavaScriptで定義されたCSSを解析し、CSSにマッピングされたJSX要素を作成する
TK
emotion
利点
- CSSとの連携を考えなくて良くなる
デメリット
- JSのランタイムに実行されるため、パフォーマンスに問題がある。
linaria
利点
- パフォーマンスの問題を解決
- コンパイル時にPostCSSによるカスタマイズが可能
デメリット
- ランタイムでemotionほど柔軟性がない
- css propsが使えない、cssプロパティの出しわけができない
TK
- Reactプロジェクトの60%くらいがcss in jsを使っているらしい
メリット
- DOMへの負荷軽減
- CSSとコンポーネントを同じファイルに定義するため、コンポーネントのロード時にのみコンポーネント用のCSSがロードされ、仮想DOMへの不要な負荷が軽減される
- より良いCSSのエラーハンドリング
デメリット
- スタイルが二重に解析(purse)される。一度はライブラリによって解析され、次にスタイルが挿入されるときにブラウザによって解析される
- ブラウザはCSSスタイルタグを動的に生成し、それを読み取ってウェブページに適用する。この読み込みと生成にパフォーマンス上の時間がかかる
- 従来は、ウェブページを読み込むと、ブラウザはCSSを読み込んで適用するだけ
ゼロランタイム
- 二重解析によるパフォーマンス時間の損失を改善するための解決策
- ライブラリがCSS-in-JSブロックを最初に別の.cssファイルに変換すること
- ブラウザがこれらのスタイルを読み込んでウェブページに適用し、最終的にスタイルタグを生成する際に通常浪費されるランタイムを節約する
- ライブラリがCSS-in-JSブロックを最初に別の.cssファイルに変換すること
- パフォーマンスが重要な、規模が大きいプロジェクトや複雑なプロジェクトで特に有用である。
TK
"ゼロランタイム "とは、CSS-in-JSの構文でスタイルを作成するが、生成されるのは他のCSSプリプロセッサが生成するような.cssファイルである。
このスクラップは2022/07/17にクローズされました