Kuma UIの設計思想と頑張らないゼロランタイムCSS-in-JS

Kuma UIの設計思想と頑張らないゼロランタイムCSS-in-JS フロントエンド技術選定 ~ゼロランタイムCSS in JSとTailwind CSS編~ @ Findy
presented by poteboy

poteboy 自己紹介個人開発合同会社ぽてぽてランド（登記中）の1人代表（予定S 要するに今は無職g Kuma
UI というOSSの作ゼロランタイムCSS-in-J4 詳しくは以下のリンクまで SN4 GitHub: potebo X (Twitter): @_poteboy_ https://www.kuma-ui.cog

w ユーティリティファースj w Chakraやxstyled、Native Baseに近É w ゼロランタイムCSS-in-Jd w 最適化はベストエフォーj w
動的な値はランタイムで挿入すE w ヘッドレスなコンポーネント群のみ用7 w デザインシステム前提のため、デフォルト  で色付けはしていない w コンポーネントというより、HTMLタグの  ラッパーに近É w Theme Configからデザイントークンを設定 Kuma UI とは

Kuma UI の設計思想とは？

Kuma UI は、パフォーマンスに特化している →わけではないよくある誤解：もちろんパフォーマンスも優れているが、それが至上命題ではない

Kuma UIの目的はDX維持＆エコシステムへの追従 Kuma UIチームとPanda CSSチームの見解としては、Utility First & CSS-in-JSが最も  Maintainabilityの高いスタイリング手法だと考えている。  Tailwind
CSSの作者であるAdam氏も、「（インラインスタイルでCSSの全てを表現する）ことをブラウザが対応していない事実こそが  CSSフレームワークが存在する唯一の理由だ」  と言っている。個人的にも、この意見に完全に同意。

Kuma UIの目的はDX維持＆エコシステムへの追従 Utility First & CSS-in-JS は個人的には最高のスタイリング技術だった。しかし、React Server Componentsの影響で、サーバーでのみ動作する（Web
APIを使わずに  済む）スタイリング技術し生き残れなくなりつつあった RSCのせいで自分の好きな技術であるCSS-in-JSが技術選定の選択肢から外れるのは嫌だったそうならないようにするために、RSCで動くUtility FirstなCSS-in-JSという選択肢をコミュニティに残そう→Kuma UIの出発点つまり、Kumaの目標はPerf以上に、従来の書き心地（DX）とエコシステムへの互換性を重視

Kuma UIの最適化はベストエフォート DXと互換性を実現するための手法が「Hybrid Approachg 静的解析可能なスタイルはゼロランタイムで8 静的解析不可能な箇所はランタイム（＋SSR）で。 Hybrid法を使うとKumaの実装がツリーシェイクされずにバンドルに残るという欠点はあるが、  従来の書き方で実行時パフォーマンスが改善されているかつRSCで対応できる。
  Hybrid法に関する詳しい解説はKumaのメンバー  のYuku Kotani氏の記事を参考に

そもそも、ランタイムCSS-in-JSは  本当にパフォーマンスが悪いのか？

CSS-in-JSのパフォーマンスの比較以下の条件で比較すC 4 ゼロランタイムCSS-in-JS ＋RSP 4 ランタイムCSS-in-JS (SSR) + Client
Componen 4 ランタイムCSS-in-JS + Client Component (Lazy Load) 同一スタイルを当てたボタン1000個をレンダリングしてみる

ゼロランタイムCSS-in-JS ＋RSC LCP1.25s page.css事前生成され、page.jsはブラウザ実行されない（layout.jsはプロバイダーコンポーネント分の実行）

ランタイムCSS-in-JS (SSR) ＋Client Component LCP1.20s Kuma UIのNextプラグインを外した→コンパイラに介入しないので全てSSRになる。  SSR環境では、useServerInsertedHTMLを使用しサーバでHTMLを出力時にスタイルを挿入する） page.jsでHydrationが実行され、cssファイルを読み込まずDOMに突っ込む

ランタイムCSS-in-JS (Dynamic Import) ＋Client Component LCPはめっちゃ早い、でもスタイルが当たるまでかなり時間を要してFOUCが起こる

計測結果から分かる通り、SSRしてればランタイムCSS-in-JSでもすごく速い！なので、（少なくともKumaにおける）ゼロランタイムCSS-in-JSの意義は、パフォーマンスより  エコシステム互換性。 React Compilerと同じで、Kumaのコンパイラはあくまで最適化の手段。一部機能を除いて、コンパイラがなくても動く。 2026年には3G回線も廃止され、実行時Perf向上の旨みはそこまでない現実的なユースケースとして、 Cloudflare Pagesなどサイズにシビアな環境にデプロイする場合は、Kumaのコンパイラを使って 
ツリーシェイクした方が良い。

まとめ：頑張らないゼロランタイムCSS-in-JS選定基準社内向けシステムやtoB向け管理画面など、パフォーマンス要件が比較的緩い　　　　　ランタイムCSS-in-JS + 必要に応じてSSRで良さそ toC向けのサービス等、ややパフォーマンス要件がありそう　　　　　
基本ランタイムCSS-in-JS + SSR(useServerInsertedHTML*)で良さそう、  　　　　　　ボトルネックに応じてゼロランタイム + RSCをオプトイ~ Edge環境などにデプロイしたいからバンドルサイズを抑えたい　　　　　基本ゼロラン+RSCで、一部Lazy Loadで良さそう。あとはPreact使うとか    *useServerInsertedHTMLはシングルレンダーでストリーミングSSRに対応している

Kuma UIの設計思想と頑張らないゼロランタイムCSS-in-JS

Kuma UIの設計思想と頑張らないゼロランタイムCSS-in-JS

poteboy

More Decks by poteboy

Featured

Transcript