あけましておめでとうございます，@1000chこと泉水翔吾です。2018年に続いて，2019年のWeb標準技術の動向も予測していきます。

Microsoft EdgeへのChromiumプロジェクトの採用

2015年7月にMicrosoft Edge（以下，Edge）が発表されてから早3年が経ちます。Microsoftは，古くなったアーキテクチャの刷新とWeb標準技術へより高速に追従することをゴールに，レンダリングエンジンEdgeHTMLの開発をゼロベースで進めてきました。

ところが2018年12月，MicrosoftはEdgeのレンダリングエンジンにChromiumプロジェクトを採用することを発表しました。公式ブログの記事には「Chromiumというオープンソースソフトウェアへのコラボレーションを通じて，Webプラットフォームをより良いものにしていく」と，あります。この決定に至るまでにどんな経緯があったかは知る由もありませんが，EdgeHTMLの開発が断念されてしまったことは事実です。

Operaも2013年にレンダリングエンジンPrestoの開発を中止し，Chromiumを採用しています。それ以来，主要なブラウザエンジンは，ChromeとOperaに採用されているChromium，FirefoxのGecko，SafariのWebKit，そしてEdgeのEdgeHTMLという状況でした。今回EdgeがChromiumを採用することで，現存する主要なブラウザエンジンは，Chromium，Gecko，WebKitの3つに絞られることになります。

今やWeb標準技術は非常に大きな仕様です。大きくなりすぎたが故に，ブラウザをゼロから作るのは現実的に難しい状況にあるでしょう。Webプラットフォームを支えるブラウザは，これらの巨大な仕様を実装し続けなくてはなりません。ブラウザを作ることへの投資とそこから得られる利益などプロプライエタリな側面を含めて様々な理由があるとは思いますが，長らくブラウザを開発しインターネットを支えてきたMicrosoftという巨大な企業がこの選択に至ったのは，感慨深いものがあります。

EdgeHTMLというレンダリングエンジンが失われることで，Webの多様性が失われる懸念もあります。現在，W3CにおけるWeb技術の標準化プロセスではドラフトの提案に始まり，2つのブラウザによる参考実装が行われ，初めて仕様として勧告されます。例えば過去にGoogleから提案されたHTML Importsは，先行してChromiumが実装しましたが，FirefoxやSafariが反対し実装を行わなかったため，仕様として見送られました。このように，各ブラウザベンダーは一定の影響力を持っていますが，EdgeがChromiumを採用した今，Chromiumの影響力はより強まっていくでしょう。実際，このEdgeの発表に寄せて，MozillaもWebの中立性についての声明を出しています。

みんなで決めた仕様に沿って，ブラウザやWebページが実装されて成り立っていることが，Webの良さであり，凄さでもあります。EdgeにChromiumを採用した今，MicrosoftがGoogleだけでなくWebプラットフォームに対してどのように関わっていくか，注目したいところです。

Low Level APIとLayered APIs

Low Level APIを定義することで，開発者で拡張できるWebの世界を唱えたThe Extensible Web Manifestoの登場以降，Web標準技術はより低レイヤなAPIの策定が進んできました。例えば，昨年の記事で紹介している技術でいえば，Web ComponentsはCustom ElementsやShadow DOMなどの仕様からなる技術ですし，Service Workerについてもキャッシュの機能を実現するにはCache APIやFetch APIを使って実装する必要があります。Extensible Webが目指した「拡張できるWebの世界」は，実現されつつあると言えるでしょう。

Low Level APIの策定が進む一方で，High Level APIの需要も見直されてきました。Low Level APIを組み合わせれば確かに大抵の需要は開発者自身で満たせますが，それはページロード時に読み込むJavaScriptファイルのサイズの増加も招きます。これはHigh Level APIが提供されることで解決されるはずです。

だからといって闇雲にHigh Level APIを定義していくと，仕様を標準化してブラウザに実装し，フィードバックを経て，開発者に受け入れられなければ非推奨化する……という，標準化プロセスにこれまでと同じ膨大なコストを払うことになります。そこで，標準化したいHigh Level APIはLow Level APIを前提としようという動きがLayered APIsです。

• Layered Web APIs Design Doc - Google ドキュメント
• Layered APIs: an overview and update - Google スライド
• layered-apis/README.md at master · drufball/layered-apis

Layered APIsに沿うことで，提案するHigh Level APIに対してLow Level APIを使ったポリフィルが提供可能になるとともに，より高い需要を満たすAPIを低いコストで標準化できることが期待されます。Layered APIsには，策定候補となるAPIとポリフィルをシームレスに読み込むためのES Modulesの拡張文法も含まれます。こちらもまだ実験段階ですが，実現すれば以下のような記法で，ブラウザ実装が存在する場合はネイティブAPIを，存在しない場合はポリフィルを読み込めるようになるでしょう。

import { ProposedAPI } from 'std:proposed-api|https://cdn.example.com/proposed-api-polyfill.js';

Web標準技術がLayered APIsに沿って標準化されるようになれば，Low Level APIを使っていくだけでなく，便利なHigh Level APIを開発者自身で生み出し易くなるでしょうし，自らで提案していくことの敷居も下がっていきそうです。