Chakra UIの思想を学んでみる
Chakra UIはUIライブラリについて調べれば必ず名前を見かけるほど著名なOSSであり、GitHubのスター数を見てもその人気度が分かります。
比較対象としてGoogleの提供するMaterial UIをベンチマークとしてみます。
- Chakra UI スター数 35.3k（2024/1執筆時点）
- Material UI スター数 90.2k（2024/1執筆時点）
Material UIのおよそ1/3程のスター数であり、万を超えるコントリビューターもいますので知名度とエコシステムともに信頼に足るUIライブラリという印象を受けます。
実際に私も業務で使用経験がありますし、個人開発でも使用する機会が多いのですが、UIライブラリとしての設計思想？というものをきちんと理解しきれていない感覚があります。
なので今回はChakra UIの思想を理解し、今後のライブラリ選定や開発に活かすという観点で考察していこうと思います。
目的
Chakra UIのドキュメントを読んで設計思想を理解し、ユースケースを考察する
設計原則
私たちの目標は、現実のUIデザインの問題に対応するシンプルでコンポーザブルなコンポーネントをデザインすることです。そのために、私たちは常にその道を歩むための原則を開発しました
設計原則のページにて語られているこの内容ではChakra UIの設計思想としてまず第一にシンプルでコンポーザブルなコンポーネントを提供することを主軸としていることが分かります。
現実のUIデザインでは複雑なUIが求められることが多いですが、それら複雑さの実態は小さなコンポーネントの集合体であることが殆どです。つまりシンプルなコンポーネントに高いコンポーザビリティを付与することで大体のユースケースは網羅できるはずであり、この思想は腑に落ちます。
以下に原則の詳細をいくつか抜粋してみましょう。
シンプルであること
コンポーネントのAPIをかなりシンプルに保ち、コンポーネントを使用する実世界のシナリオを示すよう努める。
Chakra UIの提供するコンポーネントAPIはシンプルで現実的です。
例としてMaterial UIとChakra UIで提供しているButtonコンポーネントで比較してみます（API全てを載せると長くなるのでリンク先を閲覧ください）
比較するとMaterial UIのButtonはdisableRippleやdisableFocusRipple、href、fullWidthなどできることの幅が広いのに対し、Chakra UIのButtonはisLoadingやicon系、sizeなど最低限で実用的なAPIのみを提供しているような印象があります。
あくまで一例ですが、こうして比べるとシンプルに保たれていることが分かります。
スタイル・プロップ
すべてのコンポーネント・スタイルは、スタイル・プロップスによってオーバーライドまたは拡張することができ、cssプロップスやstyled()の使用を減らすことができます。Box から新しいコンポーネントを構成する。
Chakra UIのコンポーネントはスタイルシステムに基づくStylePropsを継承しています。そのため、propsを経由したスタイリングが可能であり、上記のMaterial UI Buttonで示したfullWidthなどのスタイリングに関係するpropsも代替可能です。
スタイルシステムに関連するpropsとコンポーネント固有のpropsで綺麗に責務を分けられているように思います。
アクセシビリティ
コンポーネントを作成する際には、アクセシビリティを最優先してください。 これには、キーボードナビゲーション、フォーカス管理、カラーコントラスト、ボイスオーバー、正しいaria-*属性などが含まれます。
Webのインターフェースとして重要なアクセシビリティ、WAI-ARIAに標準していることについて触れられています。これはどのUIライブラリでも重要視しているであろう箇所ではありますが、公式がアクセシビリティを重んじる姿勢はUIライブラリとして信用できるポイントになり得ると思います。
Material UIと比較
このページではUIライブラリやCSSフレームワークとの比較が語られています。
Material UIとの比較もありますので抜粋してみます。
Material UI Reactライブラリは、ユーザーにいくつかのUIレイアウトツールを提供するが、開発者がカスタムスタイルを適用して、すぐに使える基本スタイルを上書きできる、幅広いスタイルのUIコンポーネントで最も有名である。 Chakra UIは、より堅牢で、レイアウトに特化したライブラリであり、Material UIが提供するものと同様のUIコンポーネントを開発者に提供するが、柔軟で、コンポーザブルで、スケーラブルなコードを作成することに重点を置いている。
原則通り、Material UIよりもコンポーザブルでシンプルな設計に重きを置いているとのこと。Material UIが提供するものと同様のUIコンポーネントを開発者に提供するとありますが、提供しているUIの豊富さでいうと圧倒的にMaterial UIに軍配が上がります。とはいえ原則に従うとカスタム済みの複雑なUIの提供は優先事項にはなり得ないので思想の違いが出ているのでしょう。
カスタムスタイリングがプロジェクトにとって大きな関心事でない場合、ライブラリが提供するカスタムコンポーネントの作成を避けることができるため、Material UIは有益です。スケーラブルでカスタムなデザインがプロジェクトにとって重要な場合（多くの場合そうだ）、Chakraの開発者の利便性はMaterial UIよりも優れている。
この文章から読み取るに、徐々にスケールさせていく予定があって、デザインの独自カスタムをしたいならChakra UIの方が利便性として優れているということだと思います。
ランタイム・トレードオフ
CSS-in-JSランタイムについて語られている項目があります。
ここではChakra UIがCSS-in-JSによるパフォーマンスの問題とそれに対する比較選択について説明しています。
Chakra UIはCSS-in-JSを使用しているため（emotion+styled-system）、この柔軟性は実行時に小さな代償を伴います。この実行時のフットプリントは、styled-system によるスタイル計算と、emotion による className 生成によって発生します。
パフォーマンスが重視され、頻繁に変更されるデータを扱うアプリの場合、アプリが成長するにつれてこのフットプリントに気づくかもしれない。
Chakraの使用を決定する前に、他の選択肢と比較することをお勧めします。しかし、ほとんどの小規模または中規模のデータ駆動型アプリケーションでは、Chakra UIは完璧にフィットすると考えています。
CSS-in-JSを使用することによるパフォーマンス問題は認識しつつも、それが問題にならない小〜中規模のアプリケーションにて使用することを勧めているようです。
Chakra UIからCSS-in-JSを無くすよう要望する声もあるようですが、それに対するアプローチが過去の記事ですがChakra UIの未来にて語られています。
Chakraのスタイリングシステムの優れた機能の大部分はそのままに、ビルド時にスタイルを抽出する、フレームワークに依存しない新しいスタイリングソリューションを構築しています。また、開発中にpostcssの実行時にスタイルを抽出するPostCSSプラグインも提供します。
CSS-in-JSを外すのではなく、Chakra UIのスタイルシステムに影響を受けた新規のCSSフレームワークを開発するアプローチを取るようです。そして実際にPandaがリリースされました。
ここまでの所感
ここまででChakra UIをまとめてみます。
- 柔軟でコンポーザビリティの高いコンポーネントを提供する
- シンプルなAPI
- アクセシビリティを重要視している
- 高いデザインカスタム性
- 小中規模アプリケーション向け（CSS-in-JSによるパフォーマンス問題のため）
全体としてミニマルだが実用的という印象ですね。
実際に使用している私の感想としては開発体験はとても良いです（あんまりChakra使って困ったことが無い）
まとめ:ユースケースを考えてみる
実際のユースケースで使用するならやはり小中規模での開発なのかなと思います。
柔軟でコンポーザブルなのは強みではありますが、それ故にMaterial UIが提供するような複雑なコンポーネントを提供していないので自前で作る必要があります。
自前で作る時間と費用があれば良いかもしれませんが、多くの場合そうでは無いので複雑性の少ない小中規模開発が向いてそうです（複雑なUIが作れないという話ではなくコストの問題）
ただ、メリットとしてAPIがシンプルで学習コストも少なく、アクセシビリティも担保されているのでスピード感のある実用的なフロントエンド構築が可能になると思われます。
また、既存のスタイルシステム上に独自のデザインシステムを比較的簡単に適用できるので高いデザインカスタム性が表れているポイントかなと思います（Chakraのコンポーネントが用意されたFigma UI Kitもある模様）
以上、Chakra UIの思想を学んでみての考察でした。
あくまで一個人の考察ではありますが、参考になれば幸いです！
Discussion