2015/01/16更新

[フロントエンド] The Extensible Webという考え方

こんにちは、@yoheiMuneです。
みなさま、The Extensible Webという考え方をご存知でしょうか？昨年末にJxckさんのブログでも紹介がありましたが、この考え方いいなぁと思ったのでブログで紹介させていただきたいと思います。

Special Thanks to https://flic.kr/p/9yC634

The Extensible Webとは

The Extensible Web Manifestoで表明されているWeb標準化のやり方に関する提言です。一言で言えば「低レベルなAPIを定義しようよ」ということです。なぜこのような考え方が出てきたのでしょうか。

The Extensible Webが生まれた理由

この考え方が生まれた理由は上記のサイトにも記載されていますが、次の通りです。

（個人的な解釈を含みます）
近年の仕様策定では、数ヶ月や数年の月日を要しています。仕様策定では、まずブラウザベンダーによる注意深い実装からフィードバックを受け、その後ようやく実際の利用者からフィードバックを受ける形となっており、十分なイテレーションを行うことがなかなか大変です。例えば、HTML5 App Cacheは長い仕様策定の間にどんどんとユースケースが変化し、時代の進化についていけていません。

引用:https://extensiblewebmanifesto.org/

Webにおける多くの仕様は高レベルであり、様々なユースケース（=使われ方）を考慮されて仕様が策定されている。多くのことを考慮するため、複雑で、仕様策定に時間がかかってしまい、時代の進化についていけていないという問題があるようです。そのため、The Extensible Web Manifestoという考え方が出てきたようです。

それでは具体的に、どのような内容なのでしょうか。

The Extensible Webの中身

（この章にはThe Extensible Webの簡易翻訳が含まれます。誤訳がありましたら教えて下さい）

The Extensible Web Manifestoは、次の4つの原則で構成されます。

低レベルな機能をWebプラットフォームに追加することに集中しよう。もちろんそれら機能はセキュアで有益であること
既存の機能を説明できるような低レベルな機能を公開しよう。例えばHTMLやCSSを表現できる機能を提供し、開発者が利用できるようにする
高レベルな機能の開発、表現、テストはJavaScriptを用いて表現しよう。そうすれば、標準化される前でも継続的な開発を行う事ができる。これにより標準化と開発者の間に良きサイクルを生み出すことができる
これらのことを優先し、それ以外は後回しにしよう

そして各原則はそれぞれ以下のように説明されています。

1. 低レベルな機能の標準化によって、

新たなセキュリティサーフェスが含まれる
APIを安定化するためのブラウザベンダーにおける最適化を許容しよう。これにより少ない実装コストでより良いパフォーマンスにつなげることができる
ブラウザベンダーやライブラリ開発者が、高レベルAPIを継続的に開発することが可能になる

2. 低レベルAPIを用いて既存の/新しい機能を定義する

複雑になることを防ぎ、その結果として実装バグも減らすことができる
新しい機能のポリフィルを定義することができる
新しい機能に対する学習コストを下げることができ、学ぶとしても既に存在するコンセプトで学ぶ事ができる

3. 理解しやすい新機能やポリフィルを作ることで好循環が生まれる

開発者はより早い段階でAPIを定義することができ、その結果をより早くプラットフォームにフィードバックすることができる。例えそれが検討中の仕様であっても
APIに問題点が潜んでいたとしても、APIを利用する開発者やライブラリ制作者によって、早い段階でブラウザベンダーやプラットフォームへフィードバックされ、すぐにその問題点を修正することができる
ライブラリ制作者は新しいAPIを試すことができ、またその結果として未整備な状況をどんどん整備することができる

4. これらの原則を優先することで、

今の標準化のプロセスに存在するしがらみを解き放ち、セキュリティとパフォーマンスを兼ね備えた機能に集中することができる。またプラットフォームレベルで少しだけ追加すれば事足りるような機能にも集中することができる
開発者やブラウザベンダーは、より意欲的に開発を行うことができる
すでに長期間の仕様策定が行われ、またはすでにいくつかの実装が現実に利用されている機能についても、標準化プロセスを簡素化し合理化することができる。

セキュアでパフォーマンスの考慮された低レベルなAPIの仕様策定を優先する、これがThe Extensible Web Manifestoの考え方のようです。

Web ComponentsやService Worker

The Extensible Webの考え方は、すでにいくつかの仕様策定に取り入れられています。その代表的な例としてWeb ComponentsやService Workerが存在します。

Web Componentsの場合

Web Componentsを使えば、Web上にコンポーネントという概念を持ち込むことができます。そして例えば自分のユースケースに合わせた独自タグ（そしてそのタグは他に影響を与えない、他から影響を受けない）を定義して、利用することができます。これらのことを実現するためにWeb Componentsは3つの仕様で構成されています（参考:Web Components wiki）。

Custom Elements: <core-header/>などの独自タグを定義するための仕様です
Shadow DOM: カプセル化した（=スコープを持つ）DOMを定義するための仕様です
HTML Imports: 外部ファイル化されたHTMLを読み込む仕様です

上記3つの仕様を纏めて1つの仕様とするよりも、役割分担を分けてそれぞれを仕様策定することで、低レベルなAPIが提供されています。

そしてこれらの低レベルAPIをそのまま用いるのも良いですが、このままだと使いづらいぞという人向けに、PolymerやX-Tagといった高レベルなAPIが提供されていてりします。

Service Workerの場合

Service Workerは、次世代オフライン機能として注目を集めています。Service Workerもいくつかの仕様に分けることができ、Cache APIやFetch APIなどが存在します。

この考え方をお手軽に応援できる

The Extensible Webという考え方は、JavaScript生みの親であるBrendan Eich、Ember.js開発者のYehuda Katz、、Service Workerの中心人物であるAlex Russell、FetchやCacheなど様々な仕様策定を進めているAnne van Kesterenなど、すごい人たちが書いています。

そしてThe Extensible Web Manifestoのページでは、Google Formsを使って賛同の意思表明を行う事ができます。この考え方いいなと思った方は覗いてみてください。自分は賛同してみました。

仕様策定には誰でも参加できる

（この章は今年の私に向けて書いてます）

仕様策定は、誰でも自由に参加して、意見を述べる場があります。ECMAScriptであればコミュニティに参加してTC39（=仕様策定するグループ）にフィードバックを送ることができます。またService Workerであればthe Web Applications Working Groupへ参加して不具合を報告したりできます。
こういう場での議論を理解できるようになりたいし、将来は何かしら自分も貢献したいと思う今日この頃です。

最後に

今日はThe Extensible Web Manifestoを紹介しました。今後のWebで低レベルAPIがどんどん出てくると楽しいですよね！たくさんのAPIを組み合わせて、いろいろと楽しんでみたいです。

本ブログでは、フロントエンドに関する情報を中心に発信していきます。気になった方はぜひ、本ブログのRSSやTwitterをフォローして頂けると幸いです ^ ^。

最後までご覧頂きましてありがとうございました！