Webコンポーネントは何年もの間、ほぼ完成に近い状態にある標準だ。先日のApple Music Webクライアントのリリースでは、Apple Musicのエクスペリエンスを実行する45以上のWebコンポーネントがリリースされた。その他にもAmazonやPorsche、arm、Panera、MicrosoftなどがStencilを活用して、デザインシステムやクロスフレームワークのWebコンポーネントを開発している。
Webコンポーネントがツールやライブラリを凌駕するには、いくつかの課題がある。Webコンポーネントに関して指摘される一般的な懸念は、次のようなものだ。
- 各コンポーネントのバンドルサイズが大きくなる可能性がある(フレームワークのバンドルサイズ、あるいはHTMLインポートのサポートの欠如による)
- コンテンツのレンダリングに関するコントロール
- スタイル定義されていないコンテンツ内のFlashやJS内のCSS
- 旧型のブラウザではポリフィルが必要になる
- プロパティとアトリビュートの管理
- サーバサイドレンダリングとプログレッシブエンハンスメント(progressive enhancement)
これらの懸念は、Ionicチームの立ち上げたオープンソースプロジェクトのStencilのようなツールを活用することで軽減される。IonicのCEOであるMax Lynch氏が説明するように、現在のWebコンポーネントのスイートスポットは、一般的に使用されているJavaScriptフレームワークとは異なる場所にある。
ネイティブなWebコンポーネントを提供することで、実際に解決される問題は何でしょうか？最も大きなものは、アプリケーションのテクノロジに関わりなく、開発者の作ったコンポーネントをブラウザ内で直接的に、極めて効率的な方法で共有し、利用することが可能である点です。Webコンポーネントのキラーアプリは、これらのコンポーネントの提供と、デザインシステムに関わる問題の解決にあります。一方で、マーケットの90パーセントにはこのような問題はないので、Webコンポーネントのメリットに関する議論はある意味で非生産的だとも言えるのです。
Stencilを活用することによって、Ionicは、AngularやReact、Vueをサポートするクロスフレームワークなコンポーネントを活用するカニズムを提供する(後者はベータサポート)。Ionicの新リリースのユーザは、デフォルトとしてWebコンポーネントを開発することで、コンポーネントライブラリを他のフレームワークにもシームレスに転換することが可能になる。
最新のDojoでは、Webコンポーネント標準のカスタム要素部分のサポートに重点が置かれており、フレームワークの相互運用性に関するメカニズムを提供している。Dojo custom element showcaseでは、カスタム要素として活用の可能な既存のDojoウィジェットが紹介されている。
Webコンポーネントを使った開発には他にも、HybridsやLitElement(Polymerの明確な後継)、Skate.js、Slim.jsなど、数多くの選択肢がある。Material DesignをWebコンポーネントによって実装したmaterial-componentsもある。
ツーリングとフレームワークの改善によるWebコンポーネントのブラウザサポートの進歩、フレームワークおよびアプリケーション間でのコンポーネント再利用に関わる継続的な課題によって、WebコンポーネントはAppleやAmazon,Microsoftなどにおいて開発の主流となっている。
Webコンポーネントは、Webプラットフォームとその標準に準拠することにより、今日開発した成果がアプリケーション開発に選択したフレームワークよりも長い寿命を持つための、一種の保険としての役目を果たすことになる。組織によっては、すべてのアプリケーションに唯一のフロントエンドフレームワークとしてWebコンポーネントを使うということで、議論がすでに終了しているかも知れない。
Webコンポーネントを使い始めるには、Pascal Schip氏の"Web Components: from zero to hero"など、数多くのリソースがある。Webコンポーネント標準に関する詳細な資料は、MDNやwebcomponents.orgで見ることができる。