Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kuma UIの設計思想と 頑張らないゼロランタイムCSS-in-JS
Search
poteboy
March 27, 2024
3
1.3k
Kuma UIの設計思想と 頑張らないゼロランタイムCSS-in-JS
Kuma UIの設計思想を説明しながら、実際にパフォーマンスを計測し、無理のない範囲での個人的ゼロランタイムCSS-in-JS選定基準を話しました。
poteboy
March 27, 2024
Tweet
Share
More Decks by poteboy
See All by poteboy
現代CSSフレームワークの内部実装とその仕組み
poteboy
9
4.7k
CSSパフォーマンスに関する計測結果
poteboy
4
2k
Kuma UIのこれまでとこれから
poteboy
7
4.4k
近代フロントエンドの歴史とKuma UIの登場意義
poteboy
4
4.8k
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
7.9k
Code Review Best Practice
trishagee
64
17k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Navigating Team Friction
lara
183
14k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Producing Creativity
orderedlist
PRO
341
39k
Visualization
eitanlees
144
15k
Transcript
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に対応している