あけましておめでとうございます。よういちろうです。多くの人が様々なデバイスからウェブにアクセスすることが当たり前となりましたが、ウェブをさらに進化させるために、現在も数多くの試みが行われています。その中で、本稿ではWeb Componentsを取り上げてみます。

Web Componentsの構成要素

Web Componentsは普及していない技術ですので、まだ知らない方も多いと思います。どのようなものかを簡単に紹介しておきましょう。Web Componentsは、以下の4つの仕様を組み合わせた際の総称です。

Templates

JavaScriptから利用することができるDOMベースのクライアントサイドのテンプレート仕様です。<template>タグのことです。最新の仕様は、WhatWG HTML Templatesです。

HTML Imports

関連するHTML、CSS、JavaScriptファイルなどをまとめてロードするための仕様です。最新の仕様は、HTML Imports W3C Editor's Draftです。

Custom Elements

独自の要素を登録し利用するための仕様です。最新の仕様は、Custom Elements W3C Working Draftです。

Shadow DOM

DOMツリーに対してカプセル化（スコープの隔離）を実現するための仕様です。最新の仕様は、Shadow DOM W3C Working Draftです。

これらを組み合わせることによって、ウェブアプリケーションのUIについて、部品（コンポーネント）という単位で作成することが可能になります。今までは、一つの巨大なDOMツリーを相手にしてUIを構築していましたが、Web Componentsの登場によって、部品を組み合わせてUIを構築できるようになると期待されています。

2016年末での状況

まずは早速昨年末の状況から振り返ってみましょう。以下の表は、主要ウェブブラウザのWeb Componentsのサポート状況です。

Web Componentsの構成要素すべてをウェブブラウザがネイティブサポートしているのは、ChromeとOperaのみです。その他のウェブブラウザは、部分的なサポートにとどまっています。

Web Componentsを試したい時は、実際には上記の表で掲載されたすべてのウェブブラウザで既に試すことができます。数多くの×マークがついているウェブブラウザについても、その穴を埋めてくれる機構（Polyfill）を利用することによって、Web Componentsを試すことが可能です。しかし、そのPolyfillも完全ではなく、どうしてもネイティブサポートしているウェブブラウザとの挙動の差が出てしまいますし、動作スピードについても雲泥の差が出てしまいます。

やはりWeb Componentsは、主要ウェブブラウザがネイティブサポートして初めてその実力が発揮されるようになるのですが、現状は上記の通りです。例えば、Shadow DOMという単語が最初に広まったのは、2011年1月14日に投稿されたDimitri Glazkov氏のブログエントリ“⁠What the Heck is Shadow DOM?⁠”だと思いますが、それから既に6年近く経過しています。ただでさえ流れの速いウェブの世界で、一つの仕様の検討と実装の作業が6年続いて、しかもまだ足並みが揃っていない状況は、異例中の異例と言えるでしょう。

それでも現在継続されていることから考えても、Web Componentsについて多くの人々がその将来に希望を持っている証拠と言えます。

Shadow DOMがついにSafariで使えるようになった

2015年までは、Web Componentsについてかなり悲観的な見方をする方が多かったと記憶しています。主要なウェブブラウザを開発している各ベンダー間でのWeb Componentsに対する温度感の違いが大きく、Web Componentsが目指す未来が本当に来るのだろうか？と疑問視する声も良く聞きました。

現在のウェブアプリケーションは、一つの大きなDOMツリーにて構築されています。そのDOMツリーに対して、JavaScriptやCSSが適用されています。近年のウェブアプリケーションの画面は非常にリッチであり、しかしMaterial Designやその他のデザインを統一してユーザ体験を向上させようとする試みもあり、また数多くのフレームワークやUI部品集といった乱立状態も相まって、とてもカオスな状況です。このカオスな状況が、無防備な一つのDOMツリー上で形作られていることは、本当に奇跡といっても良いかもしれませんし、フロントエンドエンジニアの努力によって成し遂げられていると言えるかもしれません。

複数のフレームワークやライブラリを組み合わせた際に、DOMの要素のIDや、CSSでのスタイル定義など、重複しない保証はどこにもありません。それを常に意識して気をつけながら開発をしなければならない状況は、Shadow DOMがもたらすDOMツリーのカプセル化が打破してくれます。これにより、部品間でJavaScriptやCSSが干渉することが避けられますので、Web Componentsの中でも最も重要な技術要素になります。

しかし、2014年にWebkitからBlinkにforkされる際に、AppleはWebkitのソースコードからShadow DOMに関するコードを削除した歴史があります。この時の反響は非常に大きく、ネット上でも騒ぎになりました。Web Componentsの未来は遂にここで終わってしまうのでは？と思った方も多かったはずです。WebkitベースのSafariがWeb Componentsをサポートしないということは、世界で数多く出荷されているiOSデバイスではWeb Componentsはサポートされないことを意味してしまいます。これは死活問題です。

この懸念は、2016年に完全に払拭されたと言って良いでしょう。ついにAppleはWebkitにShadow DOMを実装し終わり、Safari 10.0においてShadow DOMがネイティブサポートされました。Safari 10.0に実装されたものは、Shadow DOM v1と呼ばれる仕様であり、これはBlinkでしかサポートしていなかった過去のShadow DOM仕様とは異なり、各ウェブブラウザ開発ベンダー間で仕様の調整と合意がされた仕様です。FirefoxについてもShadow DOM v1の実装が既に開始されていますので、先述の表の△が○になる日も近いと言えるでしょう。

Shadow DOMのサポート状況が大きく前進した2016年は、Web Componentsにとって本当に嬉しい年となりました。

Custom Elementsも着実に前に進んでいる

Shadow DOMに続いて重要な仕様がCustom Elementsになりますが、これについても実装は順調なようです。

Appleは、Safari Technology Preview Release 13からコードが入り始め、Safari Technology Preview Release 14にて開発者向け実験機能をONにすれば利用可能な状態になりました。これも、数多くのiOSデバイス上でCustom Elementsを使ったウェブアプリケーションがネイティブサポートされる日も近いと言って良いでしょう。先ほどのShadow DOMと同じように、各ウェブブラウザ開発ベンダーの合意が取れているCustom Elements v1仕様がSafari Technology Preview Releaseに適用されています。

それに対して、残念ながらFirefoxではCustom Elements v1の開発に関するタスク登録はされていますが、具体的な作業は進んでいないようです（StatusがNEWのままであることからの推測⁠）⁠。“⁠dom.webcomponents.enabled⁠”というフラグをtrueにすることで以前のCustom Elements仕様の実装を使えるようにはなっているのですが、Custom Elements v1がFirefoxでネイティブサポートされるのは、もう少し待つ必要がありそうです。

Edgeは未着手

最も×マークが多くついていたEdgeですが、残念ながら実装される気配はまだありません。Microsoft Edge Platform Statusというウェブサイトがあるのですが、HTML Imports、Custom Elements、Shadow DOMのどれもUnder Consideration、つまり検討中のステータスです。EdgeでWeb Componentsがネイティブサポートされるのは、まだまだ時間がかかると言えるでしょう。

Platform Statusのページで掲載されている289個の機能の中で、投票順にソートすると、上位3つがまさにShadow DOM、Custom Elements、HTML Importsです。つまり、世間の要望はやはりWeb Componentsの環境がEdgeにおいても実現することであり、これはMicrosoftのEdge開発陣も把握していると思われます。当分はPolyfillに頼るしかなさそうですが、Edgeは比較的新しいウェブブラウザですので、今後の挑戦に期待したいところです。

2017年のWeb Components

では、今年のWeb Components関連の動きを考えてみます。

モバイルはもうすぐ準備が整う

デスクトップにおいてはFirefoxやEdgeのWeb Components対応が芳しくない状況です。しかし、StatCounterによるウェブブラウザシェアの統計によると、2016年11月ではFirefoxは13.49%、Edgeは2.94%でした。Chromeは59.06%と他を圧倒していて、実はデスクトップでは既にWeb Componentsの環境はほとんど既に整っていると言っても過言ではありません。

多くの人々がウェブアプリケーションをスマートフォンを代表とするモバイルデバイスから使っていますので、デスクトップよりもモバイルデバイスでのWeb Componentsの対応状況のほうが重要です。Androidにおいては、Android Browserは既にダウントレンドですので、Chromeはすべての準備が整っています。あとはiPhoneとなりますが、Safariの対応状況もAppleがGoogleの次にWeb Componentsに対してアクティブですし、実際Safariへの実装について目に見える進捗があります。

モバイルについても今年はWeb Componentsの環境が整う、と言い切っても良いでしょう。

フレームワークのWeb Components対応が進む

ウェブブラウザのWeb Componentsのネイティブサポート状況が好転していますので、Web Componentsを利用する側の対応も徐々に速度が加速していくと予想できます。

例えば、Angular 2においては、コンポーネントのスタイルとして既にShadow DOMを利用できるようになっています。具体的には、“⁠encapsulation: ViewEncapsulation.Native⁠”と定義することでShadow DOMが適用されるようになります。残念ながら2016年末時点では、Angular 2の初期値はShadow DOMを使わない指定となっていますが、今後Shadow DOMを有効にしてウェブアプリケーションを公開することは十分に現実的と言えるでしょう。

また、Reactにおいては、元々Web Componentsとの親和性が高い作りになっています。JSXを使って書かれたHTMLテンプレート内でCustom Elementsによって登録された部品を書けばそのまま利用できるようになっています。また、Reactコンポーネントの中でShadow DOMを利用可能にするReactShadowというライブラリもありますし、ReactコンポーネントをCustom Elementsを使って登録するアプローチも取ることができそうです。

今年は、各フレームワークがもっと踏み込んだWeb Components対応を打ち出してくるのではないかと考えられます。特にShadow DOMは、各フレームワークが長年課題にしてきた部品とスタイルの対応に関する問題を解決するための根本的な手法として機能するはずですので、積極的に対応が行われるのではないかと思っています。そして、時間が経過するにつれて、各フレームワークに関するドキュメントや解説記事の中で、Web Componentsという言葉を目にする機会も増えていくと予想できます。

ライブラリのWeb Components対応が進む

フレームワークだけでなく、UIの部品群を提供するライブラリを今まで開発してきた陣営が、Web Componentsに取り組み始めるのも今年からになるでしょう。Web Componentsとは、言わばウェブにおけるUI部品の標準仕様です。つまり、様々なUI部品を、その開発者が誰であれ、組み合わせて使うことができて、初めてWeb Componentsが想定しているエコシステムが回ります。そのエコシステムが今年から回り始めるのではないかと考えています。

現在、ウェブアプリケーションで利用可能なUI部品集は数多く提供されています。Dojo Toolkit、Bootstrap、Kendo UI、Ext JS、Webixといったものが有名です。これらがまずは内部的にWeb Componentsの各仕様を取り込んでいき、様々な問題を解決していくことになるでしょう。おそらく、Shadow DOMやTemplatesをまずは内部的に利用していくことになると思います。

その後、Custom Elementsによって、上記のライブラリに含まれる個々のUI部品群がWeb Componentsとして登録されるようになれば、ウェブアプリケーションの世界が大きく変わります。現状、上記のラブラリを一つのウェブアプリケーション内で複数組み合わせて利用することは、現実的ではありません。しかし、Web Components化されることで、異なるライブラリに含まれるUI部品を組み合わせて利用できるようになります。少なくとも、部品間での干渉による不具合の発生はなくなるでしょう。そして、主要なライブラリがWeb Components化されることによって、ウェブアプリケーション市場にUI部品が一気に流れ込むことになりますので、Web Componentsの利用も活性化されるはずです。

実際には今年中に上記の作業をやり終えることは難しいかもしれませんが、Web Componentsの普及は、上記のような既存のライブラリがどのようにWeb Componentsのエコシステムに対応してくるかが勝負だと思います。この動向に注目しておくと良いでしょう。

フロントエンドエンジニアの出番が来る

多くのフロントエンジニアにとって、Web Componentsは「まだ遠い未来の話であって、それは来ないかもしれない未来」だと思っていた方が多いはずです。しかし、Web Componentsの主要ウェブブラウザの対応状況はかなり進んでいて、実は既に環境はほぼ整っていると言えるところまで来ていることがわかっていただけたかと思います。デスクトップおよびモバイルでのウェブブラウザのシェアの状況を見ても、そう言えるでしょう。

今年からは、何かウェブアプリケーションを開発する際に、Web Componentsの採用を考えても良いでしょう。まずは身近の開発プロジェクトから、徐々に小さく部分的に適用していき、Web Componentsの利点を体感することから始めてみましょう。そして、フレームワークやライブラリについてWeb Components対応が進んできたところで、本格的に様々なウェブアプリケーションにて適用していく、という段階を踏むと、失敗することなく利点を活かしていけると思います。

今年からは、Web Componentsがアクティブになるレイヤは、ウェブブラウザ開発ベンダーではなく、フレームワークやライブラリの開発者であり、そしてそれらを利用する多くのフロントエンジニアになります。Web Componentsがウェブアプリケーションの主役になる日は近いです。ぜひ今年はWeb Componentsをキャッチアップし、実際に手を動かしてみてください。