HTML5 Experts.jp 副編集長兼エキスパートの吉川です。昨年好評だった「Webの未来を語ろう」企画を2018年もやります！

今回はパネルディスカッション形式で、HTML5 Experts.jp 編集長の白石が、ブラウザベンダーのGoogleのデベロッパーアドボケイトのえーじさん、 Microsoftのエバンジェリスト物江さんをお迎えして、興味深いお話を多数お聞きしました。

会場も交えたトークは、今後のWeb業界の動向を追いかける上で、重要な内容となっているので、ぜひ読んでみてください！

2017年のWebで印象に残ったことは？

白石: まずは簡単な自己紹介と、2017年のWebで印象に残ったことを教えてください。

えーじ: えーじです。Googleでデベロッパーアドボケイトをしています。もともとは、Google Chromeのアドボケイトという位置付けでしたが、最近はもっと広くなって、Web全体のアドボケイトを担当しています。 特にChromeだけの話に限らず、Web全般について話をしていますね。これには、我々のチームの理想として、Webすべてに貢献していこうという想いがあります。

2017年で印象に残ったことは、SafariがService WorkerとPayment Requestに対応すると表明したことがすごく意義深いと思っています。

物江: 物江と申します。Microsoftでエバンジェリストをしています。以前はWebに軸足を置いていたんですが、現在はWebだけに限らずISV(Individual Software Vendor)、独立してサービスや製品を提供しているパートナーさん向けに様々な技術の啓発を行なっています。Webについては、個人的なものも含めていろいろ活動しています。

2017年に印象に残ったことは、WebAssemblyやPWA（Progressive Web Apps）などについて、ブラウザベンダーがきちんと足並みを揃えて、仕様を策定するようになったということですね。非常にいい流れになってきていると思います。

▲左から、日本マイクロソフト株式会社 物江修さん、Google デベロッパーアドボケイト えーじさん

白石: 皆さん、ありがとうございます。ついでに私の2017年で印象に残ったこともお話ししておくと、個人的にはdev.toや日本経済新聞社の日経電子版が爆速だったという、そういう事例が出てきたのは印象的だったなと思います。裏側でHTML5やWebの最先端技術とか、そういったものを使って1段階上のレベルの速さを実現している。

Webプラットフォームベンダーやコミュニティの皆さんの啓蒙活動などもあって、PWAをはじめとしたWeb技術だとかパフォーマンスだとかが、ビジネス上も重要であるというところも浸透してきている。その結果として、Webプラットフォームの機能がフル活用されつつ、パフォーマンスというところに影響がでた良い例かなと。

今回は、Webの過去・現在・そして未来を語るという構成で進めてみたいと思います。

イントロダクション:HTML5は世界を変えたのか？

白石: 2017年以前のWebを振り返ると、ブラウザ戦争などの分断化があって、そこからHTML5のムーブメントが起こり、Webの様々な仕様が生まれてブラウザに実装されました。

ただ、それら「HTML5」のムーブメントは世界を変えたんでしょうか？ これまであまり、そういう振り返りをしたことがなかったので、一度やってみたいなと思っていたんです。お二人はどうお考えですか？

物江: そうですね、一般ユーザーの目からすると、確かにあまり変わっていないかもしれません。例えば、YouTubeのプレイヤーは、FlashからHTML5になりましたけど、変わったって気がつく人はあまりいませんよね。普通の人は、きっとまったく意識せずに使っている。HTML5でできたことは、とっくにFlashでもできていたわけで。

でも、開発者にとっては大きな変化がありましたよね。結局、開発者はみなHTML5を使っています。これはなぜかというと、HTML5がシンプルだからこそだと思うんですよ。

エキスパートの竹洞さんがいいことを言っていたんですけど、Webが素晴らしく進化したのはKISSの原則(*1)のおかげといっていました。つまり、誰でも簡単に使えるからこそ普及した。わざわざFlashを使わなくても、Web標準技術だけを使えばいろんなことができるようになった。それによって作り手側の裾野が広がって、以前よりもリッチなコンテンツがたくさん出るようになってきたのかなと思います。

*1 … “Keep it simple, stupid” （シンプルにしておけ！この間抜け）、もしくは、”Keep it short and simple” （簡潔に単純にしておけ）という経験的な原則の略語。Wikipedia

えーじ: ぼくも、世界は変わったと思います。やっぱりHTML5でWebを変えようっていうムーブメントがあったこと、それ自体が良かったと思うんですよね。良い意味でのブラウザ間の競争が起きて、どんどん新しい提案がなされて、共通して使えるものがどんどん生まれていった。

ちゃんと数えたことないですが、HTML5の機能でみんな当たり前に使うようになったものっていっぱいあると思うんですよ。例えば、CSS3で角丸を使うっていうのももう当たり前にみんなやっているし、それが動かないブラウザはほぼ、ない。そういうものが当たり前に使えるようになったっていうのは、一昔前からすると全然状況は異なっている。そういう意味では、相当変わったと思います。

白石: そういえば、元Mozilla Japanの浅井智也さんに以前教えてもらったんですが、Web関連技術を全部まとめた図があるんです。これ、曼荼羅図みたいな感じなので、「Web曼荼羅」なんて呼ばれているそうです(笑)。

HTML5とその関連技術（webapi.link）

こうして考えると、HTML5のムーブメントはたくさんのものを生み出しましたねえ。一般のユーザーからはあまり変わってないように見えても、「それは時間をかけて変わっているから」という面もありそうですね。

えーじ: はい、そして、これだけのものがたくさん生み出された結果、Webはアプリケーションプラットフォームになった。それが、HTML5以前との大きな違いだと思いますね。

Webは難しすぎる─Webプラットフォームの現状と課題

白石: では、iOSやAndroidといった他のプラットフォームとWebプラットフォームとを比較すると、Webはどういう立ち位置にあるとお考えですか？

物江: Webプラットフォームは時間をかけてここまで成熟してきました。機能的な面では、他のプラットフォームにもひけをとらないというところまで来たんじゃないかと思います。

そして今、Progressive Web Apps (PWA)が浸透しつつあることが、今後のWebにとってはすごく意義のあることだと思っています。 PWAって、ある意味ひとつの理想の到達点だと思うんですよね。Javaなどが理想に掲げていた「Write Once, Run Anywhere」を、PWAは真の意味で実現するわけです。 これ、次のWindowsの大型アップデートでPWAがデスクトップアプリっぽく動いだり、Windowsストアからインストールできるようになるから言っているわけじゃないですよ(笑)。

白石: そこでいつも言われているのが、Webアプリって動作が遅いんじゃないかってことですよね。

物江: ただ、そうした問題についても、Webプラットフォームは長いこと取り組んでいて、もはやあまり問題にならないレベルじゃないかと思います。 ブラウザの実装という面でも、仕様の面でも、絶え間ない改善が続けられてきました。

仕様の面でそうした部分について期待できるのは、やはりWebAssemblyですね（筆者注: ブラウザが高速に実行可能な、ポータブルなバイナリ形式）。 昨年、モダンブラウザが同時にWebAssemblyのサポートを表明するということがありましたが、これでWebの速度はまた一段階アップすることが期待できます。

あとはやはりハードウェアの進歩が解決するものも多いでしょう。ちなみに、今のWeb技術の素晴らしいところは、ハードの性能に縛られた設計をしていないこと、どこでも同じWeb技術が動作することだとも思います。

例えば昔、貧弱だった携帯電話の機能に合わせた仕様で、HDMLやCHTMLというモバイル専門のタグがありましたが、今はもうほとんど残っていません。結局、性能に関わる問題は時間が解決してしまう部分も大きいんです。いま大切なことは、「いかに人間が作りやすいか、使いやすいか」が重要になってくるかなと思います。

えーじ: ぼくも、パフォーマンス面は既にあまり課題とは考えていません。それよりぼくが課題だと感じているのは、開発者にとってのWeb技術はかなり複雑になってしまっていることです。

例えば「Extensible Web」というのを聞いたことがある方がいらっしゃると思います。これはWebの技術設計に対する、ここ数年における指針のようなもので、具体的には「標準としては、ユースケースを規定しない低レベル（低レイヤー）なAPIを提供する」というものです。

そうすることで、そうしたAPIを使用したハイレベルなライブラリだとかベストプラクティスが、開発者の手によって作られることを期待する。こうすることで、「ハイレベルだけど使われないAPI」が標準で規定されてしまうという問題を解決しようとしています。

ただ今は過渡期なので、低レベルなAPIがどんどん増え、ライブラリも量産されていて、はっきり言って混沌としています。例えばService Workerもすごく低レベルなAPIで、実際に使うとなるとなかなか難しい。

そこにGoogleがWorkboxというライブラリを出していたりするんですが、それを使うと簡単にServiceWorkerを使える一方で、ServiceWorkerもライブラリもどちらも学ばなくてはならない。

これがWeb Componentsなんかだと、仕様そのものがどんどん変わっていて、なかなか安定しない。Polymerというライブラリを使おうにも、Polymerも仕様に合わせてどんどん変わっている。どの時点の仕様が正しいのか、検索したときにどれが最新なのかわかりづらい。そういうところが複雑で、開発者はみな苦労してるんじゃないかなと思います。

個人的には、以前Webpackにやられたことがありまして(笑) 。将来的にはES Modulesが広まれば、そういうビルドプロセスを経なくてもうまく動くようになるんだと思うんですが、今は過渡期として、やっぱりGulpなりWebpackなりRollupなりを使う必要がある。

ビルドツールも次々に生まれるし、フレームワークもそう。フレームワークとビルドツール、様々なライブラリも組み合わせなくちゃならないし、ベストプラクティスが簡単にはわからない。その辺がかなり複雑になっているなと感じています。

各ブラウザベンダーのこれからの動向は？

白石: 皆さんご自身の会社の立場からお聞きしたいなと思うんですけど、ブラウザベンダー各社がどういう想いで、どういう方向を向いて実装しているのかをお聞かせください。

えーじ: 会社（Google）としての方向性はもちろんですが、チーム内でWebに関する課題を共有して、その解決策を探ることは普段から行っています。

例えば、先ほど挙がっていたパフォーマンスを例に挙げましょう。

実はJavaScriptのパフォーマンスって、もうあまり問題にならなくなっているんです。むしろ悪いのはレンダリングの部分で、そこを速くするための努力はずっと続けています。

あと、ネットワークの遅延もすごく大きい要因なので、ServiceWorkerみたいな仕様を提供することで、スピードの課題に開発者自身が取り組みやすくする。

さらに、パフォーマンスに関するベストプラクティスを開発者の皆さんと共有するのも重要です。

このように、課題一つとってもたくさんのアプローチがある。こういう活動を、チーム一丸となって同時に取り組んでいるという状態ですね。

白石: なるほど。ちなみにGoogleの中で、「今のWebはこういう課題があるね」みたいな、そういう話し合いっていうのはよくされるんですか？どんな議論がされてるのか興味があります。

えーじ: はい、常にやってますね。世界中から集ってきた情報を、雑談ベースでやり取りするような感じです。

例えばこれからGoogleがインドでももっと使われるようにするためには、インドの市場を考えなきゃいけない。しかしインドは全然違う世界だと。

例えばネットワークにしても、今われわれが4Gは当たり前に使ってますけど、向こうの世界は2Gなんです。3Gですらない。なのに、何MBっていうファイルをダウンロードしないと見れないサイトっていうのはざらにあるわけですよ。そういったネットワーク環境の悪いところに対して、開発者の皆さんがサービスを提供しようと思った時にどうするのか。そういう課題がインドに進出しようと思っているチームから上がってきたりします。

他には例えば最近は、アクセシビリティにもかなり力を入れていたりもしますね。アクセシビリティに強く関心のある人たちがチームに入ったことで、Webのアクセシビリティをもっと良くするための話し合いや仕様の提案なども活発に行なっています。

物江: Microsoft Edgeは、相互運用性とセキュリティ、アクセシビリティとパフォーマンスの4つが何においても優先されています。

例えば相互運用性でいうと、 -webkit-text-stroke というベンダープリフィックスがあります。これ、以前はWebKit系のブラウザでしか動かなかったんですが、現在はEdgeでも開発中なんです。多くのサイトで使われているような機能については、全部同じように動くようにするというのを優先的にやっています。

アクセシビリティに関しては、画面に表示されるすべてのテキストについて、スクリーンリーダーのような外部のプログラムを呼び出せるような仕組みが、WindowsにはOSレベルで入っています。それを使って、アクセシビリティを強化するような仕組みがEdgeに入っていたりしますね。

パフォーマンスについては、Chakra（EdgeのJavaScriptエンジン）のパフォーマンスアップを継続的に行っています。特に、こないだのアップデートでようやくブラウザ内部のリファクタリングが終わったようで、Edgeが出た頃からのパフォーマンスでいうと、3～4倍速くなってます。

白石: リファクタリングっていうのは、Internet Explorerから引きずっているコードがかなりあるのを書き直すって話ですよね。それが行われているって話はだいぶ前に聞いていましたが、ついに終わったんですね。

物江: はい、ほぼ全部終わったんじゃないかと。もともとEdgeのレンダリングエンジンってTrident（IEのレンダリングエンジン）から派生したものなので、20年以上前のものということで、根っこの部分で仕様が古い部分があったんですよ。その修正がようやく終わったという感じです。これから先は、Edgeの開発はどんどん加速していくんじゃないかと期待しています。

あとは、やはり2000年代と比較すると、ユーザーの意見をより開発に取り入れようという姿勢が顕著になったかと思います。Windowsをお使いの方はわかると思うんですが、フィードバックHubというのがありまして、そこでバグの報告だとか、追加してほしい機能をリクエストできるんですよ。そのリクエストのベット数が多いと優先度があがっていって、対応されるというようになっています。

注目のWeb最新技術を一挙に解説！Web Payments、WebVR、AMP、PWA、WebAssembly…

白石: ではここからは、注目のWeb最新技術についていろいろお聞きしたいと思います。Web Payments、WebVR、AMP、PWA、WebAssemblyなどなど、仕様ごとに概要と現状をお話しください。

Web Payments

えーじ: 今までWebでお金を払うといったら、フォームを使ってクレジットカード番号を入れたりとか、どこかのサイトに飛んで、そこのサイトにあらかじめ保存してある支払い情報を使うといったことがほとんどだったと思います。Web Paymentsを使うと、ブラウザがネイティブで表示してくれるUIを使って支払いができるようになるというのが大きな特徴ですね。ちょっと見てもらうと、PolyCartというWeb Paymentsのデモサイトで確認することができます。

Web Paymentsのデモサイト（PolyCart）

ブラウザネイティブのUIを通じてクレジットカードの情報や、配送先、連絡先などの入力を促すことができます。そうして入力された情報はブラウザが記憶してくれるので、次からはクリックするだけで支払い情報を入力することができます。

もっとすごいのは、将来的には支払い方法を追加できるようになるんです。例えば、Apple PayやGoogle Payで支払うのも可能ですし、仮想通貨なども使えるようになるでしょう。

WebVR

物江: 以前から、「Web上でVRコンテンツを表示する」っていうのは、Three.jsなどを使って実現が可能でした。ではWebVRは何が違うかというとVRデバイスからのフィードバックを受けることができるんです。これによって、VRデバイスと深く連動したWebサイトを作ることができます。

それにWindows10だと、ネイティブでVRの環境をサポートしていて、WebVRに対応したWebサイトにいくと、自動的にVRゴーグル上で全画面表示してくれるようになっています。VRのビデオもそのまま見ることができるので、真の意味でシームレスにVRのコンテンツが提供できるようになっています。

個人的に楽しみなのは、VRをきっかけとして新しいUIが生まれてくることですね。既存のVRゴーグルを使ったことがある人はわかると思うんですけど、キーボードもマウスも何も使えないんです。そうすると新しいUIを考える必要があって、そこに新しい可能性を感じています。

えーじ: ちなみに最近はWebXRっていうらしいですね。VR、AR、MRをコンセプトに入れた仕様を作ろうとしているという動きもありますね。

AMP

白石: 次はAMPですが、これについては既にたくさんの方がご存知でしょうから、簡潔に。主にモバイル環境で、Webページを素早く表示できるようにするための、HTMLのサブセットですね。

えーじ: AMPの仕様自体もさることながら、AMPが基本的にWeb Componentsでできているのは興味深いです。Web Componentsの仕組みを使って独自のエレメントを定義していて、なおかつパフォーマンスも追求しているので、結果としてパフォーマンスのベストプラクティスの塊をWeb Components化したものになっている。大変面白いと思います。

Progressive Web Apps

白石: 次は、恐らく今年最大の注目キーワードProgressive Web Appsですね。これは（ずっと啓蒙してきた）えーじさんに語っていただくしかないでしょう。

えーじ: はい。とはいえPWAという言葉自体は、皆さんに意識してもらいやすくするためのマーケティング用語のようなもので、技術的な観点からはそれ自体意味がないと思っています。実際の中身はService WorkerだったりとかPush Notificationだったりとかそういう具体的な機能やAPIから構成されています。

日本でも、昨年後半くらいからPWAが注目されはじめました。さっきのdev.toとか日経電子版とかも、PWAの構成要素を利用することで高速化が実現できたと。PWAの中のひとつひとつの技術要素をうまく使うとここまで速くできるんだよ、といういい例ができたなと思っています。

白石: ちなみに、個人的にはPWAっていまいち意味がわからないな、と思ってて。なにが「プログレッシブ」なんでしょうか？プログレッシブって、「だんだん（進化する）」って意味ですよね。

えーじ: PWAにおける「プログレッシブ」には2つ意味があります。

1つは昔から言われているプログレッシブ・エンハンスメントです。古いブラウザでも見ることができる基本的なWebサイトをまずは作って、そこに、新しいブラウザで使える機能を足していくという考え方。そうすれば、クライアントの環境を最大限活かすことができます。

白石: では、Service Workerが使えるブラウザだったらオフラインという機能が使えるけど、そういう機能が使えないブラウザにも同等のものを提供する。既存のサイトにあとからその機能を提供することも割と簡単にできますよっていうそういう思いを込めたものということですね。

えーじ: そうです。もう1つが、今あるサイトに機能を付け加えていくことで、徐々にPWAに近づけていけるという意味です。PWAのためにサイトを一から作り直すとか、大幅な改修を行う必要はない。既存のサイトを徐々に拡張していけばいいんです。

白石: なるほど、そういう意味合いだったんですね。ちなみにPWAの中では、Service Workerが代表的なAPIですよね。他にはWeb App Manifestとか、Push Notificationとかでしょうか。

えーじ: そうですね。ちなみに、PWAのウリの一つに、OSのホーム画面にアイコンを追加できるというのがあるんですが、以前はただのWebアプリへのショートカットでした。でも今は違います。PWAをホーム画面に置く際、アプリのパッケージを動的に生成してインストールするので、OS上の扱いはネイティブアプリとほとんど変わりないんです。なので、プッシュ通知のオン／オフをアプリごとに設定できたり、ネイティブアプリでしかできなかったことがPWAでも同様に行えます。

WebAssembly

白石: 次はWebAssembly、物江さんご説明お願いします。

物江: WebAssemblyは、Webブラウザ上で非常に高速に動作させることができる、デバイスに依存しないバイナリ形式です。現在は用途がある程度限られていて、DOMを操作することなどはできませんが、CPU依存の計算処理などは極めて高速に動作させることができます。 Emscriptenなどのツールを使うと、C/C++で作られたものをWebAssemblyに変換できるので、C/C++で書かれたゲームなどをWebAssemblyに移植することも比較的容易です。また現在はまだ開発中ではありますが、MonoがC#からWebAssemblyをコンパイルするmono-wasmであったり、マイクロソフトも実験プロジェクトとしてWebAssemblyを介してWebブラウザー上でC#とRazorを走らせるWeb UI framework Blazorを開発していたりします。

（ここで会場からエキスパートであるあんどうやすしさんから質問）

あんどうやすし: 現在のWebAssemblyって結局計算することしかできないじゃないですか、DOMもいじれないし、JavaScriptのAPI呼び出しも直接は行えない。今後もそれは変わらないんでしょうか。特にデータの渡し方に結構制限があって、使い勝手がいいものにするには難しいなと感じています。SharedArrayBufferという仕組みで一次元配列の共有はありますが、それも使いづらいし…。

物江: それは、今の段階ではまだなんとも言えないですね。

えーじ: ちなみにSharedArrayBufferはこないだのメルトダウンとスペクター(*2)の影響で機能が停止になります。

白石: ありゃ、まさかそんなところにまで影響及ぶとは…(笑)。

*2 … CPUでの投機的実行という高速化プロセスを悪用した脆弱性

Web Share API

白石: 他には、注目のAPIとかはありますか？

えーじ: 最近追加されようとしている新しい機能にWeb Share APIというのがあります。

Androidのインテントをご存知の方だったらすぐ分かる機能ですが、例えばあるサイトを「FacebookやTwitterでシェアしたい」という場合に、Web Share APIを使うと簡単に外部アプリを呼び出すことができます。

逆に、自身のWebアプリを「シェアする先のアプリ」として使ってもらうようにすることもできます。それがWeb Share Target APIというものです。

Web Share APIは既に使えるんですが、Web Share Target APIは、現在限られたサービスにしか開放されていません。このように、Chrome では一部のドメインに先行してWebプラットフォームの機能を試してもらうオリジントライアルというものをやっているのですが、現在TwitterのモバイルサイトがWeb Share Target APIを使えるようになっています。mobile.twitter.comで実際に試すことができますので、TwitterのPWAをまだ試したことがない方は、AndroidのChrome betaチャネルか、devチャネルを使ってインストールしてみてください。何かシェアしようとしたときに、TwitterのPWAが候補として出てきます。

Web Authentication

白石: Web Authenticationというのもあると聞きました。

えーじ: Web Authenticationは、実はEdgeでもう使えるんです。仕様がちょっと古いので、APIが全く異なりますが、Polyfillもあります。Web Authenticationをひとことでいうと、セキュリティキーなどを用いた多要素認証を標準技術で扱えるようにするものです。顔認証や指紋認証と組み合わせれば、安全性の高いログインの敷居はぐっと下がると思います。

物江: FIDO Allianceという標準化団体があるんですけど、そこで生体認証などのもっと広い話をしています。既にWindowsだとWindows Helloという生体認証の仕組みがFIDOの標準で作られていますね。

えーじ: FIDOのWeb版がWeb Authenticationになるわけです。Web Authenticationの実装はこれからどんどん出てくるでしょう。Mozillaさんもこないだ実装を開始しましたし、Chromeもそろそろ入ってくるのかなと思います。

白石: そうすると、もしかしたら今年はWebサイトで指紋認証とか顔認証とかが一般的になってくるという可能性があるってことですかね。

えーじ: そうですね。どの認証方式を使えるようにするかっていうのは、順番に1つずつ入れていくという話らしいので、まずはセキュリティーキーから利用できるようになって、そのうちNFC、指紋認証ができるようになっていくようです。徐々にそういったものが実装されていけば、本当にパスワードを覚えなくてもいい世界っていうのが実現できるかもしれないので、すごく楽しみにしています。

ちなみに、Credential Management APIというIDとパスワード、いわゆる共通鍵認証をする仕様があるんですが、それとAPIのネームスペースが同じになるので、共通のAPIを使うことになります。まったく別々だった仕様が一緒になるというのも個人的には面白いと感じています。

エキスパートたちが見据えるWebの未来について

白石: 最後にWebの今後について感じていることをお聞かせください。

えーじ: ぼくらブラウザベンダーは、「こうなるといいな」というものをいろいろ作ってるんですけど、それはブラウザベンダーが勝手にやってるわけじゃなくて、開発者の皆さんの声とか、こういうWebがいいという声をもとにやっているので、フィードバックをできるだけいただいたほうが、より皆さんの理想としているWebができると思っています。

フィードバック方法にも今はいろいろあって、GitHub上で管理されている仕様にIssueを立てるっていうのも一つの方法ですし、一番簡単な方法です。それすらめんどくさいということであれば、ぼくに直接言っていただくとかでも構いません(笑)。そんな感じで、開発者の皆さんと一緒にWebを盛り上げていけたらいいなと思います。

物江: 個人的な思いとしては、今非常にWebって良い方向に進んでいると思っています。（お互いを傷つけ合うような）ブラウザ戦争は終わりました。今は良い意味でお互いに競争し合ったり、歩調を合わせてWebを良いものにしていこうという動きが主流になりつつ会って、とても好ましく感じています。今後もそれが続いていって、Webのテクノロジーの活用範囲が広がればいいなと思っています。

白石: 皆さん、本日は様々なお話をお聞かせいただき、ありがとうございました！

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に、様々なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、WebAssemblyコミュニティを率いてらっしゃる清水 智公さん（@chikoski）です。清水さんのセッションは「WebAssembly MVPまとめと、今の議論の内容からいくつか」でした。

※スライド資料はこちらで公開されています。

WebAssemblyとは何か？

白石: 今日はよろしくお願いします。まずは自己紹介をお願いできますか？

清水: WebAssemblyのコミュニティを運営している清水です。@ikkoさんと一緒に、「emcscripten night !!」というイベントを四半期に一回くらいのペースで開催しています。

白石: では早速ですが、WebAssembly（WASM）とは何なんでしょうか？

清水: 一言で言うと、Webブラウザ上で実行できる、ポータブルなバイナリ形式です。現在、「MVP（Minimul Viable Product: 最小限有用な機能を備えたプロダクト）」の実装が完了し、ほぼすべてのメジャーブラウザで利用できるという状態です。

白石: ポータブルというと、ブラウザにも、OSにも、デバイスにも依存しないということですね。

清水: その通りです。Javaをご存じの方であれば、classファイル形式を思い浮かべていただくと理解は早いと思います。

白石: なるほど。なぜそうしたバイナリ形式が必要とされたんでしょうか？

清水: これまでWebページで動作するプログラミング言語といえば当然JavaScriptだったわけですが、JavaScriptは遅いという問題がありました。asm.jsでスピードの面は大分改善されたのですが、今度はサイズが大きくなってしまうという問題も生まれました。それで早く動かせて、サイズもasm.jsよりは小さいものとして、WebAssemblyが生まれたんです。

遅さの原因の一つは、JavaScriptは変数の型が動的だということです。例えばJavaScriptで足し算を行うコードがあるとしたら、いろんな可能性を考慮しなくちゃいけないんですよね。

値が整数かもしれないし、浮動小数点かもしれない。文字列かもしれないし、valueOf()を持つオブジェクトかもしれない。こういう可能性を踏まえると、単なる足し算といえども最適化は容易じゃないわけです。

ですがWebAssemblyの場合は、コンパイル時に変数の型が決まるので、最適化が容易なんです。今では、ネイティブに比べて2/3くらいの速度というところまで改善されています。

白石: なるほど。サイズが小さくなるという点についてはいかがでしょう。

清水: JavaScriptは当然テキスト形式ですが、テキストってやはり冗長なんですよね。例えば、とあるゲームのコードを全部JavaScriptに変換したところ、40メガバイトを超えるサイズになってしまったことがあります。

これでは、JavaScriptのソースコードをダウンロードするだけでかなりの時間がかかってしまうし、実行にかかるコストも半端ではありません。

WebAssemblyは、サイズを小さくすることを最初から念頭に置いたバイナリ形式ですので、確実にサイズは縮まります。元のJavaScriptファイルにもよりますが、ミニファイして圧縮した場合に比べても小さくなるのは確実。場合によっては半分以下のサイズになることもあります。

白石: それほど素晴らしいのであれば、将来的にはJavaScriptを置き換えていくような存在になるのでしょうか？

清水: いえ、WASMはJavaScriptの置き換えは目指しておらず、あくまで補完する存在という位置付けです。例えば、WASMはDOMに直接アクセスすることができませんからね。

WASMへの対応状況

白石: では改めて、ブラウザのWASMへの対応状況を教えていただけますか？

清水: 先ほども申し上げたとおり、ほとんどのメジャーブラウザで使えます（参考: Can I Use）。Safariが11から対応するようになったのは大きいですね。iOSでも使えるようになったということなので。 Edgeも先日のCreator’s updateでデフォルトでWebAssemblyを利用できるようになりました。また、Node.jsでもWebAssemblyは動作します。

白石: Nodeでも動くんですか！知りませんでした。WASMにコンパイル可能な言語には、どのようなものがありますか？

清水: 様々なコンパイラで利用されている、LLVMという中間言語があるんですが、LLVMに変換される言語だったらだいたい大丈夫です。Emscriptenというツールを使うと、LLVMからWASMに変換できるのです。

LLVMにコンパイルできる言語というと、C/C++/Objective-Cなどが挙げられます。また、RustもWebAssemblyに対応しています。

あとUnity限定になってしまうのですが、C#にも対応しています。他にはAssemblyScriptといって、WebAssemblyを出力できるTypeScriptのサブセット言語も存在します。

白石: C#やTypeScriptもあるんですね！WebAssemblyにはガベージコレクタがないと聞いていたので、それらの言語が使えるというのは驚きです。

ちなみに、WASMを出力できる言語や動作する環境がたくさんあるのはわかったのですが、実際どれくらい実用的なんでしょうか？

清水: 今は、ざっくり言ってC言語のコードをコンパイルして動かす能力は備えているというところです。 C++への対応は完全じゃありません。C++の例外をまだうまく扱えないんですよね。

白石: Cと言えば、メモリを直接操作するようなコードを直接書けると思うのですが、それがWebAssembly上だとどのように動作するのでしょうか？

清水: WebAssemblyのコードには専用のメモリ空間が割り当てられるんです。C言語におけるメモリ操作などは、そのメモリ空間に対して行われます。そのメモリ空間は、JavaScriptコードからもArrayBufferオブジェクトとして参照できます。

ちなみに、WebAssemblyの仕様上は64ビットのメモリ空間を扱えるのですが、現在の実装上では32ビットに制限されていますね。

WASMを使う

白石: WASMを使うコードはどういうふうになりますか？

清水: まず、WASMのバイナリが必要です。拡張子は.wasmです。そのファイルをfetch()でもXMLHttpRequestでも何でもいいので読み込んで、バイナリコードをArrayBuffer化し、WebAssembly.instanciate()というメソッドに渡します。

すると、WebAssemblyコードの実行結果がPromiseの戻り値として返ってくるので、そこにエクスポートされている関数をJavaScript側から呼び出すことが可能です。

// MDNのサンプルを引用
// https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiate

// WASMファイルを読み込み
fetch('sample.wasm').then(response =>
  // ArrayBuffer化
  response.arrayBuffer()
).then(bytes =>
  // インスタンスを生成
  WebAssembly.instantiate(bytes)
).then(result =>
  // 生成されたインスタンスのエキスポートされた関数を呼び出し
  result.instance.exports.exported_func()
);

白石: なるほど、使うのはそれほど難しくなさそうですね。JavaScriptからシームレスに関数の呼び出しを行えるのが素晴らしい。

清水: はい、それにWASMのコード内から、外部JavaScriptのコードを呼び出すことも簡単にできます。WebAssembly.instantiate()の第二引数で、WASMコードがインポートするメンバーを指定できるんです。

// MDNのサンプルを引用
// https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiate

// WASMがインポートして使用するオブジェクト
var importObject = {
  imports: {
    imported_func: function(arg) {
      console.log(arg);
    }
  }
};
fetch('simple.wasm').then(response =>
  response.arrayBuffer()
).then(bytes =>
  // インポートするオブジェクトを指定
  WebAssembly.instantiate(bytes, importObject)
).then(result =>
  result.instance.exports.exported_func()
);

白石: なるほど、ダイナミックリンクが可能なんですね。WASMがJavaScriptをどう補完するのか、よくわかりました。

WASMはどう使われていくか

白石: WASMが登場したことで、具体的に何が変わっていくと思いますか？

清水: まずはやはり、C/C++で書かれたコードをWASMに変換して使うのが一番最初に思いつくユースケースです。 コンシューマー向けのサービスでいうと、やはりゲーム系がすぐに思いつきますね。

例えば新たなゲームタイトルをスマホ向けにネイティブで開発しつつ、WASMでコンパイルしてWeb版も同時に開発するということができます。 UnityはWebAssemblyに対応しているので、そういう開発を行うのは比較的簡単です。

白石: なるほど、スマホ版だけじゃなくてWeb版も同時に開発して公開できれば、ユーザーへのリーチが拡大しそうですね。

清水: 実際、とあるベンダーさんが、Android用のゲームをWebブラウザでも動作するようにしたところ、ユーザー数はかなり増えたと聞いています。

白石: では、まずはネイティブとWebのクロスプラットフォーム開発でWASMは活躍しそうだと。 他にはC言語で書かれた資産とかもWeb上で使えそうですよね。例えばgzipのライブラリとか。

清水: そう、圧縮や暗号系、画像処理などの、Cで書かれたライブラリをWeb上に移植するのにも向いていますね。 CPUに依存する処理を高速化するのには、すごく向いています。

Cで書かれたコードの移植といえば、luaもWASMにコンパイルできたそうです。

白石: おお、言語処理系まで！そうか、よく考えたら、現在のWASMにガベージコレクタがなくとも、ガベージコレクタを備えた処理系ごとコンパイルしちゃえばいいんですね。

WASMのこれから

清水: はい、ちょうどガベージコレクタの話が出たので、WASMのこれからという話をしたいと思います。WASMの次のターゲットとして、ガベージコレクタが提案されています。

こちらはおそらく、「ガベージコレクタを使いたい場合は使える」という設計になると予想されています。

白石: ガベージコレクタが使えるようになったら、WASMをターゲットにした言語処理系とかが作りやすくなりそうですね。WASMで提案されている仕様は他にもありますか？

清水: まず、スレッドを使えるようにするという提案があります。 やはり、pthread (POSIXスレッド: C言語で使用できるマルチスレッドAPI)を使いたいという要望が多いんですね。 複数のWeb Workers（Web環境でマルチスレッディングが可能なAPI）で共有できる Shared ArrayBuffer は既に利用可能ですが、複数のスレッドを待ち合わせるwaitやwakeと言った命令も使えるようにすることを見据えています。

他には、先ほども申し上げたように例外を扱えるようにして、C++コードもWASMに正しくコンパイルできるようにすること。WASMのモジュールとECMA Scriptモジュールの整合性を取る…と言った提案も行われています。

白石: WASMの未来、楽しみですねー。最後にお聞きしたいのですが、現時点でWASMを試すのにおすすめの言語はありますか？C/C++で書くのはなかなかしんどいなあ、と…

清水: HTML5 Experts.jpの読者に向けてという話であれば、TypeScript（のサブセット）をWASMにコンパイルできる、AssemblyScriptを使うのはおすすめです。Web技術者が軽く試してみるという用途には最適だと思います。

白石: 本日は、WebAssemblyについて基礎から最新情報まで教えていただき、ありがとうございました。

低水準言語asm.jsとWebAssembly詳解の第4回目です。前回までで、asm.jsの必要とされる理由と、その仕様、そしてasm.jsを生成するツールであるEmscriptenを紹介しました。CやC++で書かれたソースコードから「低水準」なJavaScriptコードが出力され、それが高速に動作する理由について述べてきました。

前回の最後で述べた通り、Emscriptenで出力されたasm.jsのファイルはサイズが大きくなりがちでした。ファイルのサイズが大きくなるとダウンロードに時間がかかるのはもちろん、ネイティブコードへのコンパイルにも大きく時間がかかってしまいます。つまり高速に動作するのは良いが、起動に時間がかかるサイトができてしまうことになります。

この問題を解決するために登場するのがWebAssembly(WASM)です。これはプログラミング言語ではなく、ファイルフォーマットの一種です。 同じプログラムをasm.jsとして出力したものと、WASMとして出力したものを比較すると、WASMの方がぐっと小さくなっていることがわかります。

現在はその仕様策定が固まり、ブラウザへの実装も済み、リリースを待つばかりです。またコンパイラへの実装も進んでいます。特にBinaryen（後述します）への最適化処理の実装のおかげで、asm.jsより高速に実行できるようになりました。

下記のグラフ（MozillaのHacksブログより引用）はasm.jsとWASMの速度を比較したものです。値はネイティブの実行スピードに対する相対的な速度を表していて、1に近づけは近づくほどネイティブに近いスピードで動いていることを表しています。Bulletを除く全てのベンチマークでasm.jsより高速に動いています。これはコンパイラの行う最適化処理のおかげです。

この評価は2016年10月末の時点に、Intel Core i7-2600 @ 3.40GHzで動作するLinux版 64-bit Firefox 52 (Nightly)で計測されました。現在は最適化処理の更なる修正によって、Bulletでもasm.jsを上回るパフォーマンスが出るようになっています。

連載の最後は、リリースが間近のWASMについて、コンパイル方法、仕様、そしてJavaScript APIについてご紹介します。

WebAssemblyとは

WebAssemblyとはプログラムを表すファイルフォーマットの一種で、拡張子には.wasmを利用することが一般的です。 Webで扱うファイルの大半はテキスト形式ですが、WASMはバイナリ形式でプログラムを表現します。 バイナリエディタを用いてWASMファイルを作成することも、もちろん可能ですが、Emscriptenに代表されるコンパイラを使って出力することが一般的です。

仕様はW3CのコミュニティグループのメーリングリストやGitHubで議論が行われています。議論の指針は次の4つです。

• 高速で効率的に実行できつつも、ポータブルであること
• ソースを表示できること
• 安全であること
• Webを破壊しないこと。つまり他のWeb技術と組み合わせることができること

このコミュニティグループには、Google、Microsoft、Apple、そしてMozillaの各ブラウザベンダが参加しています。実装もそれぞれに進んでおり、Firefoxでは　52で、Chromeでは57でそれぞれ標準サポートされました。EdgeとWebkitは開発の途中です。Edgeの開発版でAngryBotsが動作している様子は、こちらの動画で確認できますし、Webkitの状況はこちらで確認できます。

WASMの想定される利用例は？

現在のところ想定されているWASMの利用方法は次の3パターンです：

1. アプリ全てをWASMで実装する：C/C++で書かれたアプリをWebに移植するための手段
2. WASMでほとんどを実装し、UIなどをWeb技術で実装する
3. Webアプリケーションのうち、速度が必要な部分をWASMで実装する

1はWebを新しいアーキテクチャとみなし、C/C++のソースコードをクロスコンパイルする、というイメージです。この典型例はゲームでしょう。iOSやAndroid、PS4、Xbox One、PCなど様々あるゲームプラットフォームにWebが加わり、いくつかのプラットフォームへゲームをリリースするのと同じようにWeb向けにゲームをリリースする、というイメージです。

2は既に持っているCやC++の資産を活かしつつ、リッチなUI/UXを提供するといった使い方です。例えば画像認識エンジンや、動画像処理エンジンをすでに持っていて、これらをサービス化したい、といった場合です。それらのエンジンをWASMに変換した上で、UXやUIはWebの技術や開発手法を利用して提供することで、お互いの良いところを取ることが可能です。

3は暗号や圧縮・展開、画像処理といった重たい処理の高速化にWASMを利用する、といった使い方です。asm.jsがよく使われてきた用法でもあります。サーバサイドであれば、Rubyが遅くなってきたのでRustで書き換える、Pythonでは辛いからGoで、といったことがよく行われてきました。フロントエンドではそのようなことは難しかったのですが、WASMを使うことで、アルゴリズムの改良などへ踏み込まずに高速化を行えるようになります。

EmscriptenでWebAssemblyを出力するには

テキスト形式のプログラムからWebAssemblyを変換して出力する方法は、概ね次の3つになります：

1. C/C++で書かれたソースコードをEmscripntenで処理して出力する
2. Rustで書かれたソースコードをコンパイルして出力する
3. WAST（WASMのテキスト形式）で書き、それを変換して出力する

現在のところは1が最も事例の多い変換方法でしょう。Emscripten自身のインストール方法は前回の記事をご覧いただくとして、ここではWASMを出力できるように設定を行い、Hello,Worldをコンパイルするところまでを説明します。

EmscripntenでWASMを出力するためには、開発版とBinaryenというツールが必要です。どちらもemsdkを利用してインストールできます。

$ emsdk install sdk-incoming-64bit emscripten-incoming-64bit clang-incoming-64bit
$ emsdk activate sdk-incoming-64bit emscripten-incoming-64bit clang-incoming-64bit

アクティベート後は忘れずに環境変数を更新しておきます：

$ source ./emsdk_evn.sh

では次のHello,WorldをWASMに出力します。 まず次のようなC言語で書かれたソースコードを用意します。

#include <stdio.h>

int main(int argc, char **argv){
  printf("Hello, World!\n");
}

このコードをEmscriptenを使ってコンパイルします。

$ emcc -o hello-world.html -s WASM=1 hello-world.c

• -oオプションでHTMLファイルを出力すること
• -s WASM=1を指定すること

この 2 つがポイントです。特に-s WASM=1をつけないと、asm.jsが出力される点にご注意ください。

出力されたWASMファイルが動作しているかどうかは、出力されたHTMLファイルをブラウザで表示させることで確認できます。asm.jsなどはファイルを直接開いて実行を確認できましたが、WASMでは行えません。これはWASMの実行時にはクロスオリジン要求が必要で、それがfileスキームには実装されていないためです。そのため簡易なWebサーバを起動する必要があります。任意のものをお使いいただけますが、Emscriptenに同梱されているemrunコマンドを利用すると設定やインストールをしなくても簡易なWebサーバを起動できます。

$ emrun emrun --no_browser --port 8080 .

上記のコマンドを実行すると、コマンドを実行したフォルダをドキュメントルートとしたWebサーバが、8080番ポートで実行されます。こちらへアクセスすることで、動作を確認できます。

WASMモジュールの構造

実はWASMのMVP(Minimal Viable Product/最低限の目標)はasm.jsとの互換機能の提供でした。つまりWASMはasm.jsでできることはできると思っておくと、概ね間違いはありません。例えばasm.jsファイルはソフトウェアモジュールを定義していましたが、同様にWASMファイルもソフトウェアのモジュールを定義します。

とはいえディテールは大きく異なります。asm.jsは（低水準とはいえ）JavaScriptとして処理できる形式でモジュールとその関数本体を定義していたのに対し、WASMは仮想的なハードウェアで動く低水準な命令の集まりとしてモジュールを定義します。WASMはその仕様で型付けされたスタックマシンを定義しており、WASMファイルにはそのスタックマシンで動作するモジュールの抽象構文木（AST：Abstruct Syntax Tree）が定義されています。 抽象構文木がバイナリ形式で与えられているおかげで、ネイティブコードを出力するために必要な処理の中で重たい字句解析の全てと、構文解析の大半を省くことができます。

さてWASMファイルはプリアンブルと、モジュール定義の2つの部分から成っています。プリアンブルはWASMファイルであることを表すマジックナンバー（32bit）と、バージョン番号（32bit）の2つのフィールドで構成されます。モジュール定義は次の7種類のセクションを持ち得ます。依存関係はありますが、これらの全てを省略することもできます。

asm.js同様、WASMでも関数は全て型付けされます。その型が列挙されているのがtypeセクションです。関数の型は引数の型と返り値の型を組み合わせて定義します。例えば次のような足し算を行う関数は(i32, i32) -> i32のように型付けされます。

int add(int a, int b){
  return a + b;
}

このような関数の型のことを「シグネチャ」と呼びます。シグネチャには、それぞれidが割り振られます。このidを用いて、個々の関数を型付けしていきます。個々の関数と、その関数のシグネチャの対応づけが行われるのがfunctionセクションです。上記の(i32, i32) -> i32というシグネチャのidが0の時、次の2つの関数は0番目の関数（addのこと）のシグネチャは0、1番目の関数（subのこと）のシグネチャは1、というようにfunctionセクションへ記述されます。

int add(int a, int b){
  return a + b;
}
int sub(int a, int b){
  return a - b;
}

それぞれの関数の本体、つまり関数定義の{と}に挟まれた部分は、codeセクションに記述されます。このセクションに記述される内容については節を分けて説明します。

上述したように、WASMはモジュールを定義します。つまりWASM内で定義された関数のうちいくつかは外部へと露出します。逆に外部で定義された関数を読み込んで関数を定義することもあります。露出する関数や読み込まれる関数は、それぞれexportとimportのセクションに記述されます。

Memoryセクションには、このモジュールで利用するヒープ領域の初期サイズが設定されます。WASMのメモリは後述しますが線形で、最大4GiBまで利用できます。このセクションで定義されるメモリサイズはあくまで初期化時に割り当てられるもので、grow_memory命令でより多くのメモリを確保できます。

これら以外のセクションもモジュールの定義に必要とされることがありますが、今回は説明を割愛します。詳しくはこちらのデザイン文書をご覧ください。

WASMで定義される抽象構文木

ここまで述べてきたWASMの特徴をまとめると、次の3点になるでしょう。

• バイナリフォーマット
• モジュールの定義
• 型付けされたスタックマシンで動作する抽象構文木を表している

ここからはより詳しくWASMの構造と、それが表す抽象構文木について見ていきます。

そのために　WASMのテキスト表現であるWASTを利用します。このWASTは現在仕様が議論中のため、将来的に記法が変わる可能性があることにご注意ください。

さてa = 1 + 2 * 3;という式は、WASTでは次のように表現されます。

(set_local $a
  (i32.add
     (i32.const 1)
     (i32.mul
        (i32.const 1)
        (i32.const 2)
     )
  )
)

このようにとても括弧が多いのがWASTの特徴です。この記法はS式と呼ばれるもので、LISPというプログラミング言語でよく用いられるもので、木やリストの形式的な記法です。(と)で囲まれたものがノードとなり、その間に挟まれた別のノードは子ノードとなります。先ほどのWASTは次の図のような木構造を表しています。

set_local、i32.add、i32.mul、i32.constというのが、WASMの仕様でで定義されているスタックマシンの命令です。それぞれローカル変数への代入、加算、乗算、即値の定義を行います。四則演算や速値の定義を行う演算子は、扱うデータ型によって異なるものが用意されています。関数本体はこのように記述され、codeセクションに格納されます。

先ほどのWASTを使って、引数に1+2*3の結果を足す関数は次のように記述できます。詳しくは説明しませんが、なんとなく雰囲気は伝わってくるかと思います。

(module
  (func $addSome (param i32) (result i32)
    (local $a i32)
    (set_local $a
       (i32.add
          (i32.const 1)
          (i32.mul
            (i32.const 1)
            (i32.const 2))))
    (get_local 0)
    (get_local $a)
    (i32.add))
  (export "addSome" (func $addSome))
)

なお、このWASTはスタックマシンの性質をうまく使えていません。その特徴をうまく使うと、次のようになります。

(module
  (type (;0;) (func (param i32) (result i32)))
  (func (;0;) (type 0) (param i32) (result i32)
    (local i32)
    i32.const 1
    i32.const 1
    i32.const 2
    i32.mul
    i32.add
    set_local 1
    get_local 0
    get_local 1
    i32.add)
  (export "addSome" (func 0)))

またコンパイラで最適化処理を行うと、次のように単純化されます。1+2*3の結果をコンパイル時に計算を済ませてしまって定数とすることで、不必要な計算を省いています。

(module
  (type (;0;) (func (param i32) (result i32)))
  (func (;0;) (type 0) (param i32) (result i32)
    get_local 0
    i32.const 7
    i32.add)
  (export "addSome" (func 0)))

WASMの構造を把握するには、The WASM Explorerというサイトを利用されるといいでしょう。 このサイトでは、C/C++のプログラムとWASM、Firefoxによって変換されるx86のアセンブラとを比較できます。 Emscriptenで出力されたものと比べると、標準ライブラリで定義されるシンボルや関数が含まれないためコンパクトで、理解しやすいものが出力されます。

WASMで扱えるデータ型

WASMで扱えるデータ型は次の4つです。

整数型と浮動小数点型とを区別して扱える点が、通常のJavaScriptとは異なります。また64bitの整数が扱える点もJavaScriptやasm.jsとも異なっています。

それぞれのデータ型に対して、四則演算、比較演算、即値、データのロードとストアなどの演算子が用意されています。また整数型に対してはビット演算子が、浮動小数型に対しては切り捨て、切り上げなどの演算子が用意されています。

また型間のデータ変換のための演算子も用意されています。32bitから64bitへの変換だけでなく、64bitから32bitへの変換も行えます。もちろん整数から小数へ、小数から整数への変換も行えます。

線形メモリ

WASMの命令セットはスタックマシン型として設計されていますが、メモリに対するアクセスも行えます。WASMのメモリモデルには次の特徴があります：

• 線形
• バイト単位でアクセス可能
• ページ(64KiB)を単位としたメモリの増加
• コード領域はない
• リトルエンディアン
• 最大4GiB

メモリスタックへのデータの読み込みは各データ型の持つload演算を使って行います。WASMはC/C++コードから生成されることを念頭に置いているため、load演算には、i32.load_8_sやi32.load_16_uのようなWASMにはない8bitや16bitのintをロードするものがあります。これらの命令はメモリ上では8bitや16bitの大きさを持つ値を、自動的に32bitへと拡張します。

同様にメモリへのデータ書き込みはi32.storeのようなストア演算で行います。ストア演算も各データ型ごとに用意されており、整数型に対してはi32.store8やi32.store16のように一部分だけを保存する演算も用意されています。

上述したようにWASMのメモリは線形で、0から順にアドレスが付いています。ロード演算やストア演算はアドレスを使って、読み書きするメモリ上の位置を指定します。現在のところアドレスは32bitの符号なし整数で表現されます。そのため利用できるメモリの大きさは4GiBに制限されます（この制限はのちに解消される予定です）。

メモリは常に4GiB確保されるわけではありません。初期化時に確保される量はモジュールで定義します。プログラムの中でgrow_memory演算を行うことで、このサイズを増やせます。また現在のメモリサイズはcurrent_memory演算で取得できます。これら2つの演算はメモリをバイト単位ではなく、ページ単位で扱います。ページサイズは64KiBのため、実際のサイズはページ数に65536(16 × 1024)をかけた値になります。

JavaScript API

ここまでWASM自体について説明してきましたが、最後にJavaScriptとの連携について説明します。今の所、WASMはJavaScript APIを利用して、明示的にコンパイルし、インスタンス化する必要があります。手順としては次の通りになります：

1. WASMファイルをダウンロードし、TypedArrayに変換
2. WASMモジュールがインポートする関数を用意する
3. 1と2を利用して、WASMモジュールをインスタンス化する

この手順をコード化すると次のようになります。下記の例では、上述したsample.wasmをインスタンス化し、そのモジュールに定義されているaddSomeを呼び出しています。

const importObject = {
  hello: () => console.log("Hello"),
  world: () => console.log("world")
};

fetch("sample.wasm").then(response => response.arrayBuffer())
  .then(buffer => WebAssembly.instantiate(buffer, importObject))
  .then(({module, instance}) => console.log(instance.exports.addSome(1)));

WebAssembly.instantiateが、モジュールのインスタンス化を行う関数になります。第1引数にWASMファイルがロードされたArrayBuffer演算を、第2引数にはモジュールがインポートする関数や値をまとめたオブジェクトを指定します。上の例ではhelloとworldという2つの関数がsample.wasm内にインポートされます（実際にインポートされるかどうかは、importセクションの記述によります）。

インスタンス化されたされたWASMモジュールは、JavaScriptのモジュールのように扱えます。変数へ代入することもできますが、属性を追加することはできません。モジュールインスタンスはexportsという名前の属性を持っており、その値のオブジェクトのメンバーとしてエキスポートされた関数を参照できます。

なおWebAssembly.instantiateの呼び出し時には、ダウンロードしたWASMモジュールの妥当性や、ファイルフォーマットの検証が行われます。これらに失敗した場合は、WebAssembly.CompileErrorが送出されます。これをcatchすることでコンパイルエラーを検出できます。

まとめ

これまで4回にわたってポータビリティや後方互換性との両立を図りつつ、ネイティブに近いスピードでの動作を実現するために行わている様々な工夫の一端を見てきました。

asm.jsとWebAssemblyによってネイティブに近い動作スピードは実現されつつあり、それを作成するツールもEmscriptenを筆頭に充実しつつあります。いずれフロント部分のほとんどがCやC++で実装されたWebアプリも登場するでしょう。

ではJavaScriptの役割は終わってしまったのでしょうか。

そんなことはありません。まずWebアプリの大半はasm.js/WebAssemblyで提供される計算性能を必要としていません。必要したとしても、大半のコードの価値はスピードよりもUXによって提供されるでしょう。JavaScriptの大きな特徴は、その生産性の高さです。高速に動作することよりも、高速に開発のイテレーションをまわ回して行く方が重要とされる局面は多くあるでしょう。そんな時にJavaScriptの生産性の高さが生きるでしょう。

ただasm.js/WASMがWebに大きな可能性を加えるものになるのは確かです。既存のWeb開発では難しかったインタラクションの多い3Dグラフィクスを扱うアプリも、UnityやUnrealEngine、Stingrayといったasm.js/WebAssemblyに対応したゲームエンジンを利用することで、効率的に開発できるようになります。工数の関係で諦めていたような表現やアプリの提案も、これらのツールを採用することで可能になる場合もあるでしょう。この連載で扱ってきた技術が、みなさまのWeb開発の選択肢に加わり、その結果Webが豊かになれば幸いです。

2016年10月のブラウザ関連ニュースは、10月12日にリリースされたChrome 54の追加機能からCustom Elements v1、DevToolsのCPU Throttling、WebAssemblyについて紹介します。

Chrome 54リリース

10月12日に、Chrome 54がリリースされました。追加された機能のまとめは、ベータ版時点で公開されたポストが詳しいです。

• Google Developers Japan: Chrome 54 ベータ版：Custom Elements V1、BroadcastChannel、メディア プラットフォームの強化

以下、気になったものを取り上げます。

Custom Elements v1

54で実装された大きな機能としては、Custom Elements v1でしょう。Shadow DOM v1のときと同じように、Custom Elements仕様もベンダー間の合意をとりつけ前進した新しい仕様を「v1」と呼んでいます。現在Safariも実装を進めており、近くリリースされる新しいTechnology Previewで有効になるはずです。

Custom Elements v1での大きな変更点は、ES 2015のクラス構文を使いカスタム要素を定義するようになったことです。たとえば、hx-element というカスタム要素を定義する際には以下のようなコードで要素のコンストラクタを定義し、そのコンストラクタをもとに hx-element という要素名に登録します。

// カスタム要素のコンストラクタ
class HXElementCtor extends HTMLElement {
  // 要素が作成された段階に実行されるコールバック
  constructor () {
    super()
    // ...
  }
  // 要素がドキュメントに突っ込まれたとき
  connectedCallback () {
    // ...
  }
  // ...
}
// hx-element という名前でカスタム要素を登録
window.customElements.define('hx-element', HXElementCtor)

カスタム要素のコンストラクタには、「要素が作成された」「要素がドキュメントに追加された」「属性が変更された」などの状態に応じてコードを実行するためのライフサイクルコールバックと呼ばれる関数を記述します。くわしくはチュートリアルがWeb Fundamentalsで公開されているので、そちらをどうぞ。

• Custom Elements v1: Reusable Web Components

DevToolsのCPU Throttling

DevToolsでは、CPU Throttlingがサポートされました。CPUの速度を制限し、スマートフォンなどのパワフルでない環境での処理を模した状態でタイムラインを取得できます。

HTML5 Experts.jpのトップページで、タイムラインを録って比較してみました。

CPU Throttlingなしのオーバービュー

通常状態では、レイアウト関連処理（紫色）が3回、JavaScript関連処理（黄色）が3回、描画関連処理が1回、チャートの上端に達しています。この状態でもCPUをけっこう専有しているようです。

“5x slowdown”を指定し制限し読み込んだもの

CPU Throttolingで5分の1に制限したものではまず、ページ読み込みに倍近くの時間がかかっています。また、レイアウト関連処理やJavaScriptの処理時間が大幅に伸びており、別れていた山がくっついてしまっています。

と、このような感じでCPUの性能がレンダリングに及ぼす影響を確かめられます。気をつけないといけないのが、“2x slowdown”といったように使っているコンピューターのCPUをもとにした制限になってることです。ですので特定のプロセッサをエミュレートできるわけではありません。Network Throttlingよりも「あくまで目安」度合いが高そうです。

WebAssemblyがさらに進捗、ブラウザプレビュー段階に

10月31日に、WebAssemblyがブラウザプレビュー段階に入ったと、Mozilla, Google, Microsoftが発表しました。

• WebAssembly Browser Preview ★ Mozilla Hacks – the Web developer blog
• V8 JavaScript Engine: WebAssembly Browser Preview
• A peek into the WebAssembly Browser Preview | Microsoft Edge Dev Blog

WebAssemblyは3月に各ブラウザで試験実装が入ったのですが、今回はWebAssemblyのバイナリフォーマットがリリース候補段階になったこと、それにSpiderMonkeyとV8のナイトリービルド、Chakraの開発版が互換性のある形で対応した旨が発表されました。バイナリフォーマットがほぼ固まったため、このブラウザプレビュー段階では幅広いフィードバックを集めたいとのことです。

今後のWebAssemblyですが、公開されているロードマップによると、解決に時間のかかる問題が見つからなければ2017年第1四半期にはバイナリフォーマットの初期バージョンが策定完了するとのこと。そしてその時点で、ブラウザの実装をデフォルトで有効にするようです。Firefoxは52での有効化を試みているそうです。

なお、発表には加わっていないものの、WebKitでもJavaScriptCoreに実装中です。主要なエンジンすべてで実装されるので、ゲームや計算コストの大きなアプリケーションをWebに持ち込むのがさらに容易になりそうですね。

Webブラウザの上で動作するアプリを書くための言語、といえば何が想起されるでしょうか。Flash、Sliverlight、Java、さまざまな言語が利用されてきましたが、やはり今のメインストリームはJavaScriptでしょう。

JavaScriptはさまざまな言語の特徴を併せ持つ動的言語で、Web技術の発展とAPIの整備の結果、Virtual Reality(VR)や画像認識、DAW(Desktop Audio Workstation)といった、少し前まではネイティブでの実装しかありえなかった種類のアプリケーションもWebブラウザをランタイムとするJavaScripで実装されるようになってきました。

そのようなアプリの代表例がゲームでしょう。少し前までのブラウザゲームといえば、リロードを繰り返すタイプのゲームか、Flashゲーム、パズルなどの簡単なものが大半を占めていたように思います。Canvasを利用して実装されたスーパマリオやNESエミュレータなどもありましたが、いずれも実験的なものであり、また20年以上前のハードウェアで快適に動くゲームだったことを考えると、CPU時間を大量に消費する「重厚」なものではありませんでした。

しかし最近は重厚なゲームの開発も行われ始めています。この嚆矢はBananaBreadでしょう。これはMozillaのエンジニアチームが開発した複数同時対戦可能なFPS(First Person Shooting)です。このようなゲームの実現が可能になったのは、WebGL、Web Workers、Web Audio API、Gamepad API、IndexedDBなどに代表されるAPIの充実もありますが、既存のJavaScriptエンジンではなしえなかった高速の演算を可能にする、低水準言語の整備のおかげでもあります。

この連載は4回にわたって、Webブラウザ上で動作する低水準言語であるasm.jsと、（いまのところ）そのバイナリフォーマットであるWebAssemblyについて、その設計と仕様、そして開発環境を紹介します。

低水準言語asm.js

asm.jsはMozillaが研究開発したJavaScriptのサブセットで、2013年に発表されました。現在はFirefoxとGoogle Chromeによって実装が行われ、EdgeやSafariも対応を表明しています。その特徴はなんといっても動作の高速さです。次のグラフはasm.js発表時に公開されたベンチマークの結果で、棒グラフが短ければ短いほど、処理が高速であることを意味しています。このグラフによると、ベンチマークの種類にも依存しますが、概ねCやC++によるネイティブ実装の半分程度のスピードで動作していることがわかります。

https://kripken.github.io/mloc_emscripten_talk/cppcon.html#/24より引用

このような高速に動作を可能にしているのは、事前コンパイルと呼ばれる技術です。AOT(Ahead of Time)とも呼ばれるこの技術を利用すると、プログラムはその実行直前にコンパイルが行われ、ネイティブコードへと変換されます。ブラウザは内蔵するコンパイラでasm.jsで書かれたコードをネイティブコードに変換し、ネイティブコードを実行することで、この高速性能を実現しているのです。

事前コンパイルを可能とするために、asm.jsで書かれたプログラムは以下にあげる特徴を持っています。

• 変数や式、関数の型が静的解析可能である
• 数値計算に特化している
• 作成や属性の参照、メソッド呼出といったオブジェクトに関する操作ができない
• 利用できるコレクション型はTyped Arrayのみである

一般のJavaScriptやAngular、RxJSといったモダンなフレームワークの提供するDSL(Domain Specific Language)に 慣れた身からすれば、機能が制限され、「低水準な」印象が拭えません。2013年にもなって、なぜ、このような制約の強い言語が開発されたのでしょうか。もちろんJavaScript発展の文脈に基づく、実用上の要求があるためです。それを理解するに、まずJavaScriptの動作について簡単に（かつ大雑把に）振り返ることとしましょう。

JavaScriptが動く仕組み

プログラミング言語は「コンパイラ型」と「インタプリタ型」の2つに分けることができます。C言語やC++は前者の典型で、 後者の典型はPerlやRuby、Pythonでしょう。JavaScriptも後者に分けられます。インタプリタ型の特徴は、あるプログラムの動作に「インタプリタ」と呼ばれる別のプログラムが必要である点です。SpiderMonkey(Firefox)、Chakra(Edge)、V8(Chrome / Node.js)はJavaScript向けのインタプリタとして有名でしょう。

インタプリタは、文字列を解釈してプログラムとしての文法的構造を取得します。この過程を字句解析・構文解析と呼び、 結果得られた文法的な構造のことを抽象構文木(AST: Abstract Sytactic Tree)と呼びます。例えばa=1+2*3; のASTは次のようになります。

素朴なインタプリタは、この抽象構文木を枝の方から実行していきます。先ほどの例だと、まず2 * 3の計算を行い、 その結果である6で2 * 3に相当する部分木を置き換えます。その後1 + 6を計算し、最後にa = 6を計算します。この場合では、*や+、=といった演算子や標準ライブラリ中の関数などは、インタプリタ中の関数として実装され、それらをASTを解釈する巨大なswitch文の中から呼び出してプログラムは実行されます。そしてこの巨大なswitch文は、プログラムの評価が終わるまで繰り返し実行されます。

仮想マシンとバイトコード

このようなインタプリタはシンプルで理解しやすいのですが、変数のスコープや返り値の受け渡しの実現が困難になりがちです。そこで多くのインタプリタはASTをバイトコードに変換して実行します。バイトコードは単なるASTのバイナリ表現ではなく、インタプリタによって実装された仮想的なハードウェア（仮想マシン）を動かすマシンコード、つまり仮想的なネイティブコードとなっています。例えば(a,b,c)=>a+b*cという関数は、SpiderMonkeyによって次のようなバイトコードの列に変換されます。

getarg 0
getarg 1
getarg 2
mul
add
return
retrval

getargやmul、addなどはSpiderMonkeyの実装している仮想マシンの持つ命令です。仮想マシンには計算に使う値をスタックに保存するスタックマシンと、レジスタに配置するレジスタマシンとがありますが、SpiderMonkeyはスタックマシンを採用しており、変数への代入や、実引数の参照はスタックに対する操作として実現されています。

なおSpiderMonkeyの提供するバイトコードはこちらのサイトで一覧できます。

バイトコードに変わったとはいえ、実行のモデルは変わりません。バイトコードを1つずつとってきては、バイトコードを解釈する巨大なswitch文を通じて、各命令を実装する関数が呼ばれます。これがプログラムの実行が終了するまで繰り返されます。

型情報の不足

どうせネイティブコードを出力するなら、仮想マシンのネイティブコードではなく、実マシンのネイティブコードを出力すればいいのに。そう思われるのも当然ですが、出力しない、もしくはできないのにも理由があります。それらの中で大きなものの1つが、型情報の不足です。

function wrap(value){
  return {value: value};
}

var b1 = wrap(1);
var b2 = wrap(2);
var result = b1.value + b2.value;

resultにはどういう種類のデータが入るでしょうか？数値とすぐわかる方も多いとは思います。ではなぜ数値だとわかったのでしょうか？頭の中で上記のプログラムを実行した結果、b1.valueとb2.valueの値が両方とも数値であることがわかり、 数値同士の加算は数値になることから、resultには数値が代入されると結論づけたのではないでしょうか。

では、このwrapの返り値のvalue属性には常に数値が代入されているでしょうか？wrapの引数は数値でなければならない、とはどこにも書いてありません。そのため、次のような呼び出しも可能です。

var b3 = wrap("abcd");
var b4 = wrap({id: 1234});
var b5 = wrap(null);
var b6 = wrap(undefined);

b3,b4,5,b6それぞれのvalue属性の型も、string,object,null,undefinedと異なる型になっています。 このようにJavaScriptのプログラムは実行するまで変数や演算結果の型がわからないことが多々あります。 これはプログラムの中に型の情報が含まれていないためです。 もし型情報が含まれていれば、実行しなくても変数や演算の結果の型を決められます。 型付けの強い言語の代表例であるRustを使って同様のプログラムを記述すると、次のようになります：

struct Box<T>{value: T}
fn wrap<T>(value:T) -> Box<T>{
  Box{value: value}
}
fn main() {
  let b1 = wrap(1);
  let b2 = wrap(2);
  let result = b1.value + b2.value;
  println!("result = {}", result);
}

このプログラムでは実行しなくても、resultの型はintであることがわかります。resultの宣言からは、型宣言を省略してあります。それでもRustの処理系は他の情報から型を決定して型を決めています。それはBoxとwrapの宣言についている型情報、そしてwrapを呼び出した際の引数から、b1.valueとb2.valueの型が決定できるためです。

さて型がわからないことが、ネイティブコードの出力にどのような影響を与えるのでしょうか。それは端的にいえば、出力するネイティブコードが冗長になるということです。例えばIntelのCPUの場合、加算だけでも20種類以上の命令があります。 これはデータ型と、データの保存場所によって使用する命令が異なるからです。データ型が適切に決定できているなら、使用する命令を1つに絞ることができます。

しかしデータ型を適切に決定できない場合、その可能性を1つずつチェックし、そのチェックした結果に合わせて使用する命令を決めるといったようなコードを出力せざるをえません。その結果コード全体は冗長になり、スピードもあまりでなくなってしまいます。ネイティブコードの出力にも時間がかかるため、その時間に見合った効果が得にくくなってしまいます。

JITコンパイル

ネイティブコードを出力したいが、ソースコードには型に関する情報がない。この状況を打破するために利用されている技術がJIT(Just in Time)コンパイルです。これはJavaScriptをいきなり高速に動かすためのネイティブコードに変換せず、しばらくインタプリタなどで動作させます。変数に代入される値を観察して、その型に関する統計情報を集めます。

この統計情報と、1つの変数には同じ種類のデータが代入される傾向にある、というヒューリスティックを利用してその変数の型を推定していきます。推定がある程度できた時点で、該当するコードからネイティブコードを出力します。このようにプログラムを動かしながら、必要に応じてネイティブコードへと出力するのがJITです。

SpiderMonkeyではJITは2段階に分かれています。まずはnullチェックなどを含んだ冗長なコードを出力するベースラインJIT を行います。その状態でしばらく動作させ、型情報の統計を取得します。ある程度の型情報が集まったところで、その情報を元により効率の良いコンパイルを行います。

図中のIon compileがそれです。

asm.js AOT compilation and startup performanceより引用

型情報が集まったかどうかは実行回数によって決まっているようです。コードをざっと眺めた限り、10回程度繰り返し実行されるかどうかが、コンパイルを行うかどうかの判断の目安になっているようです。

上図のように、コンパイルされたコードは常に維持されるわけではありません。ときにはbail、つまりコンパイル結果を捨てて、もう一度型の推定からやり直します。これはJavaScriptの関数呼び出しに型による制約がかけられず、推定がヒューリスティックによるもののため、仕方がないことです。例えば、次のような呼び出しが行われた場合twiceのコンパイル結果は捨てられてしまいます。

function twice(a){
  return a + a;
}
var array = [0, 1, 2, 3, ... , 100000].map(twice);
var str = twice("こんにちは");

map関数からの呼び出しによってtwiceは10000回実行されます。この途中で（正確には、行われるかどうかは処理系に依存するのですが）、twiceはnumberを引数にとり、numberを返す関数としてJITコンパイルされます。しかし次の行の引数に文字列が与えられた呼び出しによって、その結果は捨てられてしまいます。捨てないとこの処理が行えないためです。

TypeScriptのような型制約があればこのようなことが起きないのですが、残念ながらJavaScriptにはそれがありません。 そのため時には時間をかけて行ったコンパイル結果を捨て、低速に動くことを余儀なくされてしまいます。

まとめ

JITを利用することで、よく利用されるコードを高速に動作させられるようになりました。 それでも次のような問題が残っています。

1. よく使うコードしかネイティブコードにならない
2. 高速に動作するようになるまでにはリードタイムが必要
3. 型の推定には失敗することがある

重厚なゲームのようなアプリケーションの場合、2や3の問題は致命的なものとなりえます。

FPS(First Person Shooting)で対戦している場合を想像してみてください。対戦の最初はコンパイルがすんでいないため、ゲームはもっさりと動作しています。これではゲームになりません。しばらくは自分の陣地でゆっくりしてコンパイルが終わるのを待ちましょう。コンパイルが終わってFPS(Frame Per Second)が出てきました。ようやく本当のゲーム開始です。

そこで相手の攻撃を読み、侵攻して、草むらに潜み、相手がくるの待ち受けます。いざ相手へ攻撃をかけようとした瞬間、3に起因するコードの再コンパイルが発生し、画面がプチフリーズ。ゲームに復帰したら、目の前には銃を構える敵が…

こういう状況を避けるためにも、上述したような問題に対する回避策が求められました。それがAOTとasm.jsでした。AOTによって1,2の問題を回避し、その実現と3の回避のために型情報のふくまれたasm.jsが導入されることとなりました。

次回はasm.jsがどのように型情報を与えていくのか、型アノテーションを中心に解説します。

2016年3月のブラウザニュースは、Chrome 49の新機能、Firefox 45とinnerText、WebAssembly実装のプレビュー、Edgeの拡張機能、Safari 9.1リリースなどについて紹介します。

Chrome 49でCSS Variablesサポート

3月2日に、Chrome 49がリリースされました。新機能はベータ版がリリースされた際にまとめられています。また、同じエンジンを搭載するOpera 36のリリース記事でも紹介されています。

• Google Developers Japan: Chrome 49 ベータ版: CSS Custom Properties、Background Sync、ES2015 の新機能など
• Dev.Opera — What’s new in Chromium 49 and Opera 36

注目はCSS Custom Properties（通称Variables）でしょうか。プリプロセッサやポストプロセッサが持つ変数とちがい、ちゃんと継承されるというのが特徴です。これを利用し、Jake Archibaldが、display の値をカスタムプロパティで定義し、外部CSSが読み込まれた際に block に書きかえさせ段階的にCSSを読み込ませるというアイデアを披露しています。

• Control CSS loading with custom properties – JakeArchibald.com

V8も更新され、ES2015のdestructuringとdefault parametersが使えるようになりました。また、Promiseのrejectionを検知する unhandledrejection イベントおよび rejectionhandled イベントもサポートされました。

Firefox 45と innerText

3月8日に、Firefox 45がリリースされました。

• Firefox 45.0 リリースノート

ES 2015のClass構文が有効にされています。うれしいですね。

他には、他ブラウザとの互換性のため innerText プロパティがサポートされました。要素内の「レンダリングされたテキスト」を取得するプロパティです。

この「レンダリング」というのが曲者です。要素内の文字列を取得するには textContent プロパティがありますが、こちらは「DOM要素内のテキスト」なので display: none などが指定された要素内のテキストももちろん返ります。いっぽう、 innerText はレンダリング結果を考慮するため display: none な要素内のテキストは結果に入りません。

innerText はブラウザ拡張などで外部サイトをいじったりするときには便利だったりしますが、レイアウトを行うためパフォーマンスに影響があります。単純に要素のテキストを取得したい場合は textContent を使いましょう。

WebAssembly実装のプレビュー

3月15日に、Mozilla、Google、Microsoftが、WebAssemblyの実験的なサポート状況について公開しました。WebAssemblyの試験実装は昨年から進められていますが、3ブラウザで相互運用可能な状態になったとのことです。

• WebAssembly が 1 つのマイルストーンを達成しました： 複数ブラウザによる実験的なサポートがはじまりました | Mozilla Japan ブログ
• Google Developers Japan: V8 で WebAssembly を試験運用開始
• Previewing WebAssembly experiments in Microsoft Edge | Microsoft Edge Dev Blog

FirefoxとChromeについては、NightlyやCanaryでフラグを有効にすると試せます。

WebAssemblyについては、中心人物のひとり、MozillaのLuke Wagner氏へのインタビューが面白いです（インタビューの場に混ぜていただきました）。インタビューが行われたMozillaのView Source Conferenceでのセッション資料も参考になります。

• ハイパフォーマンスなWebを実現するasm.js／WebAssemblyとは――Mozillaのルーク・ワグナー氏に聞く：CodeZine（コードジン）
• WebAssembly

また、先日ポッドキャストでのインタビューも行われています。こちらもあわせてどうぞ。

• TechCast #94 – Luke Wagner on WebAssembly

Edgeの拡張がプレビュー版に

Microsoft Edgeの拡張機能が、ついにプレビュー版に入りました。

• Microsoft Edge extensions now available to preview | Microsoft Edge Dev Blog

拡張は正式リリース時にはWindows Storeから追加できるようになるそうです。

拡張の構造はChrome拡張互換のAPIですが、現時点では本家やMozillaのWebExtensionsと少し違い、chrome オブジェクトが browser オブジェクトに変わっているそうです。ちょっと面倒ですね。

• Micorosoft Edge(プレビュー)の拡張を作ってみる – ぷろじぇくと、みすじら。
• Micorosoft Edge(プレビュー)の拡張について調べる、デバッグする方法 – ぷろじぇくと、みすじら。

サポート予定のAPIはロードマップが公開されています。Firefox, Edge, Chromium系で（だいたい）同じコードで拡張が動くようになるのでやる気がでますね。

Safari 9.1リリース、さらにTechnology Preview登場

3月21日に、OS X 10.11.4とiOS 9.3がアップデートされ、Safari 9.1がリリースとなりました。WebKitのブログで新しい機能が紹介されています。

• New Web Features in Safari

新しい機能は内部的に利用されてもいるようで、追加されたCSS Custom Propertiesを使い、Web Inspectorのコードをシンプルにした話もエントリとして公開されています。

• CSS Variables in WebKit

さらに、3月30日、Safari Technology Previewという開発者向けのビルドが公開されました。

• Introducing Safari Technology Preview

Safari Technology Previewはリリース版のSafariよりも新しいWebKitを搭載したビルドで、2週間にいちど更新されます。最初のビルドではES2015のArrow Functionsやイテレータ、Web標準ではShadow DOM (v1)などが使えるようになっています。

なお、レンダリングエンジンのWebKitはこれまでもナイトリービルドを提供していましたが、Safari Technology Previewは独立したUIを持ち、App Storeから更新されるといった違いがあります。

現段階でiOS版のプレビューは提供されていませんが、多くの人がそれを望んでるだろうとは認識しているとのこと。こちらのほうが出ると嬉しいので、要望をあげましょう。