Web ComponentsはJavaScriptフレームワークを超えて生き残る

• Web Componentsの長寿命性と柔軟性についての記事。JavaScriptフレームワークと比較
• プロジェクトの技術選定は、デフォルトの選択肢ではなく、プロジェクトの制約によって決まるべきだという筆者の主張
• 筆者がプロジェクトにバニラJSのWeb Componentsを選んだ理由: 移植性とHTMLレンダリング能力
• 筆者のブログは、Astro、Hugo、PHPで書かれたカスタムCMS、Tumblr、Movable Type、WordPressなど、さまざまなツールで構築されてきた
• Markdownで書かれたプレーンテキストファイルにコンテンツを保持する利点を強調。システム間でのコンテンツ移行プロセスを簡素化
• Astro固有の機能は便利ではあるが移植性がないため、プロジェクトでは使わなかったという筆者の主張
• Web ComponentsはMarkdown内でHTMLとして記述でき、その結果、Markdownコンテンツの他の部分と同じくらい高い移植性を持つ
• Web Componentsは、再利用可能なHTML要素を構築するためのW3C標準群であり、すべてのHTML、CSS、JSを単一ファイルにカプセル化でき、ビルドシステムも不要
• Web Componentsは外部から設定できるように属性を公開できると筆者は指摘。ネイティブのpropsに類似
• 保守性と依存関係のトレードオフへの懸念から、Lit、Stencil、SvelteのようなWeb Componentsにコンパイルするフレームワークではなく、バニラJSを使うことにした筆者
• TypeScriptのような依存関係は有用な機能を提供しうるが、新しいバージョンやAPIとの互換性を維持するために時間と労力が必要だという筆者の主張
• ユーザーが制御できない依存関係を避け、長期的なアクセシビリティとWebコンテンツのレジリエンスのために、安定していると分かっている標準に従うことの重要性を強調
• Webを長寿命性を念頭に置いて使うなら、最もレジリエントで移植性が高く、将来にも備えられるコンピューティングプラットフォームだと称賛して締めくくる筆者の結論

[GN⁺]

Hacker Newsの意見

• Web Componentsの長期的な持続性についての記事で、JavaScriptフレームワークと比較している
• コメント投稿者たちは、htmxライブラリが記事で言及されておらず、サーバーと状態を同期することに重点を置いている点でWeb Componentsとは異なると指摘
• htmxは依存関係がなく、後方互換性を重視している点で、多くのJavaScriptライブラリと違って高く評価されている
• Web Componentsの状態管理は未解決の問題として挙げられ、開発者がラッパーフレームワークなしで直接対処しなければならない
• Web Componentsのパフォーマンスは予想されるほど重要ではなく、インスタンス化コストのために一部の小さな要素はWeb Componentsから差し戻されている
• Web Componentsは、使用しているフレームワークに関係なく新しいページに簡単に追加でき、スタイルのカプセル化の点で評価されている
• 一部のコメント投稿者は、Web Componentsのような静的ソリューションよりもJSフレームワークの進歩と改善を好むと述べている
• 新しいプロジェクトを始める際には、チームの知識とスキルを考慮することの重要性が強調されている
• Rails Hotwire、Phoenix Liveviews、Laravel Livewireのようなサーバー側ソリューションが興味深い発展として言及されている
• Web Componentsはサーバー上で実行できず、それらをレンダリングするにはクライアント側のJSが必要だという点で批判されている
• Web Componentsでのslotの使用はわかりにくく複雑だと指摘され、アプリケーション構築における魅力を下げている
• DOM APIは、コンポーネントを組み合わせてアプリケーションを動作させるのには適していないと批判されている
• Web Componentsは、属性やイベント名の自動補完のような機能に対するエディタサポートの不足を批判されている
• Web Componentsにおける一部の基本機能、たとえばフォーム内のボタンなどは、依然として未解決の問題として残っている