Web Componentsは近い将来、Webアプリケーションの作り方を変えるだろう。Web Componentsの中核的な機能は、まるでライブラリのように、デベロッパがユーザインタフェイスの独自の部位/部品（コンポーネント）を作り、それらをHTML上で、デベロッパが命名した任意の名前のタグ（たとえば<datepicker>）で再利用できることだ。そんなWebコンポーネントを作るのは簡単ではないが、基本的にはHTMLとCSSとJavaScriptの知識だけあればよい（”Shadow DOM”に関する知識もあった方がよいかも）。Web Componentsの標準化プロセスはまだまだ時間がかかりそうだが、GoogleとMozillaはその前からいろんな取り組みを開始している。
しかし、まだほとんどのブラウザがサポートしていないのに、Web Componentsはどこから手出しをしたらいいのだろう？ そこで、polyfillというコンセプトが登場してくる。また、GoogleのPolymerフレームワークや、Mozillaの地味な名前のpolyfillライブラリx-Tagというものもある。polyfillというコンセプト自体は、かなり前からある。その考え方は、ブラウザがネイティブに持っているAPIをJavaScriptなどで複製して、クロスブラウザで使えるようにすることだ（それをまだネイティブでサポートしていないブラウザ上でも）。それは要するに Modernizrなどが使ってるのと同じコンセプトだが、GoogleとMozillaのプロジェクトは同じ低レベルのWeb Components用polyfillsを共有している。
Googleは今年初めのI/OカンファレンスでPolymerフレームワークを紹介したが、それは明らかにGoogleが今後長期にわたって推進したいと考えているコンセプトだ。Mozillaもこのバスに乗り遅れたくないので、このたび、x-TagベースのクロスブラウザなライブラリBrickをローンチした。それは、説明によると、“一般的によく使われるユーザインタフェイスパターンを、使いやすく柔軟性に富みそしてセマンティックなWeb Componentsに抽象化する、新しいカスタムHTMLタグ集”、を提供するものだ。
Brickを使うことによってデベロッパは、ベーシックなインタフェイス成分、たとえばヘッダメニューや日付指定、カレンダーなどや、もっと複雑なアニメによるトランジションのあるスライドデッキなんかを、単純にBrickのスタイルシートやJavaScriptライブラリへのリンクをドキュメント（Webページ）に書き、それからカスタムのHTMLタグを使って、それらの新しいインタフェイス成分を呼び出せるようになる。
Mozillaも認めるように、それまでは、そういう新しいユーザインタフェイス成分を使うためにはjQuery UIみたいなものを使い、定型的でノンセマンティックなマークアップをHTML中に置いて、初期化や管理もJavaScriptで明示的に書く必要があった。またそういうタグの多くは、カスタマイズしようと思うと大量の属性を加える必要があった。
将来的には、Web ComponentsはデベロッパによるWebアプリケーションの作り方を変え、UI成分の再利用や共有を容易にするだろう。MozillaとGoogleが積極的にその開発を支援しているから、やがてpolyfillsは、レガシーブラウザをサポートするためにのみ、必要なものになってしまうと思う。ただしメジャーなブラウザのすべてがWeb Componentsをサポートするのは、さらに先かもしれないが。
[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）
