wcb vs Lit vs FAST: サイズと機能の比較

v5以降のリリースでは、WebComponent ベースクラスはカスタム要素の仕様への準拠をより厳密にし、JSコンポーネントの作成に関する期待値と安定したHTMLの振る舞いを組み合わせることで、QOL（生活の質）の改善と全体的な堅牢性を実現しました。現在では、その場での再レンダリング、HTMLのboolean意味論、オーバーライド可能な属性コンバーターなど、数々の改善が備わっています。

このページでは、これらの利点とそのコストを文脈の中で示します。類似のWeb Componentライブラリと比較してWCBのサイズはどれくらいか、各ライブラリはカスタム要素をゼロから書くのに比べて何をもたらしてくれるか、そしてどんなときにWCBが正しい選択となるかです。

実測サイズ: 各ライブラリで同じコンポーネントを実装

以下の数値は、各ライブラリで書いた同一の最小限のカウンターコンポーネント（1つのリアクティブな count prop、クリックハンドラー、変更時の再レンダリング）を esbuild --bundle --minify --format=esm でバンドルし、gzip（レベル9）とbrotli（品質11）で圧縮して実測したものです。これは「最初のコンポーネントの実コスト」、つまりライブラリのランタイム＋コンポーネントコードとしてブラウザがダウンロードするすべてを表しています。

実際に動く様子はこちら: ライブラリ比較デモ ↗ — すべてのカウンターが並んで動作し、各ライブラリのソースと、下表を生成する measure.mjs スクリプトを確認できます。

ライブラリ	バージョン	最小化後	Gzip	Brotli
web-component-base	6.2.0	6.6 kB	2.9 kB	2.6 kB
@elenajs/core	1.0.1	9.2 kB	3.7 kB	3.4 kB
lit	3.3.3	15.3 kB	5.9 kB	5.3 kB
@microsoft/fast-element	3.0.1	44.8 kB	13.6 kB	12.2 kB
バニラ HTMLElement	-	0.6 kB	0.3 kB	0.2 kB

規模感として: v5.2〜v6.2のすべての作業を経てなお、WCBのカウンターはElenaより約23%小さく、Litより約52%小さく、FASTより約79%小さくなっています。

機能比較

各ライブラリが HTMLElement を直接拡張するのに比べて何を与えてくれるか、つまり自分で書かなくてよくなる定型コードです。

機能	WCB 6.2	Lit 3.3	Elena 1.0	FAST 3.0
宣言的テンプレート	✅ html タグ付きテンプレート（htm）またはプレーンな文字列	✅ lit-html タグ付きテンプレート	✅ html タグ付きテンプレート	✅ バインディング式を持つ型付きテンプレート
リアクティブなprop ⇄ attribute	✅ static props、オーバーライド可能なコンバーター	✅ コンバーター付き static properties	✅ static props、オプトインの反映	✅ @attr / observable
更新戦略	インプレースパッチ（インデックスベース、非キー）	パートベース: 変更されたバインディングのみ更新、キー付き repeat	バッチ処理された再レンダリング	きめ細かいobservableバインディング、キー付き repeat
再レンダリング時のDOM状態保持	✅	✅	✅	✅
更新のバッチ処理／スケジューリング	⚠️ prop書き込みごとにレンダリング	✅ 非同期バッチ処理、updateComplete	✅ バッチ処理、updateComplete	✅ キュー／バッチ処理
キー付きリスト調整	⚠️ 位置ベース	✅ repeat ディレクティブ	⚠️ 位置ベースのモーフィング	✅ リサイクル制御付き repeat
デフォルトでLight DOM	✅（static shadowRootInit でシャドウDOMをオプトイン）	❌ デフォルトでシャドウDOM	✅（シャドウはオプトイン）	❌ デフォルトでシャドウDOM
スコープ付きスタイル	⚠️ static styles には static shadowRootInit によるシャドウのオプトインが必要	✅ シャドウスコープのCSS（シャドウDOMがデフォルト）	✅ 生成された @scope CSSファイル（CLI）によりLight DOMでも可能。static styles 自体はシャドウのオプトインが必要	✅ シャドウスコープ + デザイントークン（シャドウがデフォルト）
サーバーレンダリング	⚠️ SSRパッケージなし。型付きpropの状態はサーバーが書き出した属性から初期化（サーバーは任意、サーバー側JS不要）	✅ @lit-labs/ssr（labsのプレリリース表記あり）	⚠️ @elenajs/ssr は実験的なアルファ版	⚠️ fast-ssr は非推奨。後継パッケージは1.0未満
サーバーDOMのハイドレーション	❌ 最初のクライアントレンダリングがサーバーのマークアップを置き換える	✅	❌ 動的コンポーネントは最初のレンダリングでサーバーのマークアップを置き換える	⚠️ defer-hydration はあるが、非推奨／1.0未満のスタックに依存
ビルドツール不要で動作	✅ CDNからインポート、コンパイラ不要	✅（ビルドレスも可能、デコレーターにはツールが必要）	✅	⚠️ 実用にはツールが必要
エディタ／IDEツール	✅ 型付きprop + CEMアナライザープラグイン	✅ 充実（アナライザー、TSデコレーター、IDEプラグイン）	✅ CEM中心	✅ TSファースト
ライフサイクルフック	onInit、afterViewInit、onChanges、onDestroy	フルセットのリアクティブ更新ライフサイクル	willUpdate、firstUpdated、updated	フルセットのライフサイクル + ビヘイビア
支援体制／エコシステム	単独メンテナー。1つのパッケージ、小さいAPI表面積	OpenJS Foundation（2025年にGoogleから寄贈）、大規模なエコシステム	新規（2026年）、単独著者	Microsoft、Fluent UIの基盤

SSRとハイドレーション

SSR関連のセルは、いずれもそのパッケージ自身が公表している安定性の位置づけを引用しています。@lit-labs/ssr はlabsのプレリリース表記を掲げているものの、メジャーバージョンは4に達し活発にリリースされており、この中で最も成熟しています。@microsoft/fast-ssr は非推奨となり、@microsoft/fast-build と @microsoft/webui に引き継がれましたが、どちらも現時点では1.0未満です。WCBにはSSRパッケージがなく、状態はサーバーが書き出した属性から初期化されるものの、サーバーのDOMは初期表示専用にとどまります。

11ty WebCがここにない理由

WebCはコンパイル時ツールです。Eleventyのビルド中にコンポーネントを解決し、クライアントランタイムなしのプレーンなHTMLを出力します。上表の各行はすべて、ライブラリがブラウザ上でランタイムに何を行うかについてのものなので、並べて比較すると異なる2つのものを測ることになってしまいます。もしあなたのコンポーネントがビルド時に静的であるなら、WebCは別の問題を解決してくれます。

これらの数値と機能が何を意味するのか（そしてどんなときには意味を持たないのか）については、なぜWCBを使うのか?を参照してください。

---

全ライブラリを2026-08-09に測定（WCBはv6.2.0）。esbuildとNodeのzlib（gzip −9、brotli q11）を用いて、上記の固定バージョンで測定。手法: ライブラリごとに同一のカウンターコンポーネントを、ライブラリごとにバンドルし、圧縮。自分自身で再実行することもできます。カウンターとmeasure.mjsスクリプトはデモワークスペース（demo/examples/library-comparison/）にあります。このベンチマークは、上記で固定されたバージョンで簡単に再現できます。