WebComponentsライブラリの選定

はじめに

前回、危うく地雷を踏むところだったWeb Awesomeに代わるWeb Componentsライブラリには他に何があるかを調べることにした。今回は中で使われている技術よりも完全に見た目だけで判断したいと思う。

デザインシステムのあり方とは

まず、デザインシステム（CSSフレームワーク）の必要要件について考えてみよう。

• 見た目が良い
• カスタマイズ性が高い
• 設計思想（デザイン的一貫性を含む）がはっきりしている

このうち、カスタマイズ性が高いというのと設計思想がはっきりしているというのはトレードオフの関係であり、前者が多い場合、よほど計画性を持って作らないと、今のTailwind.cssのように、色一つ変えるのにクラスを書き直しみたいな、メンテナンス性が悪かったりUIパーツのデザインに一貫性のないサイトができてしまう。

かといって設計思想がはっきりしているとBootstrapやmaterial designのような、どのサイトに行っても同じようなデザインということになる。¹

いずれにせよ、TawilwindはDOMが汚れるくらい長いクラス名が必要²、bootstrapやMaterial Designはcssの容量といった形で、サイトを表現するのに必要以上のペイロードが必要という構造的問題は解決できていない。

Material Designも自己主張が強めだが、AndroidというOSそのもののデザインをWebに移植したようなものなのでbootstrapほど違和感を感じない。しかし、過剰なスタイリングによるペイロードの増大問題は残る。

Web Componentsデザインシステム一覧

とりあえず、今回は自分が調べたWebComponentsのデザインシステムを雑に紹介したい。なお、ほとんどのフレームワークはVueやReactとのバインディングがあるので移行も簡単である。

デザインシステムは大きく分けて、

• Bootstrap系
• フラット系
• マテリアルデザイン系
• Fluent系（Metro（Modern）を含む）

と定義する。

• Astro UXDS - フレームワークのAstroとは無関係。プロジェクトサイトではvueへの言及はないが、実際は対応している
• Auro - アラスカ航空の提示するデザイン。ちょっと初回表示が重め。航空会社らしくフライトにまつわるUIがある
• Blueprint UI - フラットデザイン。自己主張弱め
• Bolt Design System - Pega Systemsによって提供されているデザインシステム。特徴的なのはTwigと標準仕様のWeb Componentsを組み合わせ、再利用可能なUI要素（ボタン、リスト、画像、フォームなど）をカプセル化して提供しているところ。phpとのバインディングもあるのでLaravelを使用するプロジェクトと相性がいいかもしれない
• Calcite Components - GISの会社で有名なESRIの提唱するデザインシステム。マップ関係に強い。フラットだが立体感があるマテリアルデザインに近い
• Carbon Web Components - IBMの提唱するデザインシステム。非常にフラットなデザインで、ボタンやフォームなどが角ばっているデザインが好みの分かれるところかもしれないが、モバイルやVRにおいてはその方がUXとしては正しいので、IBM Plexフォントも相まって今後のbootstrapポジションになるかもしれない
• Clarity Core Web Components - VMWareが開発していたデザインシステムだが買収騒動の余波を受けたのかポシャったらしい
• Crayons - Freshworks Design System。淡くしたマテリアルデザインという感じで自己主張弱め。ボタンはうっすらグラデーションが掛かっている
• Fluent UI Web Components - マイクロソフトの提唱するFluent UIのWeb Components実装。FAST Componentsに準拠している。ただし、Windows界隈ではWPFの迷走や、Metro（Modern UI）だのと散々UIのデザイン指針変更で揉めた実績があるので要注意である
• Taylor Forge Design System - マテリアルデザイン系だがかなりフラット寄り。実験的だがTailwindとのバインディングやMCPと結合がある
• GOV.UK Web Components - イギリス政府のデザインシステム。デザイン性よりもUXを重視しているらしく、ボタンやチェックボックスのUIパーツやコンポーネントの余白が大きめに設定されているところが特徴
• Helix UI - Fluent UI系。Windows 8のメトロデザインに近い
• Liquid Oxygen - Bootstrapに近いイメージ。Tailwindとのバインディングあり
• Lyne Components - マテリアルデザイン系。レイアウトやスタイルシートの指針が含まれているのが特徴。便利な半面機能が増大しがちかもしれない
• Material Web Components - Googleの提唱するMaterial DesignのWeb Components実装だったが、ポシャったので除外。一応メンテはされているが・・・。
• Momentum UI Web Components - フラットデザイン系。変わったギミックを持つコンポーネントがある
• Nord - ヘルスケアのNordHealth社のデザインシステム。マテリアルデザイン系
• NVIDIA Elements - nVidiaの提唱するデザインシステム。AI連携が考慮されている。デザインとしてはFluentとフラットの中間といったところか
• OutlineJS - Fluent系
• PatternFly Elements - Fluent系。メトロデザイン
• Pharos Design System - Fluent系メトロデザイン
• Red Hat Design System - RedHat社のブランドのUI。若干表示がもたつく以外は率直なフラットデザイン
• Siemens iX Web Components - ジーメンス社のデザインシステム。Bootstrapに近い
• Spectrum Web Components - Adobeの提唱するSpectrumデザインをWeb Componentsで実装したもの。率直だがAdobe臭が抜けない
• UI5 Web Components - マテリアルデザイン系だがフラット
• U-M Library Design System - ミシガン大学のデザインシステム。bootstrapをフラットにした感じのデザイン
• Zooplus web components - Bootstrap系。開発は終了しているようだ

特に気になるものは太文字にしておいた。

今後どう動くべきか

最近のサプライチェーン攻撃の問題から、依存関係の多くなりがちなNext³やNuxtを新規プロジェクトで採用することは避けたい。

その最終的な解決策としてのWeb Componentsだが、仕様としては完成しているもののまだ採用例が少ない。

中期的な選択肢としては、Astroを勧めていきたい。アイランドアーキテクチャで本当に必要な箇所だけVueやReact、Svelteなどを混ぜることができるので、Web Components移行を見据えて採用するのが一番かもしれない。⁴

そもそも論として

そもそもWebに限らず、VueやReactなどで実現しているリアクティブな要素が必要になる箇所は思っているほど多くない。何でもかんでもVueだReactだNextだNuxtだRemixだうんたらかんたらだと考える前に、本当にリアクティブが必要な箇所とはどこか？ をリストアップしてから技術選定するべきである。

よくありがちなのが、「将来の拡張性を見据えて」とかもっともらしい理由をつけて重厚長大なフレームワークを安易に選ぶことである。依存関係が増えてサプライチェーン攻撃の脆弱性の窓口を増やしている現代のシステム開発において、もう一度 単一責任の原則や、YAGNI原則に振り返って考えるべきだ。

どう考えても、限られた人しかアクセスできないシステム向けに、NextやNuxtのようなSSR(サーバーサイドレンダリング）はいらんだろ…。

「何をするか？」よりも「何をしないか？」を考える事のほうが、エンジニアリングとして重要なのである。

1. まぁ、bootstrapが選ばれない理由として、CSS変数をカスタマイズして自分色にする使い方をしていないサイトが多く、結果的にbootstrap臭が抜けないせいという理由のような気がする。せめて、bootswatchぐらいは使おうよ。 ↩

2. 結果的にTailwindは、CSSが肥大化する代わりにHTMLそのものが肥大化しているという本末転倒なことが起きている。このため自分は最初から選択肢を外している。 ↩

3. というか、NextはVercelにベンダロックされてね？RedHatのCentOS騒動の時のように他の会社に買収されたら、サポートやライセンス、料金体系がわかったもんじゃないぞ。 ↩

4. 現在開発中のBootstrap6もAstro基盤で作られている。ただし、v6ブランチを見た感じ、ダイアログをdialogタグで済むところを未だにdivタグで実装していたり、時間不足を理由にWeb Componentsへの移行は断念しているようなので将来性には期待できない。 ↩