現代CSSフレームワークの内部実装とその仕組み BARフロントえんどう #2 「CSS Library / Framework」@ Cybozu 合同会社ぽてぽてランド
 poteboy

poteboy 自己紹介 t 合同会社ぽてぽてランド 代表社a t ほぼフリーランB t 最近やってること( t Frontend Ops/SR& t モバイルアプリ新規開 t SND t GitHub: potebo t X (Twitter): @_poteboy_

今、CSSフレームワークがアツい！！

開発者体験とパフォーマンスへの飽くなき探究心 ランタイムCSS-in-JSでは実行時にパースしてDOM操作して...(ry
 パフォーマンスに悪い！RSCで使えない！！ その問題を解決すべく、数々のCSSライブラリが作られてきた。(Panda, Kuma, StyleX, etc 解決したい課題は同じでも、それぞれアプローチがユニークでとても面白い！！ 本日は、そんな各CSSフレームワークの内部実装の仕組みをざっくり紹介します！

現代CSSフレームワークの仕組みは、大きく以下３つに分類される XW 静的解析Y a Kuma UI なC iW VM実行Y a Vanilla Extract なC 4W 仕様ハックY a CSS Hooks など


Ä 静的解析系 抽象構文木（AST)を走査して、抽出対象となるスタ イルを抜き取る。ロジックの実態はコンパイラ側で持 つ V 利` V xxx.css.ts の様にCSSファイルとJSX & Templateを分けなくて良い。→関心の分離を 技術単位でなくコンポーネント単位にでき5 V 欠` V 静的解析が難しい！単純なリテラルだけであれ ば解析は容易だが、変数の場合はフロー解析が 必要。

ÆÂ VM実行系 ASTを静的解析せず、作成した独自コンテキストを Node.jsのVMを用いて隔離されたサンドバックス環境 でコードを「実行する」S I 利a I 「実行」するので、JSの構文として正しく、 かつビルド時に決定できさえすれば、変数代入 でもInterpolationでも何でも対応できるS I 欠a I コードを「実行」する必要があるので、コン ポーネントの中に直接書けず、別ファイルに定 義する必要がある（コンポーネントでは、副作 用や非NodeのAPIが使用される）。

ÇÅ 仕様ハック系 CSSフレームワークが存在する唯一の理由は、インラ インスタイルで擬似要素やメディアクエリが使えない から。CSS変数の guaranteed-invalid valueという仕 様をハックして擬似要素にもスタイルを当てる„ B 利T B バンドラやプラグインが必要なくWeb APIなし で（ほぼ）ゼロランタイムを実現する„ B 欠T B バンドルサイズが上がったり、実行時のパ フォーマンスが懸念される。StyleXの作者は、 インラインスタイルはレンダリングのたびに再 計算する必要性から批判的。

つまりゼロランタイム系CSSフレームワークの課題は..! Q JSX（やテンプレート）にCSSを書けるようしたら表現力が下が% Q 表現力を上げようと思ったら別ファイルに書く必要があ% Q 実行時に動的に決定される値はどちらにせよ無 Q やろうと思ったら、パフォーマンスが犠牲になる

そんな中今個人的に注目しているのが、 WyW-in-JS ゼロランタイムCSS-in-JSライブラリを構築 するための開発者向けライブラリ。
 ゼロランタイム系の課題だった「同じファイ ルに書けてかつ表現力もある」を実現しよう としていて、Linariaの内部でも使われてい る。
 https://github.com/Anber/wyw-in-js

WyW-in-JSのアプローチ 1/2 WyWは、変換対象だけをトップレベルにホイスト（巻き上げ）して、ホイストしたものだ けを実行する。つまり①静的解析 と ②VM実行 の合わせ技

WyW-in-JSのアプローチ 2/2 他のファイルからインポートしている場合は、依存先のファイルだけ実行することで、値 が解決され他場合に置き換えればいい（そのファイルも他ファイルに依存している場合は 深さ優先探索的にLeafから順に実行する）。
 すなわち、Hoistingの静的解析を頑張るのはエントリーファイルだけで良い！

つまりゼロランタイム系CSSフレームワークの課題は..# P JSX（やテンプレート）にCSSを書けるようしたら表現力が下がる
 P 表現力を上げようと思ったら別ファイルに書く必要がある
 P 実行時に動的に決定される値はどちらにせよ無理 逆にここまでできたら、かつて（ランタイム）のDXを取り戻せる ️→ WyW-in-JS で解“ ️→ WyW-in-JS で解“ ️ → WyW-in-JS で解決できない 　　

今後のCSSフレームワークの方向性 現状のWyWは一定の条件下でキャッシュのInvalidationが出来ないのでHMRが効かずまだ 本番投入はできないが、静的解析＋VM環境での実行は筋が良いと感じている！ これでビルド時に決定できる値については殆どカバーできそう。 また、実行時に値が確定する値についてはCSS HooksのようにCSS変数 + インラインスタ イルに逃すことで、どんな書き方でもRSCで動く未来は実現できそう！（ちなみに、Vueの コンパイラもv-bindで定義したスタイルをCSS変数の guaranteed-invalid valueを使って インラインで埋め込んでいる） → これがまさにKuma UIがv2で実現しようとしている世界。



おわりに 各CSSフレームワークの実装アプローチについて説明しながら、CSSフレームワークの今後 やKuma UIの展望についてお話ししました。 今日お話しした内容を踏まえ、近々（10日以内）Kuma UIのGitHubでもv2に向けてRFCを 書くので、この発表が参考になったという方はぜひチェックしていただけると嬉しいで す！ ご静聴ありがとうございました！ https://github.com/kuma-ui/kuma-ui