後編である今回は、Extensible Webの現在、そしてWeb技術の未来にフォーカスしたお話になります。Extensible Webの概要や、Extensible Web以前からあるWebの問題点について知りたい方は、前編をご覧ください。

HTML5は（ついに）モジュール化される

白石 では、Extensible Webの考え方が提唱されてから2年が過ぎたわけですが、どのような変化が起きつつありますか？まずは皆さん、思いついたものから教えていただけると嬉しいです。

ダニエル 最近の話で言うと、HTML5の仕様がモジュール化されます。例えばTimed Media Working Groupというワーキンググループが提案されていますが、もともとはHTML5の一部でした。このように、専門的なグループに分かれて仕様策定が進められるようになろうとしています。

白石 Extensible Webは、標準化の話とも密接に関わっているかと思うので、詳しく教えて下さい。HTML5.1がバラバラになっていくということでしょうか？

ダニエル そうです。まだ詳細は決まっていませんが、今後仕様書も分割されていきます。ちょうど、CSSがバージョン3になって、多数の仕様書に分割されて、それぞれメンテナンスされるようになったのと似た感じになるでしょう。

また、ワーキンググループが分かれていくというだけではなく、もっと開発者が参加しやすくなります。その一つが、Web Incubator Community Groupの作成です。これができたのもつい最近（2015/7/2）ですね。ここは仕様を提案する場というよりは、質問してアドバイスを受けたり、デモを投稿したりと、一般の開発者のサポートが中心になります。

斉藤 これは素晴らしいですね。最近すごく思うのは、仕様書がGitHubに置かれるようになって、別にGitHubが大好きというわけでもないんですが、開発者に見られるサイトNo.1ということで、変更の履歴すらも簡単に見られるようになり、どういう経緯で仕様が変更されていったかが追えるようになったのは素晴らしいと思います。

ダニエル 10月のTPACまでに細かい作業を終えて、TPAC以降にフィードバックをもらいながら改善していくという感じだと思います。

APIの低レベルさはどこまで許容される？

浅井 最近はExtensible Webの流れを受けて、低レベルなAPIを提供して開発者に使ってもらおう、ということを意識するようになりました。例えば最近、センサー類のAPIを作ろうとしているのですが、大きく２つの方向性があるという議論になったんですよ。

一つは光センサーとか、既存のセンサーを抽象化するようなもの。またそれと合わせて、組み込み向けの通信制御のAPIを提供してはどうかというものでした。こちらはまあ、普通ですね。

でももう一つはぶっ飛んでて、Low Level File System APIっていうのを作ってしまってはどうか、と。 UNIXって、/dev 以下のファイルを通じてデバイスにアクセスできるじゃないですか。だったら、ファイルにアクセスできる手段を一つ開発者に与えてあげるだけで、どんなデバイスでも操作できるようになるじゃないか、と。本当に低レベルなものを作りさえすれば、開発者が必要なものを作れるよという考え方です。

でもこれは完全にぶっ飛んでる。だってプラットフォームに思い切り依存するじゃないですか。やり過ぎ感はすごくあるけど(笑)、それをマジメに議論できるようになったというのが、Extensible Webから来る発想なんじゃないかな、という気がします。僕としては、ちょっと低レベルすぎるんじゃないかと思いますが。

白石 そのうち、システムコールとか叩けるAPIが出てきそうですね。

浅井 あまりAPIが低レベル過ぎても、今度は（JavaScriptライブラリによる）パフォーマンスのロスが大きすぎるし、OS依存のAPIを露出するのはよくないという考え方もあるので、どこまで低レベルにいくべきかというのは、今Extensible Webの中で本当に議論していかなくてはならないんじゃないか、という気がします。

「Extensible」なAPIたち

白石 なるほど。ではここでちょっと話を変えて、実際にExtensible Webに関連するAPIといえば何があるんでしょう？まずFetch（※）とか。あと、ServiceWorker（※）もでしょうか。

斉藤 Promise（※）とかもそうだと言っていいんじゃないでしょうか。Promiseの原型になったAPI（Deferとか）は、Extensible Webの提唱以前からありますが。

小松 他には、Object.observe（※）とかもありますね。

浅井 Web Components（※）もそうでしょうね。

ダニエル Web Componentsは便利ですよね。Polymer 1.0が出た時に使ってみましたが、とてもよかった。でも、Polymer自体がものすごく巨大なので、便利さの代償も大きいな、と(笑)。

浅井 Web Components、小規模なプロジェクトならいいですが、大規模で長期的なプロジェクトとかでは、まだあまり使われてないんじゃないでしょうか。 そういう点では、Mozillaはむしろ積極的に使っています。しかも、Firefox OS本体で。本当に大事なAPIは、誰かがガチで使わないと熟成されないので、我々は必ず本番プロジェクトにガンガン入れるんです。

Firefox OS 2.5とかになると、Web ComponentsだけじゃなくてServiceWorkerとかも思い切り使って、アプリケーションのアーキテクチャを大幅に変更しようとしてます。どこよりもServiceWorkerを思い切り使って、悪いところを見つけ出そう、くらいの勢いですね。 ただ、ServiceWorkerをフルに使用して、複雑なキャッシュ処理とかを行うコードを見ていると、これはもう一般のWeb開発者が気軽に触れるレベルじゃないな、と思います。WebGLを生で扱うコードとかもそうですけど。

小松 WebRTCなんかについても、「一般のWeb開発者にとっては、使うのが難しい」という話はよく聞きます。でもWebRTCは、低レベルすぎるという意見もあれば、あれでもまだAPIのレベルが高過ぎるという意見もあって。

もともとはビデオチャットをユースケースとしてAPIを作っていたんだけど、実際にやってみると双方向のビデオチャットだけじゃなくて、例えば監視カメラみたいに「一方向だけ」というユースケースも重要だったりとか、多人数会議とかやるときは映像のネゴシエーションとかもっと柔軟にやりたい、という話が出てくると、実は今のWebRTCでも高レベルすぎると。その議論が、今のORTCに繋がったりしているわけです。しかし、APIのレベルを低くすればするほど、柔軟性は向上するんだけど取り扱いは難しくなって、一般の開発者が触るには難しいものになっていくだろうな…とは感じています。

白石 なるほど…WebRTCみたいな、高度なネットワーク処理を伴うAPIについては、TCP/UDPのソケットを直接触れるような低レベルAPIがあればよさそうですよね。Socket APIとかは既にあるんでしたっけ？

浅井 ありますよ。Firefox OSではよく使われています。

白石 ああそうか、Firefox OSやChrome OSだと、かなり低レベルなJavaScript APIが既に実装されてますよね。Bluetoothとか、シリアル通信とかも可能だったような。

ダニエル BluetoothのAPIは使ってみたんですけど、やっぱりChromeブラウザじゃなくてChrome OSでしか使えないんですよね。ブラウザで（通常のWebアプリで）使いたいとは感じましたが、それは叶っていません。「危険だ」と。

小松 APIのレイヤーを下げていくことと、セキュリティやプライバシーはトレードオフがありますよね。

※ Fetch…ブラウザがHTTPを使用してリソースを取得する操作をAPIとして利用できるようにしたもの。XMLHttpRequestに近いが、よりAPIが洗練されている

※ Web Components…カスタム要素を利用できるようにできるAPI

低レベルAPIとセキュリティ・プライバシー

ダニエル 今お話に上がったように、「低レベルなAPIは危ない」という問題もある。皆さんここはどう考えますか？

白石 僕が今回の対談を準備するにあたって、いろいろ情報を集めた中では、「そういうセキュリティやプライバシーの部分こそ、標準化のリソースを費やすべき点だ」という意見がありました。ひとりのエンジニアが、自分の力だけでセキュリティやプライバシーを完璧に実装することは不可能なので、標準化というプロセスを踏んで様々な知見を集約することで、そういったAPIの安全性を担保するという。

浅井 ただ今の時代、APIだけでセキュリティを担保するのは難しくて、結局はアプリケーションのエコシステム全体でサポートしていかなくちゃいけないんですよね。例えばWebを全てHTTPS化するとか、アプリケーションマーケットでセキュリティレビューが行われるから安全になるとか、ほかの仕組みと組み合わせることで安全性を担保するという形になってきている。

まあ、一方で、そういう他の仕組みで担保してもらえるからエンジニア自身はあまりセキュリティのことを考えなくなっている…というのもあると感じています。もし低レベルのAPIが使えるようになるなら、実際躊躇なく開発者は使うわけですよ。Firefox OSでもふんだんに使われています。セキュリティレビュー前提でね。でも、そのセキュリティレビューが、どのエコシステムでも行われるわけではない。もしそういうAPIが、（セキュリティレビューのない）一般のWebコンテンツでも使えるようになったらまずいんです。

エコシステム全体で安全性を保っているのに、エコシステム抜きでAPIだけ持ってきて使えるようにしてしまうと、安全でなくなってしまう。そこをどうやって担保していけばいいのかな、というのはすごく難しく感じています。

白石 HTTPSが前提だったり、Firefox OSみたいな環境の上でサンドボックス化されたアプリケーションであることが前提だったりとか、APIを取り囲む様々なコンテキストだったり環境を含めてこそセキュリティが担保されるのであって、APIだけ切り出して安全性を担保するというのは難しいということですね。

斉藤 なるほど… 正直、「ServiceWorkerがHTTPSのみになりました」と聞いた時「なんだとコノヤロウ」と思ったくらいなんですが(笑)。よくよく考えてみると「そうだよね」と納得は出来るんですが、一方で「誰がそのSSL証明書代払うねん」という感じでもあります(笑)。

浅井 MozillaはHTTPSの無料化を推進しようとしていますけどね。

白石 そうですよね、頑張ってくださいよMozillaさん！世界中がMozillaに期待してます(笑)！

でも、ServiceWorkerはHTTPSオンリーです、というのは少し乱暴な感じも受けるのですが。今後、Extensible Webの思想に則ったAPIがどんどん現れるとして、「とりあえず危ないかもしれないからHTTPS限定にしておこう」という感じになっちゃわないんでしょうか？

斉藤 まあ、流れとしてはWebは全部HTTPSにしていこうという感じですしねえ…

小松 そうそう。iOS9のWebViewは、デフォルトではHTTPS接続しかできなくなるしね。

ダニエル 標準化のほうでも、実際そういう流れはあります。「Secure Contexts」というドキュメントがあって、「こういう場合はHTTPS接続が必要」というシチュエーションを列挙しています。 これによると、センシティブなデータやセンサーデータにアクセスするAPIは全て対象となっていますので、（今まで非HTTPS環境でも利用できていた）Geolocation APIなども、将来的にはHTTPS限定になるかもしれません。

世界は、開発者からのフィードバックを求めている

白石 ここまでは、Extensible Webを中心として、Webの過去や現在についてお話いただきました。では、未来のWeb技術はどうなるんでしょう？

ダニエル 簡単に言うと、低レベルなAPIが増えて、高レベルなライブラリが増える、ってことじゃないかと思います。

斉藤 一般の開発者や企業もライブラリを作るようになり、もっと言えば、それで利益を上げる企業が出てきてもいいと思います。今はWebのプラットフォームやライブラリを作っているのって、結局ブラウザベンダ周辺の方々ばかりです。もしそこで利益を上げられる仕組みが出てきたとしたら、もっと一般の企業や開発者がWebのプラットフォームづくりに貢献できるようになるんじゃないかと。今は、あまり貢献できる余地がない。

浅井 （Webプラットフォームへの）貢献という点では、ブラウザベンダの立場から言うと、一番求めているのって開発者からのフィードバックなんですよね。Webブラウザのエンジニアは、フィードバックが欲しくてしかたがないんですよ。自分たちが仕様を書いても、他の人が作って使ってくれないと標準化できないんですから。そこを、どんな方法でもいいから解決したくって、だからこそこんな考え方（Extensible Web）になったという流れもあると思います。

白石 そうですよねえ…前編でいくつか挙がっていた「使われていないAPI」なんて、ほんとに使われてなさそうなので、フィードバックも何もあったもんじゃないですよね。

浅井 そうなんです。少なくとも僕らは、W3Cにインパクトを与えるためにもどんどん開発者は意見をあげていってほしいと思っていますし、ダニエルさんが紹介していたWeb Platform Incubator Groupにも参加してほしいと思っています。Mozillaに限って言えば、Bugzillaに日本語でもいいからガンガンコメント欲しいですね。「英語で書かなくちゃならない」と思って書かない方も多いんですが、翻訳サイトを使って読んでみて、わからなければ日本のエンジニアに質問が来るので。

斉藤 なるほど、そういう貢献であれば、気軽にできそうだし人にも促せそうです。

浅井 わかりにくい英語でフィードバックもらうくらいなら、専門用語満載で日本語で書いてくれたほうがありがたいんです。フィードバックをもらえないことで発生するコストに比べたら、日本語のフィードバックをもらってそれに日本のスタッフが応えるなんて安いもんです。今はそれこそ、縦書きの仕様とかあるじゃないですか。ああいうところって、日本でしか通用しない用語がたくさんある。それを無理に英語にする必要はなくて、そのまま日本語で書いてほしい。

斉藤 そうですよね…「禁則処理」とか英語でどう言えばいいのか、よく考えたら知らない(笑)。

浅井 そういうフィードバックを世界中の開発者がくれる、という未来を僕らは目指しているんです。それに、Extensible Webが進むことで、例えばライブラリやミドルウェアをビジネスにするような企業も出てきたとしたら、そういう企業ってブラウザベンダとの協業にも本気なので、更にフィードバックが熱くなって嬉しいし。

例えば3Dにしても、UnityとかUnrealとか大きな企業がガンガンフィードバックをくれるので、WebGLやasm.jsも —— 今は WebAssemblyの方向に向かっていますが —— どんどんよくなっていったわけですし。

小松 確かに、ビジネスで使われると急激にフィードバックが貰えるようになりますよね。

斉藤 「趣味」のレベルと「ビジネス」のレベルだと、フィードバックするモチベーションもぜんぜん違うかもしれませんね。

小松 そうそう。趣味でやってる時って、例えバグに遭遇したとしても「このバグは仕様である」って済ませちゃう(笑)。

斉藤 「ま、いっか」で済ませちゃいますよね(笑)。Web技術の進化がビジネスに直結するのであれば、フィードバックのモチベーションは確実に高まると思います。

今あえて問う: Web技術の進化は求められているのか？

白石 ここで一つ、ちょっと刺激的に聞こえるかもしれない問題提起をさせてください。 Web技術の進化って、今そんなに求められているのでしょうか？ 現状で言うと、Web技術って主にデスクトップブラウザで使われていて、モバイルはネイティブでいいよね、と世間に認知されている感覚が僕としてはあって。 しかも、デスクトップは進化が停滞していて、イノベーションはモバイルアプリで起こっている。WebのAPIをどんどん拡充していっているけど、それで喜んでいる人ってどれくらいいるのかな？と。

ダニエル 確かに…最近そういう議論がありましたね。ppk（※）を中心として、「Webは一年くらい開発を止めておこう」という発言がありました。

斉藤 僕もppkの発言は読みました。普通、僕らの開発でも、2年も経てばたくさん技術的負債が溜まっていってしまうものなのに、Webは壊れたままでどんどん新しい機能を追加していこうとしている。「一旦止まってしまうと死んでしまう」「止まることは後退することだ」というある種の強迫観念のようなものがあるのかもしれません。

浅井 実際には（Webの進化は）長い間止まってましたけどね(笑)。

白石 (HTML)4と5の間ね。

斉藤 あの（進化が止まっていた）悲しさを繰り返しちゃダメだと、みんな思っているんじゃないでしょうか。僕は、Webはなくなってほしくないと思っているので、Web技術の進化は続いてほしいと考えています。ただ白石さんが仰るとおり、モバイルはネイティブでいいじゃん、という流れもあるのは確かです。

白石 僕自身も、モバイルアプリであってもCordovaを使って開発していたりするので、Web技術は進化し続けてほしいと考えてはいます。CordovaやFirefox OSと言ったプラットフォームが今よりもっと力を持てば、先ほど僕が言った問題提起は不要だと思うんですけどね。

浅井 今はiOSやAndroidのシェアが非常に大きいですからね。そこら辺の状況が変わってくれば、Web技術の立ち位置ももう少し変わってくるんでしょうけどね。

また、先ほどあれだけ開発者に「声が欲しいんです」と訴えましたが、一方で仕様を作っているメンバーが念頭に置いているのは、5年10年先まで互換性を保ち、しかもあらゆるプラットフォームで動作することです。最初からこれを念頭に置いたプラットフォームは、人類にとって唯一のものだと思う。だから、5年10年先を見据えて絶え間なく技術を進化させていくというのは、誰かがやらなくてはならないと思っています。

白石 そう考えると、昔の「ユースケースありき」で仕様を決めていくというのは少し無理があったのかな、と思えますね。5年10年経ったら、ユースケースなんて同じなわけがないですし。そう考えても、Extensible Webというのは正しい方向なんじゃないかと思えてきました。

ダニエル そうですね。HTML5の世界は、長らくユースケースベースでした。例えばHTML5に何かを提案しようとすると、Ian Hickson（※）の答えは決まって「あなたのユースケースを教えて下さい」（「What’s your use case?」）でしたし。Extensible Webは、そうしたパラダイムからの脱却という面は少なからずあると思います。 ※ ppk…Peter-Paul Koch氏のこと。著名なWebエンジニアで、QuirksModeというサイトを運営している。

※ Ian Hickson…HTML5を始め、近年の様々なAPI仕様を策定するにあたって中心的な役割を果たしていた人物。相性はHixie。

新たなライブラリ、仕様書の変化 – Extensible Webがもたらしつつある変化とは

ダニエル CSSの方でも、ユースケースありきの考え方から脱却しつつあります。例えば「CSS Houdini」は、ユースケースを考えずにCSSの基盤を公開して、その上に新たな機能を載せていくというアイデアです。

例えば、「新しいセレクタが欲しい」という場合、CSSの低レベルAPIで独自のCSSセレクタを作ったり…ということが想定されています。

小松 正確ではありませんが、「Web ComponentsのCSS版」といえばわかりやすいんじゃないかな。

斉藤 「独自のCSSセレクタを作る」というのを実現するhitch.jsというライブラリはすでにありますね。

白石 （READMEの例を一見して）自分の好きなセレクタを書ける！これはすごい。いやー、未来的な話になってきましたね。

斉藤 CSSにまつわる話で言うと、CSS Element Queryっていうのもありますね。

白石 （こちらもREADMEの例を一見して）ああ、これは使いやすそうですね。メディアクエリで「巨大なif」みたいな感じになるのが防げますね(笑)。

小松 ほんとだ、これは便利そう。

ダニエル ちょっといいですか？今ここで起きていることこそが、Extensible Webが目指す形だと思いました。

これまでは、まず英語でできた仕様書しかなくて、その後コードやデモが整備されるまでは中々APIを理解できない。英語がよく読めない人たちにとってはなおさらです。

でも今ここで起きていたのは、アイデアがコードで示されていて、皆さんは説明よりも先にコードを読んでいました。そして、「これはいい」とか「これは良くない」とかそういう話で盛り上がっていた。

小松 確かに。それに、仕様書にコードスニペットが記載されるという動きも、どんどん広がってますよね。そっちのほうがずっと分かりやすいから。

白石 そうですよねー、WebIDL（※）で示されたインターフェース定義から、どう動くのか想像するのとかって、割としんどかったですからね。そもそもWebIDLの読み方を勉強しなくちゃならない。

斉藤 「仕様書の読み方」みたいな講座があってもいいかもしれませんよね(笑)。

※ WebIDL…W3Cのドキュメントで使用される、Web技術用のインターフェース定義言語（IDL:Interface Definition Language）

Extensible Webから探る、Webの未来

白石 では、最後のトピックとして、Webブラウザの未来を探ってみたいと思うのですが、いかがでしょう？例えば以前、「Webは死ぬか」という対談を行った時に、Googleの及川さんが、「ブラウザコードもコンポーネント化が進んで、必要に応じてコンポーネントがダウンロードされる」という可能性を示唆してくれたのですが。

小松 例えばLinuxディストリビューションを想定してみるのもいいかもしれませんね。Linuxのカーネルに当たるのが現在のブラウザエンジン（のコア部分）で、その他の部分、例えばJavaScriptライブラリや利用頻度がそこまで高くないAPIとかは、パッケージみたいな扱いになるとか。

ダニエル 未来のブラウザという話で言うと、もっと専門的なブラウザが出てくる可能性もあるのかな、と考えています。例えばEspialという会社がありまして、別にここは新しい会社ではありませんが、TV専用のブラウザを作っていて、結構使われています。 こういうブラウザが、TVに関係する機能だけ実装すればいいのと同じように、家電専用のブラウザとか、色んな用途に特化したブラウザが出てくる可能性は大きいと思います。

浅井 ブラウザが様々なデバイスで使われるようになっていくと、そのうちブラウザというのはユーザから見えなくなって、意識されなくなっていく。四角くなくなるとか、UIのないブラウザとかが普通に使われるようになっていく。

斉藤 ブラウザがどこにでもある、って世界ですね。

白石 ただ例えば、ウェアラブルデバイスにブラウザが乗るのは当面ないような気もしますね。パフォーマンスの問題もありますし。

斉藤 それは確かにそうかもしれません。が、何をもってブラウザと呼ぶのか、という話もありますね。例えば最近読んだのは、車通勤している最中に、Mediumの記事を読み上げてほしいという話があって。そのためのAPIを作ってはという話だったのですが、サーバ側でMediumのHTMLを解釈して、音声データだけをダウンロードしてクライアントで再生するようにすれば、HTMLを解釈する「ブラウザ」はクライアント側になくてもいいわけです。このように、Webページを「聞く」という行為、それすらも「ブラウジング」と言えると思います。

白石 なるほど、「ブラウザがどこにでもある」という世界を考えると、逆にブラウザが手元になくてもいいわけですね。HTMLが単なる音声データのためのデータソースになっている。

浅井 そういうサービスを作るにあたっても、Web技術を使うようにすると、特許の問題とかが起きにくいんです。

斉藤 ああ、それはありますね。

浅井 …新しいものを作るときに、エコシステムが広がるのをブロックしてしまう原因を、Webは比較的解決していたり、最初から意識していたりすることが多いので、Web技術が広がってくれると、

白石 広がってくれると？

浅井 より人類は幸せになれます。

白石 話でかい(笑)。〆の言葉としていい感じのフレーズが出たところで、本対談を終わりにしたいと思います。皆様、本日はどうもありがとうございました！

読者の皆様は、「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サイトをオフラインでも利用できるようにする仕組み。マニフェストファイルというファイルを一枚用意するだけで、キャッシュの管理はすべてブラウザが行ってくれるというのがウリの一つ。

※ 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')とするだけで、ローカルのストレージに値を保存できる。

※ 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に比べると複雑だが高機能。

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標準技術に関するカンファレンス。

※ John Resig…jQueryを作った人。

Extensible Web Summitとは

2014年9月11日にドイツ・ベルリンにて、Extensible Web Summitが開催されました。本イベントは、Exntensible Web Manifestoに興味を持つ、Web開発者・ブラウザベンダ・W3Cメンバ等が一堂に会し、未来のWebについてディスカッションを行うというイベントです。

イベント自体は、アンカンファレンススタイルで進められるため、会議の前に議題は決まっていません。会議当日の前半のセッションにて、ライトニングトークが5本あり、その内容を参考にしつつ、参加者自らがトピックが設定していきます。設定されたトピックに沿って、本イベントでは3つのブレイクアウトセッションが平行して開催されます。そして、各参加者は自分の興味のあるセッションに参加します。

本記事では、Extensible Web Summit Berlinでの設定されたトピック、およびトピックの中から特にExtensible Web に関係する議論が行われたトピック2つをピックアップし、その議論模様を紹介いたします。世界中のWeb関係者が、どのような点に興味を持っているか参考になるはずです。

当日決定されたトピック

当日決定されたトピックは以下の通りとなりました。

当日の議論の議事録は、こちらで公開されています。各ディスカッショントピック議事録へのリンクもありますので、詳細確認されたい方は、是非チェックしてみてください。

ディスカッショントピックは、Extensible Webに関するものだけではなく、「このトピックについて、W3Cメンバーと開発者との間で議論したい！」というものも多く存在しました（例えば、WebRTCのセッションでは、『iOSってWebRTCサポートされないの？』『こればっかりは分かんないね〜』といった話題も）。

本稿では、各種トピックの中から特に Extensible Web に関わりの深い二つのトピック（上表にて、強調表示）の議論模様を紹介いたします。

セッション紹介：Extensible Web, Huh?

本セッションのみ、全員参加のセッションとなりました。本セッションでは、『Extensible Webって、実際どうなの？』というテーマで、参加者がディスカッションが行われました。

セッションの進行形式としては、質問/疑問を持っている参加者がそれを発言し、他の参加者が回答する流れとなります。ここでは、主な議論事項を紹介いたします。（議事録は、こちら。要旨理解を助けるため一部、議論の順番を組み直して記載しています。）

まず最初の質問として投げかけられたのが、「Exntensible Webでは、低レベルのAPIを公開することになるが、Webのセキュリティモデルに適しているのか？」という点でした。これに対しては、

同様の課題は、Service WorkerやCORSにもある。

や、

もしExtensible Webを実現するためのテンプレート/パターンのようなものがあれば、セキュリティモデルに対する1つの解になるのではないか。

という回答が上がっておりました。

また、Extensible Webでは、世界中のWeb開発者が独自のWeb拡張を進めることが出来ます。このとき、 「多くの開発者が同じ目的を持って、Webの拡張に取り組んだ場合、どうやってまとめていくのか？複数のWebの世界を作ってしまうのではないか？」 という懸念があります。これらに対しては、少しジョークのニュアンスを含みますが、

READMEが最も簡単で理解しやすいものが、生き残るのではないか。

という回答、また世界中の開発者を巻き込むという観点から

技術に取り組むなら、英語が必要だ。優れなコントリビュータの中でも、英語を使えない人をほとんど知らない。 また、仕様に使われる英語をもっと簡単にする必要もある。

という回答がありました。

その他にも、「必要以上に低レベルなAPIを公開することにより、パフォーマンスに影響が出てしまうのではないか？」という懸念も出てきていました。この懸念に対しては、

JavaScriptのパフォーマンスはそこまで悪くない。

といった意見や、

ブラウザネイティブの機能を利用した方が、polyfillを使うよりもパフォーマンスが良いのは理にかなっている。polyfillを毎回ダウンロードする必要もない。

のように、ネイティブの機能のほうがパフォーマンスは良くなる、といった回答も挙がっておりました。

ここまで記載してきたのは、技術的な側面からの質疑でしたが、その他の側面からのコメントとして、

Extensible Webでは、低レベルなAPIを公開する等の技術的な側面はもちろんだが、社会的な側面も必要となる。社会的な側面とはつまり、世界中の開発者をどうやって巻き込んでいくか？ということだ。

というもっともな疑問も挙がっています。本疑問については、参加者の多くが重要と考えており、以下に続く別セッションへ切り出しとなっております。

セッション紹介：New way to do specs; how to connect specs and developers, next generation standardization, etc…

(本セッションレポートは、小松 が執筆しました。要旨理解を助けるため、議論の順番を組み直して記載しています）

本セッションでは、『開発者が標準化プロセスにもっと関われるようになるためには、どのような取り組みが必要か？』についてディスカッションが行われました。W3C HTML5仕様のメインエディター、Robin Berjon 氏がセッションモデレーターを務めました。（議事録は、こちら）

本セッションのポイントは、仕様エディターと開発者との間の連携やコミュニケーションの実効性を上げていくこと。理由は、仕様と実際のニーズとの乖離を防ぐためです。例えば、この手の議論で失敗例としてよく出てくる AppCache ですが、

「AppCacheの失敗は、開発者が望んでいる機能を仕様化しなかったこと」 「AppCacheの考え方（オフラインWeb）自体は、間違っていない。仕様化の進め方が間違っていた」

という分析を行ったとのこと。これを受けて、Indexed Database APIの仕様化にあたっては、エディターとデータベース技術者とで連携したことを紹介し、W3Cの仕様化に普段は関わっていない、実際の利用者から密にフィードバックを得ることが、良い仕様を作るためには重要との考えが示されました。

開発者からのフィードバック手段として現在良く利用されているのが、BlogやSNSへの書き込み。これらのフィードバックは、エディターにとって非常に重要な情報ですが、

「それらを追いかけるのは、大変」

このため、Specifictionというフォーラムを開設しており、仕様へのフィードバックは、是非ここに書き込んでいって欲しいとのことでした。

また、このようなオープンな標準化プロセスを進めるにあたり、その大枠の考え方を WebPlatform Specs として文書化していることが紹介されました。現状、ポイントとしては

• Forkable
• Hackable
• Thoughtful
• Royalty-Free
• Software Practices
• Tested

が挙げられています。最初の二つは、GitHubのイメージですね（参考まで、W3Cではないですが、HTTP/2はGitHub で、オープンに管理されています）。当日のディスカッションでは、

Polyfillの開発やサンプルコードによるユースケースの提示は仕様化を進めるのに有効

との発言もあり、Forkable, Hackableは大変重要な概念と感じました。

あと、3番目の Thoughtful を補足すると、仕様化にあたって「何をゴールにするか？」のルールを複雑に考えていると、それだけで無駄な時間がとられてしまうので、（アジャイルの考え方で）仕様化も継続的に進められると考え、ゴール設定やルールはシンプルでスマートにしようといったことが述べられています。

ほかには、

開発者は普段別の仕事をしており、仕様化貢献にそこまで時間を割くことはできない

というコメントがあり、これを解決するために仕様を機能分割し、開発者の学習コストを下げる取り組みを行っているといった議論もありました。

まとめ

本記事では、Extensible Web Summit Berlinの議論模様を一部紹介いたしました。前述のように、詳細な議事録は、こちらで公開されています。各ディスカッショントピック議事録へのリンクもありますので、詳細確認されたい方は、是非チェックしてみてください。

W3Cの標準化担当者・Web開発者が支持を表名している、「Extensible Web」という概念をご存知でしょうか？ Extensible Webとは、一言で表すと、標準化組織であるW3Cとブラウザベンダだけでなく、 Web開発者も巻き込んでWebの未来を拡張していこう、という考え方のことです。

本記事では、Extensible Webの登場背景、その内容について紹介いたします。

登場の背景

これまでのWebの新機能は、長い年月をかけてブラウザベンダによって開発されてきました。 そのため、多くの場合、Web開発者がブラウザへフィードバックをするには、 まずブラウザ側の機能実装を待つ必要がありました。

しかし近年、Webの開発者が先導して、ブラウザの新機能へ影響を与えるケースが出てきています。 例えば、querySelector や、Object.observe が具体例です。 これらの例は、以下のフィードバックループによって生まれてきています：

1. Web開発者が自身が必要とするユースケースに沿ってAPI(ライブラリ)をデザインする
2. Web開発者は、他の開発者が作成するAPIと切磋琢磨し、自身のAPIを洗練させていく
3. 洗練されたAPIの中から、ブラウザが実装すべき基本的な機能が抽出される（ブラウザがNativeに実装すればパフォーマンスが向上し、かつライブラリのコードも小さくできる)

Webに本当に必要な機能を生み出すためには、 上記のように、ユースケースに沿った実践的なフィードバックループを回すことが重要です。

既にこのプロセスはWeb標準化にも取り込まれています。例をあげると、

といったところが代表的でしょう。例えば、セレクタを用いたDOM操作は jQuery で実践的に有効性が示され、querySelectorとして標準化されました。これにより、jQueryのパフォーマンスは向上し、さらに Zepto.js のような軽量化ライブラリが登場・・・といったWebの好循環を起こしました。

一方、ユースケースの考慮が浅いまま実装されてしまったAPIは、 結果的に実践にそぐわず、憂き目にあってしまうケースが多々見受けられます。(その代表的な例が、Application Cache です)

これまで説明してきたフィードバックループを、 Webを構成するHTML・CSS・JS等の様々な分野で更に展開できるといいのですが、 現在のWebを取り巻く環境では限界があります。なぜならば、
　「Web開発者が、拡張(extend)できるポイントが少ない」
ためです。 例えば、CSSの構文を拡張するのは、既存の拡張ポイント(API)では困難であるため、 そもそもフィードバックループを回しはじめることが出来ません。

Extensible Web Manifest

もし、Web開発者が拡張できるポイントが多くあれば、 言い換えれば、低レベルのAPIがWeb開発者に公開されるとしたら、どうなるでしょうか？ Web開発者が実際に必要とするケースに沿って、 さらに多くのAPIやライブラリを開発できるようになります。

このような考え方は、Extensible Web Manifestoにまとめられています。

Extensible Web Manifesto

Extensible Web Manifestoでは、ExtensibleなWebのプラットフォームの設計原理として、 以下の点を提言しています：

(Extensible Web Manifestoより抜粋、意訳)

Focus on adding new low-level capabilities to the web platform that are secure and efficient.

安全で効率的な、新たな低レベル機能をWebのプラットフォームに追加する

Expose low-level capabilities that explain existing features, such as HTML and CSS, allowing authors to understand and replicate them.

既存の機能(HTMLやCSS)が、これら低レベル機能によりどのように実装されるかを示すことで、開発者の理解を促進し、複製を可能とする

Develop, describe and test new high-level features in JavaScript, and allow web developers to iterate on them before they become standardized. This creates a virtuous cycle between standards and developers.

新機能の開発、表現、テストをJavascriptで実施し、標準化の前にWeb開発者が参画できるようにする。これにより、Web開発者と標準化担当者の間で素晴らしいサイクルが実現される

Prioritize efforts that follow these recommendations and deprioritize and refocus those which do not.

上記のような提言に沿った取組みの優先度を高くし、そうでないものは優先度を低くするか、もう一度フォーカスを練り直す

原典ではそれぞれの項目について、更に詳細な記載がありますので、興味のある方は参照ください。

Extensible Webの今後

Extensible Web Manifestoは、標準化団体であるW3C・各種ブラウザベンダ(Google, Mozilla等)・著名ライブラリの開発者が支持を表明しており、今後より具体化していくことが期待されます。

具体的な活動の一部として、フェイスツーフェイスのミーティングも既に開催されています。 そこで次回の記事では、2014年9月11日にドイツ ベルリンで開催された Extensible Web Summit の議論模様を紹介いたします。