読者の皆様は、「Extensible Web」というキーワードについてご存知でしょうか。
Extensible Webは、現在のWebが抱える大きな問題点を解決しようとする考え方であり、ムーブメントです。 その問題点とは、誤解を恐れず言うなら、「HTML5の流れで生み出された様々なAPIが実際にはあまり使われておらず、役に立っていない」という点に尽きると思います。
Extensible Webはそうした問題を解決するために、「開発者によって拡張可能なWebを目指そう」と呼びかけます。そのために必要なのは、特定のユースケースを想定した粒度の粗いAPIではなく、粒度が細かく、より基本的な機能を提供する低レベルなAPIを提供することで、開発者が様々なライブラリを作りやすくすることです。詳しくはこちらの記事も参考にしてください。
Extensible Webは、「Extensible Web Manifesto」というマニフェストが公開されてから広く世に知られるようになりました。Extensible Web Manifestoの文書がGitHub上で公開されたのが2013年6月9日ですので、既に2年以上が経過していることになります。本対談では、Extensible Webが誕生してから2年で何が変わったのか、そしてこれからWebはどうなっていくのかを、有識者の方々にそれぞれの立場から語っていただこうという発想で企画しました。
標準化団体のスタッフがどんな目線でWebを見ているのか、ブラウザベンダが開発者に求めているものは何か、Web標準にも詳しいエキスパートが現在のWebをどう捉えているかなど、普段聞けない話がいっぱいです！前後編でお届けしますので、どうかお楽しみくださいませ。
ちなみに、前編は全体的に、HTML5や関連（あまり知られていないかもしれない）APIを広範にdisる批評するという流れになってしまったので、ちょっとマニアックかもしれません…あしからず。
自己紹介
白石 皆さん、本日はお集まりいただき、ありがとうございます。非常に豪華なメンバーにお集まりいただき、誠に光栄です。今日は脱線大歓迎というノリで、自由闊達にExtensible Web、そしてWeb全体について語っていただきたいと思います。ではまずは、自己紹介からお願いできますでしょうか。
小松 小松と申します。通信会社（NTTコミュニケーションズ）でWebに関する研究開発をしておりまして、最近ではWebRTCやIoT/WoTに関する開発、標準化活動をやっています。
浅井 Mozilla Japanの浅井です。最近はエヴァンジェリストとしてWeb技術に関して開発者の皆さんの前でお話したり、モバイル＆エコシステムマネージャーとして、パートナーさんとの協業を促進しています。Fx0というスマートフォンの開発や、FirefoxOSを搭載したビエラの開発をお手伝いしたりなど、パートナーさんと「Webを使ったものづくり」を広げていく仕事をしています。
白石 ビエラって、FirefoxOS積んでるんですか。知らなかった…。
斉藤 株式会社リッチメディアで、主にメディア事業に携わりながら、対外的にはUXエンジニアとして活動しています。ここにいる皆さんは、標準化に近いところで働いていらっしゃる方が多いと思いますが、僕は一番現場に近いところで実装寄りの仕事をしているんじゃないかな。
ダニエル W3Cのダニエル・デイビスと申します。半分はTV・ビデオ関係の仕事を、もう半分はマーケティングやコミュニケーション、特に開発者向けに標準をどう伝えていくかといったことを担当しています。特に最近注目しているのはセキュリティです。今セキュリティに関する仕様書がたくさん増えているので、そうした情報を開発者に伝えるにはどうしたらいいかを考えています。
Extensible Web以前 – Application Cacheの失敗
白石 では、Extensible Webが出てもう2年が過ぎたわけですが、そもそもExtensible Web以前は何が問題だったのでしょうか？例えば、標準化の失敗例としては Application Cache (※) がよく引き合いに出されますね。AppCacheの何がいけなかったのでしょう？
小松 使えるシーンが限られていたのが一番の問題じゃないかと思います。数ページ程度の静的なWebサイトならいいんだけど、ページ数が増えたり、ちょっと複雑になるととたんに使えなくなっちゃう。あと、キャッシュのバージョン管理が面倒臭かったですね。
斉藤 アプリケーションキャッシュのファイルのバージョンを書き換えるGruntタスク、なんてのもあったりしますが、「勘弁してくれよ」って感じですね(笑) キャッシュが更新されるタイミングもブラウザによってまちまちですし。
白石 実務だと、キャッシュの最大容量とかもよく問題になりましたね。巨大な動画ファイルとかはキャッシュされなかったり、キャッシュの最大容量を知ろうと思っても知る手段すらない、とか。
ダニエル 「オフラインの場合はキャッシュを、オンラインの場合はWeb上にある最新のリソースを使う」といったユースケースにも対応できていませんでしたね。
斉藤 仕様としても、結構珍しいかなと思いますね。長くWeb屋をやっていますが、1ファイル（マニフェストファイル）だけ用意すれば、あとはブラウザがうまくやってくれる…という仕様は他に見たことがありません。
JavaScriptのAPIは、だいたいにおいてPolyfill (※)を用意できるように作られていて、レガシーなブラウザの上でも動作をエミュレートできるようにしてあるものが多い。でもアプリケーションキャッシュの場合は、使うか使わないかの「ゼロイチ」を要求される。APIではなく、いきなりプラットフォームを作りにいったという感じがありますね。
白石 僕、Google Gears（※）っていう技術の本を書いたことがあって、そういうのだけよく知ってるんですが、Gearsの仕様を参考に作られたからこんなことになったんだと思ってます…どうでもいい話ですが。。
※ Application Cache…Webサイトをオフラインでも利用できるようにする仕組み。マニフェストファイルというファイルを一枚用意するだけで、キャッシュの管理はすべてブラウザが行ってくれるというのがウリの一つ。
※ Polyfill…新しいAPIをJavaScriptで実装し、非対応ブラウザでもそのAPIを使えるようにするもの。有名なところでは、Web Componentsを古いブラウザでも利用可能にする「Polymer」などがある。
※ Google Gears…Googleが昔開発していた、オフラインWebアプリを実現するブラウザプラグイン技術。Application CacheやWebSQL Database、Web Workersなど、HTML5関連APIの仕様策定に参照され、HTML5がメジャーになると開発が終了された。
Webはアプリケーションプラットフォームになった
白石 他に、問題だったAPIとかありますか？
小松 よく言われるのは contentEditable (※)ですね。
浅井 ああ…死んでましたね。実装する側が(笑) 。「誰だ、こんな、実際には誰も使わないAPI作ったの」って開発者が文句言ってました(笑)。
白石 確かそれって、IEかなんかで実装されていたのを仕様に起こしたって感じじゃありませんでしたっけ。
浅井 そうかもしれませんね。「Webはみんなで作るもの」ってなる前の時代に作られた仕様という気がします。
斉藤 ちょっと全般的な話になってしまうのですが、かつて単なる「ドキュメントレンダラー」だったWebブラウザが、HTML5のブームの中で、アプリケーションのランタイムへと変化していったという流れがあると思うんですよね。
白石 かつてはHTML5の仕様書の先頭の方にも、「アプリケーションプラットフォームを目指します」と書いてありましたしね。
ダニエル それは今も変わっていませんね。W3CとしてはWebのことをオープン・ウェブ・プラットフォームと呼び表しつつ、プラットフォームがあまりに広くなりすぎているので、Application Foundation（アプリケーション基盤）として8つのカテゴリに集中するという動きをしています。
浅井 ブラウザベンダ側からすると、JavaScriptを生み出した時点で「僕らはアプリケーションプラットフォームです」と言い続けていたんですよ。機能不足で、そうは見えなかったんでしょうが…ただ、それを目指していたというのはNetscapeの時代からありました（若い人向けの注: Netscape NavigatorというブラウザがFirefoxの前身）。
NetscapeがJavaScriptを動的な、拡張可能な言語として設計した時点から、Webはずっと拡張可能なプラットフォームです。なので、Extensible Webというキーワードには、（Webは拡張可能であるという）ブラウザベンダの思いを、Web開発者に伝わりやすいように言い直したという一面があるんじゃないかな、と思っています。
※ contentEditable…任意の要素を、ユーザが編集可能な領域にすることのできる属性。<div contentEditable>とするだけで、簡単なWYSIWYGエディタを作成可能
disってない。disってないですよ
白石 イマイチという評価のAPIとしては、他にもそういえばWeb Storage（※）もありますね。同期型のAPIなので、ループの中とかで使っちゃうとUIスレッドがビジーになっちゃって、UIがもたついちゃったりフリーズしちゃったり、という。
小松 僕は割と好きなんですけどね。
斉藤 ハードに使っちゃダメなんですよ。ちょっとした優しさのために使うべき(笑) 。例えばフォームの入力内容を入れておいて、ネットワークが切れた時でも失われないようにするとか、その程度。
ダニエル 問題のあるAPIというと、<input type="date">とかもそう。昔私はOperaにいたんですが、そこらへん（inputの様々なtype）をいち早く実装したのが自慢でした。でも開発者からのフィードバックとしては褒められるどころか、「（<input type="date">使った時に）自動的に表示されるカレンダーのデザイン変えさせろ」でした(笑)。
斉藤 Operaかわいそう(笑)。
浅井 HTML5の発端（の一つ）だったのにね(笑) 。※
斉藤 僕は結局使ったことないですね(笑) 。デザインが合わないと、結局使いものにならないので。フォーム関係の仕様で言えば、required属性とか、<input type="email">とか<input type="number">とかはすごく助かりますよね。
小松 モバイルで、タイプに合わせた最適なキーボードが出てきてくれるのが嬉しいですよね。
白石 ほかには、存在はするけどあんまり使われてない、ってAPIも多そうですよね。例えばWeb Workers（※）とか。Shared Worker（※)なんてのもあったなあ…。
浅井 いや、（Mozillaは）使ってますよ！
白石 いやまあ、一般のWeb技術者が使っているかというと、あんまり…という気がしますよね。他には…えーと…名前が出てこない。EventSourceとかいうAPI使うやつ。
小松 Server Sent Events（※）だ。
一同: ああーー
小松 テキストしか扱えないし、サーバプッシュの用途だったら、他にWebSocketがあるから。HTTPサーバで事足りるっていうのはいいんですけどね。
ダニエル WebSocketを使えないホスティングサービスの上で、「しょうがないから」Server Sent Events使ったということはありましたね(笑)。
白石 まあ、こういう風に、「あるけど使われてない」とか「あるけどイケてない」という仕様がいっぱいあって。
ダニエル 他にももう一つ思い出しました。Network Service Discovery API（※）。W3Cスタッフとして言っていいかどうかわからないけど、あれはセキュリティの問題もあって、ちょっと残念な感じでした(笑)。
白石 でもこの対談、HTML5のAPIをdisる流れになってて、こんなの初めてで面白いなあ(笑)。
浅井 disるように誘導してません？(笑)。
白石 いや、そんなつもりは…(汗) 。
※ Web Storage…シンプルなローカルストレージAPI。localStorage.setItem('key', 'value')とするだけで、ローカルのストレージに値を保存できる。
※ WHATWGの取り組みの初期に、「Web Forms 2.0」という仕様が提案されていた。
※ Web Workers, Shared Workers…Webブラウザ上でマルチスレッドプログラミングを可能にするAPI。
※ Server Sent Events…サーバプッシュを可能にするAPI。WebSocketとは異なり、HTTPサーバさえあれば動作する。
※ Network Service Discovery API…ネットワーク上のサービスを動的に発見するためのAPI。ホームネットワーク上で、デバイスを発見する用途に利用できるとされていた。
プレフィックスの反省を活かす
白石 あと、Extensible Webの情報漁ってた時に「Indexed Database API（※）は、開発者のフィードバックを受けながら作った素晴らしいAPI」と書いてあったんですが、正直同意できない(笑) 。かなり使いにくいAPIだと思うんだけど…。
浅井 えーと、いや、それは、申し訳ない。だいぶうちら（Mozilla）が推進しちゃって(笑)。
小松 一番最初に実装してなかったけ？
浅井 してました(笑)。 （それ以前に提案されていた）WebSQL Database（※）なんて、標準化されていないSQLiteの仕様に依存してて全然ダメだ、と。
白石 いや、その主張は同意できたんですけど、できあがってみたIndexed Database APIの仕様がこれかーー、と(笑)。
浅井 いやでもまあ、Extensibleではあるじゃないですか。プリミティブで、パフォーマンスも上げられるAPIは一応揃っていて。APIの使い勝手については、申し訳ない、ライブラリ使ってくださいと。MDN (Mozilla Developer Network) に掲載されているIndexed Database APIの解説でも、「localForageかdexie.jsを使ってください。そっちのほうが『More user friendlyだから』と」と書いてあります(笑)。
ダニエル 素で使うのが厳しいという意味では、WebGL（※）とかもそうですよね。ラッパーライブラリがないとコーディングは厳しいけど、プリミティブでパフォーマンスの高いAPIを提供している。
浅井 そういう点から言うと、Extensible Webの考え方があと数年早かったら、Web Audio API（※）じゃなくて、Mozillaが作っていたAudio Data APIだったんじゃないかな、と思いますね。プリミティブなAPIを提供して、ライブラリはJavaScriptで作ればいいじゃん、と、そういう発想で作られていたAPIだったんです。
小松 さっき話に上がってたWebSQL Databaseは、実はまだ結構使われてたりする。
浅井 ああ、結構ありますね。たまにユーザから「動きません」ってフィードバックもらって、見てみるとWebSQL Databaseのせいだったりする。WebKitがWebSQLを実装したあたりで、急にみんなが新しいWebの機能を使い出して、そのままになってるサイトが多いんですよね。
白石 それは、-webkit-プレフィックスに依存したサイトが未だに大量にある、って問題とも繋がってますよね。
浅井 そうなんですよ… プレフィックス付けてる間に開発者からの意見を取り入れていこう、というシナリオをブラウザベンダは考えていたのですが、開発者たちは便利なものがあれば使ってしまう。我々（ブラウザベンダ）が考えていたようには、うまくいきませんでした。かと言って、ブラウザベンダ自らがライブラリを作って提案したりしても、使われるのは最初だけで、すぐ使われなくなったりしてしまう。だから、ライブラリを作りやすくして開発者の意見を取り込みやすくしていこうというのがExtensible Webの目標の一つです。プレフィックスの失敗も、反省の一つだと思うんですよね。
※ Indexed Database API…ブラウザ上で利用できるキー・バリュー・ストレージ。Web Storageに比べると複雑だが高機能。
※ Web SQL Database…ブラウザ上で利用できるリレーショナル・データベース。SQLiteというデータベース実装の使用を前提としていたことが標準仕様としては不適格という理由で、今は非推奨に。
※ WebGL…ブラウザ上で利用できる3Dグラフィック用API。
※ Web Audio API…ブラウザ上で利用できる音声操作API。
※ Audio Data API…音声操作のAPIとして、Mozillaが仕様策定と実装を進めていたが、標準化の過程でWeb Audio APIに一本化された。
Extensible Webの起源はjQueryにあり？
小松 あと、Extensible Web以前という話で言うと、4年前にサンタクララで行われたTPAC（※）のブレークアウトセッションの中で、「開発者とW3Cがうまく関わっていくにはどうしたらいいか」という議論をしたのを覚えています。そこで、開発者が中心になってWebを伸ばしていくという話で、jQueryの例が取り上げられていました。
で、（DOM操作に）セレクタを使用するというのがWeb開発者に受け入れられるというのが判明したので、パフォーマンスの問題を解決するために、ネイティブでquerySelector API（※）が実装されたと。ここではフィードバックループがうまく働いたので、こういう例をどんどん増やしていこうという話がありまして、こういう流れがExtensible Webに繋がったのかなあ、と思います。
ダニエル jQueryの話が出たところで、一ついいですか？Extensible Webとは全然関係ないんだけど。
白石 なんですか？
ダニエル …小松さん、John Resig（※）に似てない？
斉藤 ああー、ググって出てきた写真で見ると、ちょうど黄色のやつに似てる。黄色いJohn Resig。
一同: (爆笑)
ダニエル すいません、脱線しまして…。
白石 いえいえ、最初にお伝えしたように、脱線大歓迎です。この、「黄色いJohn Resig」の話も、記事に含めさせていただきます(笑)。
ではここらで一旦まとめますと、まずjQueryをきっかけとしてquerySelector APIが出てきたといった流れがあり、これは実際に役立つAPIとして世界中で利用されているし、jQuery、もしくは類似ライブラリのパフォーマンス向上にも一役買っている。
一方で、Webプラットフォームには今やたくさんAPIがあるけど、使われていないものや、イケてないものもたくさんあると。こうした問題を解決する一つの糸口として、querySelector APIが生み出された経緯をヒントにしつつ、現在のExtensible Webというムーブメントに繋がっている…という流れでしょうか。
（以後、後編に続く）
※ TPAC…W3Cが主催する、Web標準技術に関するカンファレンス。
※ querySelector API…今すぐ開発者ツールのコンソールを開いて、document.querySelector('任意のセレクタ')を実行してみるべし。
※ John Resig…jQueryを作った人。