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