世界を動かす技術を、日本語で。

ウェブコンポーネンツ:フレームワークに依存しない新たな時代

2026年2月20日原文(caimito.net)

概要

  • モダンブラウザ だけで高度なUI構築が可能な現状
  • Web Components による安定した長期運用と保守性向上
  • ネイティブイベントShadow DOM で疎結合なコンポーネント連携
  • AIアシスタント を活用した学習と開発効率の向上
  • フレームワーク依存からの脱却と Web標準 の再評価

フレームワーク税なしでモダンUIを構築する

  • ReactVueAngular などのフレームワークなしで、現代的なUIを構築できる時代の到来
  • Web ComponentsCustom ElementsShadow DOMネイティブイベントシステム によるモジュール化・再利用性の実現
  • AIアシスタント が習得・実装のハードルを大幅に低減

すでに起きている変化

  • ブラウザ自体がフレームワーク 化している現状
  • Custom Elements で独自タグと振る舞いを定義
  • Shadow DOM でスタイルや構造のカプセル化
  • テンプレートスロット による柔軟なコンポジション
  • ネイティブイベント による堅牢なコンポーネント間通信
  • 主要ブラウザで標準搭載済み、今や実用段階

アップグレード地獄からの解放

  • フレームワーク特有の 学習コストメンテナンス負担 からの脱却
  • Web標準 で作れば、10年前のコードも動作する安定性
  • Angular 1ReactクラスコンポーネントVue 2 のような破壊的変更の心配不要
  • 長期運用・セキュリティ向上・依存関係の削減

コンポーネント間の優雅な通信

  • Custom Events によるバブリングイベントで階層を超えた通信
    • 例:this.dispatchEvent(new CustomEvent('item-selected', { detail: {...}, bubbles: true, composed: true }))
  • グローバルストアやpropsの受け渡し、context不要
  • 属性・プロパティで親→子へのデータ伝播、イベントで子→親への通知
  • React のパターンをWeb標準で再現

作りながら学ぶWeb Components

  • Web Components の全仕様を把握せずとも実用的な開発が可能
  • シンプルなカスタムエレメント例
    • class TaskCard extends HTMLElement { ... }
  • AIアシスタント による即時フィードバック・リファクタリング支援
  • 実装→疑問点の質問→理解深化のサイクル

AIアシスタントとペアプログラミング

  • 実装例や仕様の解説、パターンの提案がAIで即座に可能
  • Shadow DOM 越えのイベント伝播(composed: true)の意義もAIが解説
  • connectedCallbackconstructor の違いもすぐに理解
  • ドキュメント全読破不要、実践しながら学習

実践的なアーキテクチャ例

  • ダッシュボードの複数パネルが 共通フィルター に反応するケース
    • FilterPanelがfilters-changedイベントをdispatch
    • ダッシュボードシェルがイベントを受けて各パネルのapplyFiltersを呼び出し
  • 各パネルは独立実装・独立テスト・独立再利用が可能
  • 疎結合による高速開発・保守性向上

Shadow DOMによる真のカプセル化

  • コンポーネントの スタイル漏れ防止 ・グローバルスタイルの影響遮断
  • シンプルなクラス名・リファクタリングの容易さ
  • CSS ModulesBEM などの複雑な手法不要、標準機能で実現

それでもフレームワークが有効な場合

  • チームが React 等に精通し、既存資産や開発速度を重視する場合
  • フレームワークパターンを前提とした保守体制の場合
  • 新規・小規模・長期運用前提のプロジェクトにはWeb Componentsが有力
  • ReactVue とのハイブリッド運用も可能、漸進的移行に対応

今日から始めるWeb Components開発

  • シンプルなコンポーネントを作る → DOMにマウント
  • インタラクション追加 → イベントハンドリング、DOM更新
  • コンポーネント間通信 → カスタムイベントのdispatchとリッスン
  • Shadow DOM でスタイルカプセル化、スロットで柔軟な構成
  • AI活用で未知領域もスムーズに習得、Web標準知識が長期資産に

Web開発のルネサンス

  • Webプラットフォーム がフレームワークの役割を担う時代
  • ツール・ブラウザ・パターン ともに成熟
  • シンプルで安定した基盤への回帰志向
  • AI による学習障壁の低減、Web Componentsの再評価
  • 流行に左右されず、 標準技術 で未来に残るプロダクト構築が可能

Newsletter

  • 新着記事・ストーリー・ヒーロープロファイルをメールで配信
  • 配信元:newsletter.caimito.net
  • いつでも配信停止可能

Hackerたちの意見

これをざっと読んだ。ウェブコンポーネントをよく使ってるけど、間違ってなければ、リアクティビティは提供されてないよね。自分で書かなきゃいけない。リアクティビティは現代のJSフレームワークを生み出した特徴だから、この記事はちょっと大げさだと思う。それに、もっと重要なことを見落としてる。ブラウザのネイティブESモジュールの広範なサポートのおかげで、ビルドステップ(webpack)が不要になったってこと。記事の「AIが簡単にしてくれる!」って部分は、いつも通りイラッとする。あえて疑いをかけるわけじゃないけど、いくつか怪しいエムダッシュの比較があったのは確か。

observedAttributesと、それが変わるたびに反応するコールバックがある。それが基本だね。

まだすべての引数をJSONや文字列で渡さなきゃいけないの?それともその辺に改善はあった?

リアクティビティは提供されてないよね。自分で書かなきゃいけない。リアクティビティは現代のJSフレームワークを生み出した特徴だから、この記事はちょっと大げさだと思う。これは多くのウェブコンポーネントの支持者がわざと見落としている真実だよ。彼らはこれを知ってるし、タグ付きテンプレートリテラルもエスケープが必要だから、まともなテンプレートソリューションがないことも知ってる。効率的なDOMの更新とかもあるし。(ちなみに、最近Claudeにウェブコンポーネントを書かせたけど、コードはすべてのキー入力で同じクラスを要素に割り当ててたよ)こういう特徴がたくさんあって、やっと認めさせると「自分で書け」って言われる。まあ、フレームワークはすでにこれらすべてを提供してるんだけどね。面白いのは、ウェブコンポーネントを書くための人気ツールの一つであるStencilは、実際に上記のすべてを提供しているってこと!彼らのウェブコンポーネントは、他のフレームワークで期待されるのと全く同じ特徴を持っている。なぜなら、それ自体がフレームワークだから。これが、ここでの議論がいかに馬鹿げているかを強調してる。フレームワークの「独立性」じゃなくて、あなたのコンポーネントはStencilやLit、今YouTubeが使ってるもの、あるいは他のサポートコードに依存することになる。すべては、Chromeの開発者たちがフレームワークを理解できずに嫌って、ウェブコンポーネントを推進したことから始まる。フレームワークがすべてのことを扱っていることに気づいていなかったんだ。https://youtu.be/UrS61kn4gKI?t=1921 32:00(でも、動画全体が価値があるから、この議論の両側の人たちには全部見てほしい)。ウェブコンポーネントの唯一好きなところは、「this」がその要素にスコープされるところだね。

そうだね。著者は、あまり複雑でないページでウェブコンポーネントを使った経験がないか、意図的にその複雑さを隠しているように感じる。現実的には、純粋なウェブコンポーネントを作るのはあまりおすすめできないよ。フレームワークを使って構築するのがいいと思う。言い換えれば、フレームワークを使わずにウェブコンポーネントだけでページを作ることはできるけど、そのやり方ではReactのページを変換するのは難しいよね。

シャドウDOMとそれに付随するCSSのエンキャプスレーションにはまだ心を掴まれてないけど、カスタム要素は結構使う。多くの場合、状態がシンプルでDOMに住める小さなコンポーネントが必要だから。カスタム要素はライフサイクルフックを提供してくれるから、基本的なコンポーネントにはそれだけで十分なんだ。

実際には、ページとは別のカプセルに入っているわけじゃないよ。CSS変数は「ライト」/通常のDOMから漏れ込んでくる。ホストからshadowRoot.querySelector()で要素をクエリできるし、要素は親からスタイルを継承することもある。閉じたルートにすることもできるけど、最後にチェックしたときは、深刻なアクセシビリティの問題があったよ。(ちなみに、だからこそ、リンクされた記事が「グローバルスタイルは漏れない(明示的に許可しない限り)」と言っているのは間違いだと思う。)

確かに、Shadow DOMって新しいiframeみたいで、主に広告ネットワークや「埋め込み」に使われてる気がする。Web Componentsで作るものとはあんまり関係ないかな。多くの開発者がShadow DOMに夢中になってるのは面白いけど、私にとってはWeb Componentを「Light」DOMに全部置いて、CSSにカスケードの役割をやらせて、ページに合わせてWeb Componentが適応するのが理想なんだよね。孤立したスタイルの島になってほしくないな。

UI階層の深いところにあるコンポーネントが、DOMツリーをバブルアップするイベントを発火できる。Reduxが生まれた理由を再発見しようとしてる人たちがいるみたいだね。

Reduxはイベントを上に上げて新しいデータを下に送るだけでよかったんじゃないかな。

Home Assistant [1]はウェブコンポーネントを使って書かれていて、素晴らしいよ。私たちが13年間活動してきた中で、フロントエンドを完全に書き直す必要は一度もなかったし、必要に応じてコンポーネントを徐々に更新してきた。JavaScript業界のアップグレードサイクル(短い!)に縛られないことで、自分たちの優先順位を選べるようになった。現在はLitをフレームワークとして使ってる(必要だよ、全然問題ない)。状態管理はプロップスを回すだけで、うまく機能して、コミュニティが簡単にカスタムカードを開発できるようになってる。欠点は、利用可能なコンポーネントが少ないこと。特定のフレームワークに縛られていないから、どのウェブコンポーネントフレームワークでも選べるけど、選択肢はちょっと限られてる。今はマテリアルコンポーネントを使っていて、一部をShoelaceに移行中。去年、Syntaxポッドキャストで私たちのフロントエンドへのアプローチについてもっと話したよ。[1] https://www.home-assistant.io [2] https://syntax.fm/show/880/creator-of-home-assistant-web-com...

おお、HNで見かけるなんて嬉しい!最近、あなたのコードベースを見て、自動化の扱い方をチェックしてたんだ。asyncioに頼ってるみたいだけど、どうしてその決定に至ったの?APSchedulerや他のジョブライブラリのような代替案を考えたことはある?

Hacker Newsで議論の続きを見る