あけましておめでとうございます。よういちろうです。多くの人が様々なデバイスからウェブにアクセスすることが当たり前となりましたが，ウェブをさらに進化させるために，現在も数多くの試みが行われています。その中で，本稿では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にとって本当に嬉しい年となりました。