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.4k
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.8k
CSSパフォーマンスに関する計測結果
poteboy
4
2k
Kuma UIのこれまでとこれから
poteboy
7
4.4k
近代フロントエンドの歴史とKuma UIの登場意義
poteboy
4
4.9k
Featured
See All Featured
What's new in Ruby 2.0
geeforr
343
31k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Making Projects Easy
brettharned
115
5.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2.1k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Bash Introduction
62gerente
608
210k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
The Cost Of JavaScript in 2023
addyosmani
45
6.8k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
96
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に対応している