ウェブコンポーネントは問題ない

 (nolanlawson.com)
2 ポイント 投稿者 GN⁺ 2024-10-01 | 1件のコメント | WhatsAppで共有

ウェブコンポーネントは問題ない

  • ウェブ開発コミュニティでは、ウェブコンポーネントをめぐってしばしば議論が起こる
  • Ryan Carniato は "Web Components Are Not the Future" という記事を書き、Cory LaViska は "Web Components Are Not the Future — They’re the Present" という記事で応答した
  • 著者はこの論争を平和的に整理しようとしている

パフォーマンス

  • ウェブコンポーネントは Custom Elements を基盤としており、すべてのインターフェースは DOM を通じて処理される
  • DOM ノードを最小限にすることが、パフォーマンス最適化の核心である
  • しかし、パフォーマンスだけがすべてではなく、保守性、セキュリティ、使いやすさ、アクセシビリティなど他の要素も考慮する必要がある
  • たとえば、aria-* 属性をレンダリングしなければパフォーマンスは向上するかもしれないが、アクセシビリティのためには必須である
  • パフォーマンス最適化は重要だが、実際にはレイアウトスラッシング、ネットワークウォーターフォール、不要な再レンダリングといった、より単純な問題のほうがパフォーマンスに大きな影響を与える

標準のコスト

  • 標準をサポートするには、追加のコード記述と実行が必要になる
  • しかし、ウェブコンポーネントをサポートすることは大きな負担ではない
  • 新しいウェブプラットフォーム機能を考慮するのは当然のことであり、これは Symbols、Proxies、Promises などにも当てはまる
  • ウェブ開発コミュニティの一部はウェブコンポーネントをサポートしたくないかもしれないが、それでも構わない
  • ウェブは多様なアプローチを許容する大きなテントである

結論

  • ウェブコンポーネント自体に問題はないが、あらゆるものを置き換えられるという約束は危うい
  • ウェブコンポーネントはサーバーサイドレンダリング、アクセシビリティ、相互運用性などの面で弱点を持つ
  • React、Solid、Svelte など、他のフレームワークが依然として輝く領域がある
  • ウェブはさまざまな用途に使われており、それは創造性を表現する機会を提供する
  • ウェブコンポーネントが自分に合わないとしても、それで構わない

# GN⁺のまとめ

  • この記事はウェブコンポーネントに対するさまざまな視点を示し、パフォーマンスと他の要素とのバランスを強調している
  • ウェブコンポーネントはすべてを置き換えることはできないが、特定の用途には適している
  • ウェブ開発コミュニティは多様なアプローチを許容しており、それが創造性を高めている
  • ウェブコンポーネントが合わないなら、他のフレームワークを使うこともできる
  • ウェブの多様な機能は、新しい創造的表現の機会を提供する

関連記事

1件のコメント

 
GN⁺ 2024-10-01
Hacker Newsの意見

  • 「Web Components Are Not the Future」という記事には、説得力のある主張が不足していると感じた

    • 現在のフロントエンドフレームワークの状況は混沌としている
    • 複雑なフレームワークを学びたくない
    • ドキュメントなしでは理解できない魔法のような機能は求めていない
    • Web Componentsは直感的で、Shadow DOMによる分離機能を提供する
    • React時代に残すべきなのはJSXだけだと思う

  • 人々はそれぞれ異なる最適化を追求しているため、意見が分かれる

    • VC支援のスタートアップではフレームワークが適しているかもしれない
    • 学術研究室では、保守コストの低いWeb Componentsのほうが良い
    • VueからWeb Componentsへ移行した経験は非常に良かった
    • 依存関係が減り、管理しやすくなった

  • SvelteはCustom Elements APIを通じてWeb Componentsの生成をサポートしている

    • SvelteはJS/HTML/CSSにコンパイルされ、再利用可能なコンポーネントを簡単に作れる

  • Web Componentsはフルスタック開発者の生活をより良くするものではないと思う

    • ほとんどの例は、HTMLにデータをテンプレート化するだけにすぎない
    • それはすでにHandlebarsでできることだ

  • Web ComponentsとShadow DOMは、ブラウザー拡張機能の動作を妨げる可能性がある

    • ブラウザーベンダーはこの問題の解決を急いでいない

  • 相互運用性には性能コストが伴う

    • 複数のフレームワークがそれぞれ独自のランタイムを持つため、性能低下が発生する可能性がある
    • Web Componentsは技術的に遅れており、複雑さを増大させる

  • Web Componentsは現在のフロントエンドの問題を解決できると思う

    • 性能が高く、データテーブルを滑らかにスクロールできる
    • Web Componentsライブラリを準備中だ

  • 250,000行のJSコードベースを引き継ぎ、Web Componentsへリファクタリングしている

    • コードを50,000行削減した
    • 既存コードの機能を理解する助けになっている

  • Web ComponentsはJSなしでも動作できる

    • プログレッシブエンハンスメントのために何度か使ってみた
    • サーバーサイドレンダリングとうまく動作する

  • フレームワークとWeb Componentsは、それぞれ異なる問題を解決するためのツールだ

    • フレームワークは状態に応じたビューのレンダリングを担当する
    • Web Componentsは状態管理の問題を解決しない
    • 両者は共存できると思う