Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

poteboy
March 27, 2024
1.3k

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

Kuma UIの設計思想を説明しながら、実際にパフォーマンスを計測し、無理のない範囲での個人的ゼロランタイムCSS-in-JS選定基準を話しました。

poteboy

March 27, 2024
Tweet

Transcript

  1. poteboy 自己紹介 ˜ 個人開発ƒ ˜ 合同会社ぽてぽてランド(登記中)の1人代表(予定S ˜ 要するに今は無職g ˜ Kuma

    UI というOSSの作ƒ ˜ ゼロランタイムCSS-in-J4 ˜ 詳しくは以下のリンクまで ˜ ˜ SN4 ˜ GitHub: potebo ˜ X (Twitter): @_poteboy_ https://www.kuma-ui.cog
  2. 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 とは
  3. Kuma UIの目的はDX維持&エコシステムへの追従 Kuma UIチームとPanda CSSチームの見解としては、Utility First & CSS-in-JSが最も
 Maintainabilityの高いスタイリング手法だと考えている。
 Tailwind

    CSSの作者であるAdam氏も、 「(インラインスタイルでCSSの全てを表現 する)ことをブラウザが対応していない事実こそが
 CSSフレームワークが存在する唯一の理由だ」
 と言っている。 個人的にも、この意見に完全に同意。
  4. 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)とエコシステムへの互換性を重視
  5. 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個をレンダリングしてみる
  6. まとめ:頑張らないゼロランタイムCSS-in-JS選定基準 š 社内向けシステムやtoB向け管理画面など、パフォーマンス要件が比較的緩い       ランタイムCSS-in-JS + 必要に応じてSSRで良さそ€ š toC向けのサービス等、ややパフォーマンス要件がありそう      

    基本ランタイムCSS-in-JS + SSR(useServerInsertedHTML*)で良さそう、
       ボトルネックに応じてゼロランタイム + RSCをオプトイ~ š Edge環境などにデプロイしたいからバンドルサイズを抑えたい       基本ゼロラン+RSCで、一部Lazy Loadで良さそう。あとはPreact使うとか


 *useServerInsertedHTMLはシングルレンダーでストリーミングSSRに対応している