デザインシステムで Tailwind CSSとCSS in JSに分散投資をしたら良かった話

2024-03-27に行われたFindy『フロントエンド技術選定 ~ゼロランタイムCSS in JSとTailwind CSS編~』の登壇資料です
https://findy.connpass.com/event/312625/

Transcript

1. デザインシステムで Tailwind CSSとCSS in JSに 分散投資をしたら良かった話 フロントエンド技術選定 ~ゼロランタイムCSS in JSとTailwind CSS編~ @ Findy pixiv Inc. Chiaki KUDO / @f_subal 2024.03.27
2. 2 自己紹介 • 2016年4月 ピクシブ株式会社に新卒入社 • 2018年から pixivFACTORY の開発 • フロントエンドエンジニア → テックリード → エンジニアリングマネージャ → PdM • 2020年〜2022年デザインシステムの開発を兼任 ◦ 2022年に charcoal として OSS 化 ◦ デザインシステム初期メンで、OSS化プロ ジェクトを進行した人 • 2024年に『Tailwind CSS実践入門』を出版 @f_subal ピクシブ株式会社
4. 話すこと • なぜユーティリティファーストをデザインシステムの設計に採用したか • なぜTailwind CSS以外の選択肢を用意する形を取ったか • styled と Tailwind CSS の両対応したらどう良かったのか • 今後の展望――将来のフロントエンドの変化にいかに対応するか 4
5. なぜユーティリティファーストを デザインシステムの設計に採用したか 5
7. ピクシブにおけるデザインシステム • 10個以上のプロダクト、だいたいのリポジトリが5年以上の歴史を持つ • フロントエンドの技術スタックは特に同じではない ◦ React(非Next.js)、React + Next.js、Vue.js、Rails + ERB、PHP + Smarty、全部ありうる ◦ とはいえ React が多数派ではある • 目的は「異なるプロダクトでも同じピクシブのプロダクトだとわかる」状態 ◦ 複数プロダクトでのブランディングの統一性 ……を目指すべく始まった。2020年頃から。 7
8. 2020年のCSSはどんな感じだったか（私見） • React 界では CSS in JS または CSS Modules またはその他大勢 ◦ ピクシブで早く React を採用したチームは styled-components が多かった • Vue.js 界では v3.0 がリリースされた年。Scoped CSS が依然として強い • テーマを巧く表現できる技術が CSS in JS ぐらいしかない時代 ◦ IE が死んだばかりで、CSS Variables をようやく使えるかという状況 ◦ styled-components 使わないとダークモードがちょっとしんどい時代 • 「CSSのフレームワーク ≒ Bootstrap みたいなもの」という風潮 ◦ しかし開発者は Bootstrap のことをそんな好きではない ◦ まともなコンポーネントライブラリ作るなら中で CSS in JS を使うという風潮 • この状況で「技術スタックを問わないデザインシステム」なんてできるのか？ 8
9. 9 • 当時名前を聞いたことがあった程度 • tailwind.config.js で設定できること をあるとき知る → これじゃん！！！ • 実体が PostCSS プラグインであった のも良い（ポータブル！） • 「styled を使ってるチーム以外は全 部 Tailwind CSS で良くない…？」 • 複数の技術間でデザイントークンを 共有する動機が芽生える 2020年5月、 Tailwind CSSに注目 powered by https://tweet2image.vercel.app/
10. 「コンポーネントファースト」をやめる決意 • デザイナは色やスペーシングのルールからスタートしていた ◦ 一方、開発陣はコンポーネントライブラリを作ろうとしていた ◦ 「pixiv.net で使ってる <Button> を横展開しようぜ」といった感じ • しかし出来合いのコンポーネント集はキリがなく、挫折しやすい（した） ◦ 「どのくらいコンポーネントが揃ったらファーストリリースして良いのか？」 ◦ 「あったところで、どうせプロダクトで拡張したくなるんじゃないか？」 • しかし Tailwind CSS を使えば、色やスペーシングのルールをそのままライブラリに できるし、それでマークアップができる • というか、テーマを定数として配布すれば同じものが styled でも使えるじゃん 10
12. 12 • 複数の技術に対応させた結果、レイ ヤーがあると気づく（三層構造） • デザイントークン < ユーティリティ < コンポーネント の順に依存 • 複数の技術を考慮した結果真ん中の 層の存在に気づいた ◦ テーマとコンポーネントしかな いと思いこんでいたが違ってた デザインシステムの 三層構造
13. デザインシステムを いかに普及させていったか 13
14. 途中から入れやすいことに全ふりした設計 • コンポーネントファーストじゃない方針で良かったのか？ ◦ 結論良かった ◦ 共通コンポーネントに任せたい部分は実際には一部だった ▪ 「<Button> 以外は固有のUIだが、paddingはルール通り」とかよくある ◦ コンポーネント集からスタートするのはデザインシステムのアンチパターンと さえ言って良い（我々のようなケースでは特に） • 2020年後半〜: 新規に作られるプロダクトや画面で使われ始める ◦ CSS Modules → Tailwind CSS への移行は意外と痛みが少なくスタートできた ◦ もともと styled なプロダクトはテーマを charcoal 仕様に ◦ Next.js への移行をするチームが増えてついでに使われるようになった 14
15. 15 • 先述の通り、styled-components を 使ってるプロダクトが多かった ◦ CSS Modules → Tailwind は移 行しやすかったが、styled → Tailwind はハードルがあった • styled-components 向けに型安全で ユーティリティファーストな記法を 提供（実験的な試み） ◦ 共通言語として浸透していった ユーティリティに選 択肢を用意する
17. 17 • styled にせよ Tailwind にせよ、ユー ティリティに沿ってない記法のほう が特殊、という扱いになる • レビュー時に「ガイドラインに沿わ ない見た目」がわかるようになる ◦ 「ここ何で mb-[26px] なんで すか？デザイナのミス？」「ホ ントだFigma間違ってそう」 • CSSのレビューがまともにできる！！ デザインシステムに 沿ったレビュー ※ レビューコメントはイメージです
19. 普及した後に見えてきた 課題とか、展望とか 19
20. 前提:ライブラリ提供者にとってのCSS in JS • 2010年代、CSS in JS でライブラリを実装することにはメリットがあった ◦ 利用側にビルド周りの設定を強制しなくてすむ、スタイルが衝突しない… ◦ 「webpack や babelrc をいじらずに導入できる」がコンポーネントライブラリ の当たり前基準だった ▪ 「えーこのコンポーネントライブラリ css-loader 必要なの😅」という感情 ◦ Material UI も Chakra UI も内部では emotion を使っていた • 最近は、利用側の設定でビルドしてもらう形が受け入れられつつある（私見） ◦ vanilla-extract や Kuma UI など、ゼロランタイム系は特に顕著 ◦ ゼロコンフィグよりも、パフォーマンス面やフレームワークとの相性が重要に 20
21. 普及フェーズから非機能要件の底上げへ • 初期の charcoal は「途中から導入しやすい」ことに全振りした設計だった ◦ これはたぶん正しかった ◦ 今からデザインシステムをはじめる人も最初こっちに全振りするのはアリ • ある程度普及してくると非機能要件がメインの問題になってくる ◦ パフォーマンス、アクセシビリティ、アップデートのしやすさ…… ◦ 「なんでうちReact + Tailwind CSSのプロジェクトなのに styled 依存のコン ポーネント使ってるんだろ…」 ◦ 「依存を減らしつつ、導入側の負担も少なくする」を両立することが課題に • バンドラの設定をもとに CSS を import するのは今の時代なら簡単だし良いかも ◦ import '@charcoal-ui/react/dist/*.css' に移行していきたい 21
22. 22 • 独自の theme(o => …) 記法は型安 全性のメリットはあったがランタイ ムコストがあった • pixiv.net のような利用者の多いサイ トはパフォーマンスが無視できない • ふつうなら styled → Tailwind CSS 移行はしんどいところだが… ◦ 全く同じデザイントークンを 使ってるので意外と現実的！ 一部のチームは styled→Tailwindへ
23. まとめ: 疎結合が選択肢を生む • 一見「技術を移行しなければならない」というのはネガティブ要素に思われるが… ◦ そもそもそれが現実的に思えるつくりにできたのは成功ポイントとも言える ◦ 「三層構造」でトークンとユーティリティを疎結合にしててよかった！ • 社内に5年以上続くサービスがいっぱいあるし、そしてこれからも… ◦ 10年後にCSSの技術が様変わりしたとしても、デザインシステムが層に分かれ ていれば一部を取りかえるだけで良いはず（理論上） ◦ 実際トークンとユーティリティはそのままに、コンポーネントだけ styled をや める見込みがあるわけだし • デザインシステムをレイヤー間で疎にしつつ、複数の技術に分散投資しててよかった 23
24. Any Questions? 24