なぜWCBを使うのか?

WebComponent ベースクラスは、可能な限り最軽量で、フルセットのコンポーネント開発体験を提供します。生産性を高めるために必要最小限のコードだけです。

WCBが存在する理由は5つあります。

手に入る中で最も安いランタイムリアクティビティであること。 フルセットの開発体験（宣言的テンプレート、型付きprop⇄attribute同期、ライフサイクルフック、状態を保持した再レンダリング）を、最小のフットプリントで実現します。LitとFASTは通信量（brotli圧縮後）で2〜4.7倍のコストがかかります。予算が「ほぼ静的なページ上の1コンポーネント」程度なら、LitやFASTが通信量として最も重いものになる場面でも、WCBはぴったり収まります。
文字通りツール不要。 コンパイラなし、デコレーターなし、ビルドステップなし。<script type="module"> からCDN経由で1つ import するだけで、現行ブラウザ上で動作します。全体のメンタルモデルは static props + template + 4つのフックだけで、配布されるソースは一度に読み切れる読みやすさです。ランタイムはbrotli圧縮後で2.6 kB（実測値）。
属性ファーストのリアクティビティはHTMLネイティブである。 propは属性にシリアライズされるため、初期状態は（JSフレームワークのSSR統合を必要とせず）任意のサーバーがプレーンなHTMLとしてレンダリングでき、コンポーネントはdevtools上で通常の属性として検査・デバッグ可能な状態を保ちます。
デフォルトでLight DOM。 グローバルなスタイルシート、フォーム、サードパーティのCSSがそのまま動作します。カプセル化が必要になったら、静的フィールド1つでシャドウDOMに切り替えられます。
サイズゲートは統治された値である。 追加されるすべてのバイトは、CIで強制されるsize-limitの予算のもと、サイズ変更ログでその存在理由を説明する必要があります。スマートな差分検出はプロジェクト史上最大の単一追加であり、そのコストは0.43 kBでした。

WCBが誤った選択になる場合

正直に選びましょう。

状態を持つ項目の並べ替え可能なリスト: パッチ処理は位置ベースであり、キーベースではありません。保持されるフォーカスやアニメーションは項目ではなく位置に追従します。Litの repeat やFASTならこれを正しく処理できます。
大きなツリーへの高頻度な更新: WCBはprop書き込みごとに同期的に再レンダリングし、vnodeツリー全体を差分比較します。Lit/FASTはバッチ処理されたスケジュールで、影響を受けたバインディングのみを更新します。
クライアントハイドレーションを伴うSSR: WCBはconnectedCallbackの後、クライアント側でレンダリングするため、ハイドレーションのステップはありません。サーバーレンダリングされたマークアップをその場でハイドレートする必要があるなら、Lit（@lit-labs/ssr）を使ってください。
大規模チーム・長期展望のデザインシステム: WCBは意図的に表面積を小さく保った、単独メンテナーによるライブラリです。大規模組織のバックアップとエコシステムが必要なら、Lit（OpenJS Foundation）かFAST（Microsoft、Fluent UIの基盤）を選んでください。

これらの主張の背後にある実測値と機能ごとの比較については、WCBと類似ライブラリを参照してください。