ハクソク

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

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

94日前原文(caimito.net)

概要

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

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

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

すでに起きている変化

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

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

  • フレームワーク特有の 学習コスト や メンテナンス負担 からの脱却
  • Web標準 で作れば、10年前のコードも動作する安定性
  • Angular 1 や Reactクラスコンポーネント、 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が解説
  • connectedCallback と constructor の違いもすぐに理解
  • ドキュメント全読破不要、実践しながら学習

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

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

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

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

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

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

今日から始める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や他のジョブライブラリのような代替案を考えたことはある？

└

サイクルは、毎年言われているほど短くないよ。2014年からReactを使ってるけど、6〜7年であまり変わってない。最近、Reactだけを依存関係にしたスクリプトタグベースの再利用可能なライブラリを作ったんだけど、シャドウDOMやダイアログのおかげで、普通のJSよりもずっと高品質な開発体験が得られたよ。

└

Home Assistant [1]はWeb Componentsを使って書かれていて、すごく良いよ。スライダーを動かしたときに現在の値のツールチップが表示されない理由はこれかもね :P

└

JavaScript業界のアップグレードサイクルに縛られない（短いからね！） > 現在、私たちはその上にLitを使ってる。この二つは矛盾してるよ。1. LitはReactよりも新しく、Polymerの完全に互換性のない代替として始まった。2. 「フレームワークじゃなくてライブラリ」として積極的に宣伝されてるけど、「速い動きのJS」からの機能をどんどん取り込んでるよ。カスタムの独自構文からコンテキスト、コンパイラ、「フックのルール」（カスタムのディレクティブルール）など。 > 現在、マテリアルコンポーネントを使っていて、一部をShoelaceに移行中。これもまさに君が言ってる「速いJSの回転」だね。

└

かなり独立したWeb Componentsをいくつか作ったことがある。Litについては結構調べたけど、「なぜ」必要なのかは完全には理解できなかった。誰か自分の経験をシェアしてくれない？Litが必要だった理由は何？標準の仕様のWeb Componentsではできないことを何を提供してるの？私にとってWeb Componentsの大きな魅力は、npm installが必要ないことなんだ。私はコンポーネントをプレーンなJSファイルとして出荷するのが好きで、CDNからホットリンクするか、ダウンロードしてローカルで提供することができる。ちょっと偏執的かもしれないけど、ノードモジュールがクリーンでバloatやスパイウェアがないとは完全には信じられないし、定期的に更新するのも面倒なんだ。Web Componentの静的JSファイルを一度ダウンロードして、中を読んで、忘れる方がいい。将来的にメンテナンスの一環としてそのコンポーネントのソースを再訪するかもしれないけど。例えば、私はシンプルな「いいね」ボタンのコンポーネントを作った[1]。その後、友達が面白い絵文字のコンフェッティを表示するコンポーネントを作った[2]。いいねコンポーネントに属性が設定されている場合にオプションでそれを取り込むことにした。彼のソースをダウンロードして、自分のドメインからホストした。でも、実は彼のコードにバグがあって、いいねボタンを何回も連打するとコンフェッティが「降ってくる」ことになってた。彼はそれを修正したけど、実はそのバグが気に入ってたから、コンフェッティコンポーネントのソースは更新しなかった。 [1]: https://catskull.net/likes [2]: https://github.com/samwarnick/confetti-drop

└

ステート管理については、Lit Stateをチェックしてみるといいかも。これはLit専用に書かれたとても軽量なステート管理ライブラリで、同じ考え方で作られてるんだ。これを使えば、常にプロップをあちこちに渡す必要がなくなるよ。https://github.com/gitaarik/lit-state

彼らのフレームワークフリーなナラティブにはうんざりしてきた。彼らがやってるのは、ブラウザの中で、仕様やプラットフォームへの提案を通じて、自分たちのフレームワークのアイデアを押し込んでるだけだ。ブラウザメーカーへの影響力を使って、これらの実験を実装することから逃げてる。ウェブコンポーネントは解決策として提示されているけど、グリッチのないUIの解決策は、状態とプレゼンテーションのメカニクスのコラボレーションだ。ウェブコンポーネントはメカニクスや前提が多すぎて、少し複雑なものには使えない。使いにくくて、エッジケースが多いんだ。ElementInternals（フォーム）、アクセシビリティ、半分のスタイルエンキャプスレーション、状態共有、などなど。フレームワークは協力して、研究し、解決策を見つけて技術を前進させる。SolidJS（シグナルで道を切り開いている）がSvelteやReact、Preactの開発者と健全な議論をしているのは珍しくない。一方で、ウェブコンポーネントグループは、あなたの意見を無視して、参加する自由があると言いつつ、結局は自分たちの見解を押し付けてブラウザに実装してしまう。利害の対立がある。これが、すべての人に影響を与える欠点で、彼らの非ユーザーにも影響が出る。この記事のように、これを万能薬として売り込むけど、実際は非常に複雑で多くの前提を持っていて、WCはライブラリやフレームワークとほとんど機能しない。

└

そうだね、MicrosoftのDHTMLやビヘイビアはまさにそれで、ものすごいロックインを引き起こしてた。しかも、ひどかった。歴史を知らない人は、本当に同じ過ちを繰り返すことになるよ。

└

わあ、これは変なコメントだね。「彼ら」とは誰のこと？JSフレームワークに対する巨大な陰謀があると思ってるみたいだね。イルミナティが関わってるの？冗談だけど、ブラウザの機能ってそんなもんだよ。機能が十分なブラウザに入るまで何年もかかることがあるから、JSフレームワークの流動性とはかなり違う。こういう議論はいつも出てくるけど、毎回同じ返事をしてるんだ：みんながやってることにフルフレームワークが必要なわけじゃない。彼らは他のフレームワークや第三者とコードを共有する必要があるかもしれないしね。投稿でも、ウェブコンポーネントがあなたに合わないかもしれないって言ってるし。

└

私たちは、ウェブコンポーネントのアイソレーション機能を使って、パートナーが他のCSSやJSを使っていてもウェブページに埋め込めるReactアプリケーションを作っているんだ。100個の小さなウェブコンポーネントを個別のボタンレベルで作るのはどうかと思うけど、自己完結型のウィジェットがウェブページにポップアップするのは素晴らしいと思う。

└

理想的には、さまざまなフレームワークで試された良いアイデアが、時間をかけてブラウザに取り入れられていくべきだと思う。例えば、シグナルの提案（https://github.com/tc39/proposal-signals）については、ウェブコンポーネント仕様の元々の4つの部分（カスタム要素、シャドウDOM、テンプレート、モジュール）が、さまざまなレベルで試されてきたことに同意する。おそらく最も価値のあるアイデア（カスタム要素とESモジュール）は、最も優先されていたものだろう。

フレームワークは協力し、研究し、一緒に解決策を見つけて技術を前進させる。 SolidJS（シグナルを使って道を切り開いている）が、SvelteやReact、Preactの開発者たちと健全な議論を交わしているのは珍しくない。この話は、ページ内フレームワークの相互運用性という非常に現実的な問題から少し逸れている気がするけどね。これは開発者同士がアイデアを共有するのとは違うから。

└

ウェブコンポーネントが大好きだけど、シャドウDOMを突き破るプロパティがたくさんあるせいで、「一度作って、異なるアプリケーションで再利用する」という目的が台無しになってる。よく遭遇する落とし穴の一つは、HTMLの基本フォントサイズだね。これがウェブコンポーネントの計算に影響を与えるから、フォントサイズが12/14/16のウェブコンポーネントを使うと、全然違う挙動になる。もし本当に隔離されていたら、もっとスケールするはずなのに、そうはならないんだ。

└

ウェブコンポーネントには多くのメカニクスや前提が詰め込まれていて、少し複雑なことには使えない。これらは非常に使いにくく、エッジケースが多い。ElementInternals（フォーム）、アクセシビリティ、半分スタイルカプセル化、状態共有など。これらはDOM自体にも言えることだよね。だから、フレームワークが最初に作られたんだ。カスタム要素APIは複雑だし、DOMも複雑。後者には慣れているけど、前者には慣れていないだけなんだ。

└

同意する。ウェブコンポーネントは、コンポーネントベースのフレームワークの1対1の置き換えにはならない。多くの期待があったけど、実装が不足している。

└

Web Componentsにはメカニズムや前提が多すぎて、ちょっと複雑なことには使えない。私の経験（ネイティブWeb Components、Polymer、Litライブラリでの8年間）とは全然違うな。Web Componentsだけで驚くほど複雑なビューを作れるよ。実際にやってるし、これからもやるつもり。具体的にWeb Componentsが使えないと思う理由は何？「ちょっとした複雑さ」のラインをどう定義してるの？

└

Web Componentsは開発者が自分のHTML要素を作るための方法に過ぎないよ。ブラウザがすでに組み込みのHTML要素をつなげるフレームワークである限り、彼らは「フレームワーク」と呼べる。DOMツリーに参加するノードを組み込みコンポーネントだけに制限する理由はないと思う。他のGUIフレームワークは全て開発者が自分のノードを作れるのに、なんでウェブはそうじゃないの？ > メカニズムや前提が多すぎて、ちょっと複雑なことには使えない。具体的な例はある？どの「メカニズム」を指してるの？Photoshop、Reddit、インターネットアーカイブ、YouTube、Microsoft App Store、Home Assistantなどの非常に複雑なアプリがWeb Componentsで作られてるのに、使えないっていう主張はちょっとおかしいよね。君のコミュニティに対する他の具体的な不満から、君が誰かは推測できるけど。その人は私たちのDiscordサーバーに来て、みんなに対してすごく意地悪で失礼だったから、何人かに「落ち着け」って言われてたよ。みんなが悪いアイデアだと思った提案を一つして、フィットを投げて「私たちは全然聞いてない」って言ってた。場所に来て悪い態度を取っておいて、コミュニティに拒絶されたからって文句言うのはおかしいよ。

自分はバニラJavaScriptとウェブコンポーネントに傾いていて、大きなフレームワークは避けて、軽量なもの、あるいは場合によってはフレームワークなしでやってるんだ。ただ、この記事や他の多くのウェブコンポーネントに関する記事は、ウェブコンポーネントの使い方を誤解していると思う。1. 「フレームワークなし」ということ フレームワークというのは、NextJSのような大規模なものから、enhance.devのような軽量なもの、あるいはshoelaceのようなUIに特化したものまで色々ある。完全にフレームワークから自由であることが何らかの利点をもたらすかもしれないけど、フレームワークには一貫した規約やパターンを強制するという主な利点がある。公平に言えば、この記事でもフレームワークの重要性について触れていて、フレームワークの主な利点の一つを言い表そうとしている部分がある。「開発者がフレームワークのパターンを期待している場合、ウェブコンポーネントは摩擦を生むかもしれない。」チーム内では、パターンがないよりはある方がいい。フレームワークはパターンを強制するのに役立つ。ウェブコンポーネントの有無にかかわらず、パターンがないと摩擦やスパゲッティコードが生まれる。2. ウェブコンポーネントとシャドウDOMは一緒に使うべき 理由はわからないけど、ほとんどのウェブコンポーネントのチュートリアルは、メインDOMではなくシャドウDOMでのレンダリングから始まる。スタイルをカプセル化するという考えは安全に思えるけど、ページの一部がメインページの後にレンダリングされることになるから、DOM要素が「フラッシュ」してスタイルのないコンテンツが表示されることがある。自分にとって、この不安定なUXはスタイルをカプセル化する利点を打ち消してしまう。さらに、もしスタイルが互いに漏れ出している状態なら、プロジェクトには他に解決すべき問題があると思う。シャドウDOMには使い道があるけど、個人的には過大評価されていると思う。

└

理由はわからないけど、ほとんどのウェブコンポーネントのチュートリアルは、メインDOMではなくシャドウDOMでのレンダリングから始まる そう、これが多くの人をウェブコンポーネントの使用から遠ざけてるよね。そして、これは普通のアプリで使うには実際的な制限になってる（埋め込まれたスタンドアロンウィジェットは理解できるけど）。

ウェブコンポーネントは、ブラウザがすでに実装すべきだったもの、例えば、使いやすいアコーディオンやコンボボックス、日付ピッカーを実装するのに最適な方法だと思う。主に静的でコンテンツが多いAstroサイトで使うのが楽しい。でもそれを超えると、アプリ全体の状態やリアクティビティに対応できるフレームワークなしでは、あまり使えないんだよね。それでも全然問題ない！良いニッチを埋めてると思う。ただ、ブラウザがAPIを提供しているからといって、いつでも使うべきだとは限らないよ。

└

アコーディオン：``を使って、好きなようにスタイルすればいい。アコーディオンにJSやウェブコンポーネントはもう必要ない。コンボボックスや日付ピッカー：CSSフォームコントロールスタイリングレベル1 [1] は大きなゲームチェンジャーになるだろう。appearance: baseを使えば、ブラウザのフォーム入力の各部分をCSSだけでスタイルしやすくなる。スタイルの仕方についての意見が少なく（プラットフォーム特有になりすぎず、もっとウェブプラットフォームに一般的）、コンポーネント部分のCSSセレクタが増えるからね。それでも、ネイティブフォームコントロールのアクセシビリティはそのまま維持される。今度の草案が今年進展することを本当に期待してるよ。[1] https://www.w3.org/TR/css-forms-1/

Vue 3でUIを書くのが一番楽しいのは、JavaScriptの狂ったOOPメカニクスに縛られず、普通の関数を使えるところだね。「this.foo.bind(this)」みたいな呪文を気にせずに済むのがいい。ウェブコンポーネントはJSのOOPシステムを完全に受け入れてるけど、まあ、彼らに任せておくよ。あと、「シャドウDOM」みたいなものを扱うのもあまり好きじゃない。これはフレームワークが最初に抽象化すべき実装の詳細に思えるから。ウェブコンポーネントは他のフレームワークの良いコンパイル先のようだけど、直接扱うのはまだちょっと抵抗があるな。

90年代からウェブの開発をしてきたけど、Web Componentsの普及が遅いのはちょっと変に感じてる。Glenn MaddernのJSConf EU '13でのX-GIFトークが、ブラウザをHTMLタグの固定されたセットを超えて拡張することに目を開かせてくれた。すごくワクワクしてWeb Components v1での開発を始めたけど、Reactがあまりにも強力で、全然 traction が得られなかった。正直、彼らにも本当の問題があったし（Litみたいなものがないと作るのが難しい、複雑な非同期ライフサイクル、リアクティブフレームワークは他のものが状態を持つのが嫌い）。2020年頃、Video.jsをほぼ10年作ってきて、あらゆるフレームワークでプレーヤーを動かすのに疲れて、Media Chrome（https://www.media-chrome.org/）をWeb Componentsとして作り始めた。もう6年近く出ていて、npmの統計を見ると、ここ1年、特にここ数ヶ月で週に100万回以上ダウンロードされるようになった。何がその要因かはわからないけど、見ていて面白い。3月にVideo.js v10のベータ版を出す予定で、ゼロから作り直してMedia Chromeと統合した。Web Componentsだけでなく、Reactのイディオムに沿ったバージョンも意図的に作っている。単にラップしたWeb Componentsではなくて、Web Componentのバージョンが実際に人気になるのか興味がある。

ダッシュボードプロジェクトのTHINK（https://think.iotdata.systemsで公開中）でカスタムHTML要素を試してみたんだけど、バニラウェブコンポーネントだけでこんなに機能があるなんて驚いてる。ソースはGitHubに載せてるし、他のプロジェクトや作業についてはhttps://marchildmann.comでドキュメントも書いてるから、興味があったら見てみてね。