Chrome Dev Summit 2017まとめ

10月23,24日で行われたChrome Dev Summit
2017のまとめ記事を書こうと動画を見始めたのですがすでにまとめ記事があったので、翻訳することにしました。

I Watched All of the Chrome Dev Summit 2017 Videos So You Don’t Have To

新しい発表はあまりありませんでしたが、PWAの啓蒙はたっぷりのイベントでした。

Dan FabulichはRedfinのプリンシパルエンジニアです。（採用中です！）

Chrome Dev Summit 2017の動画はすべてyoutubeから見ることができます。
10時間の動画。

まとめ：Googleは開発者がPWAを作り、JavaScriptファイルサイズを縮小して、Webコンポーネントを使い、autofill(自動入力)を使うことを望んでいます。
また支払い、認証、Android Trusted Web Activitiesの信頼できるウェブアクティビティ、Chrome Dev Tools、Chrome User Experience Reportあたりの機能だけですが発表もありました。

Redditのリンク

 Hacker Newsのリンク

CDS (Chrome Dev Summit)では、通常Googleは次の3つのことを行います。

人々に使ってほしいWebテクノロジーを宣伝する
新しいものを発表するか再発表する（以前発表されたものの焼き直しも少なくない）
Web開発者のための実用的なアドバイスを共有

「アナウンス」とはいえ、実際にすでに宣伝された既存の技術の再発表であることも多いです。
時にはGoogleは実用的ではないかまだ実用的ではないWeb技術を推すこともあります。たとえば最新のベータ版だったりChromeの最新版だけで動くものだけだったり。

Googleがあなたにして欲しいこと

Progressive Web Appを開発する。具体的にはService Workerを使用して、アプリがオフラインのときでも使えるようにします。Service WorkerはiOSでは動作しないため、これはGoogleにとっては大変な売りですが、Appleはついに数ヶ月前開発を開始しました。 iOS 12で利用できるようになること希望。
ウェブサイト内のJavaScriptのサイズを大幅に削減する。 Googleは$100ドル以下の低消費電力で安価なAndroid携帯端末でも5秒以内に使えるようになることをひとつの目標として勧めています。裕福な西側諸国のWeb開発者は、パフォーマンス特性がはるかに優れたiPhoneまたはハイエンドのAndroidデバイスを使用する傾向があります。（iPhone 8には8MBのL2 CPUキャッシュが搭載されていますが、多くのハイエンドのAndroid携帯には通常L2キャッシュがありません）。Googleは安価なスマホでは1MB以下のminified ungzipped Javascriptか150KB以下のgzippedしか扱えないと言っています。「新興市場」の国向けにサービスを提供する予定がない場合は、ほとんどのWeb開発者にこれらの制限を受け入れてもらうのは難しいです。 Googleの推奨目標を達成するには、しばしば、面白いJSフレームワークを破棄して書き直しが必要です。
Web Componentを使用する。（最近はCustom ElementとShadow DOMだけを指し、HTMLのインポートはあきらめているようです）。特にGoogleは Polymer推しです。問題はWeb Component APIが、特にReactと比較して、直接使用するのが実際にはかなりめんどくさいことです。それが他のフレームワークと比べてPolymerがいまいち人気の無い理由です。 Svelte、 Skate 、 StencilのようなWC(Web Component)ベースの他のフレームワークは、WCを抽象化しコンパイル対象として扱います。（WCには別の大きな問題があります：Shadow DOMのためのサーバーサイドレンダリングの方法がありません。またクライアント側のWCをサーバーレンダリングされたWCでない出力からデータを注入する効率的な方法がありません）。GoogleはWCを推奨目標を達成するための重要な方法として位置づけ、WCを使うことですることでJavascriptで再作成を避けることができ、JavaScriptのバイトを大幅に節約することができると言っています。
autofill(自動入力)をサポートするようにフォームを作ります。特にログインフォームやチェックアウトフォームに適しています。相当なトラフィックのあるECサイトですらautofillを完全に無視してのにはショックを受けています。これはモバイルブラウザにとって特に重要なことです。近年、ChromeにはCredential Management APIやPayment Request APIなどの新しい自動入力機能が追加されていますが、おそらくブラウザのサポートが悪いため、各サイトでの採用が遅れています。

Googleが発表したもの

Payments(支払い)：既にあるものと似ていますが、少し異なります

Google Payment APIの発表がありました。 Google
CheckoutをGoogleウォレットに置き換えてAndroid
Payを入れ替えただけですが、ドキュメントには「Googleで最新の支払い方法」と大胆に書かれています。

Google Payment APIはAndroidのChromeでのみ動作します。
「標準」ではあるがほとんどサポートされていない Payment
Request APIと統合されています。いまのところはAndroid Chrome内のAndroid Payだけが動くといったところです。
そのうち他のブラウザにもサポートが広がることを願います。

これまでAndroidのみに制限されていたPayment Request APIがChromeのすべてのプラットフォームで利用できるようになる発表もありました。

Authentication (認証)：既にあるものと似ていますが、少し異なります

「Automatic Sign In (自動サインイン)」と「One-tap Sign Up
(ワンタップサインアップ)」の
2つの機能が発表されました。

もちろん以前からGoogle Sign-Inを使ってGoogleにサインイン/サインアップすることができました。（「Google
Plusでログイン」と呼ばれていた時期もあります）。しかし今回のバージョンでは、アニメーションのトーストが画面の下部に表示され、ユーザーがGoogleにログインできるようになりました。

新しい「ワンタップ」フローはCredential Management API
にpolyfillを追加することで使えるようになるためiOSでも動作します。いいですね。

Trusted Web Activities (信頼できるWebアクティビティ)：AndroidアプリのPWAタブ

Trusted Web
ActivitiesはURLバーを表示せずにAndroidアプリ内でChromeカスタムタブを起動する方法です。
Androidアプリで自分のウェブサイトを画面にし、Google
PlayストアでAndroidアプリとしてPWAを簡単にパッケージ化できるように設計されています。

Chrome Dev Toolsの諸々な改良

Dev Toolsのほとんどの機能と同様文章にするのは難しいです。
動画の方がよく分かると思います。
CSS Grid Layoutの検査、「ローカルオーバーライド」（Dev
Toolsで使えるGreasemonkeyの「ユーザースクリプト」）、新しいリアルタイムのPerformance
Monitorパフォーマンスモニタ、類似のイベントのフィルタリングとグループ化のできるコンソールログの強化、Applicationタブ内のPWA対応の強化などがデモされました。

Dev
Toolsの＃1バグをステージ上で修正済みとしてマークし、複数のクライアントがリモートデバッグ中にChrome
Dev Toolsを使用できるようにしました。

Chromeユーザーエクスペリエンスレポート

Chromeユーザーエクスペリエンスレポートは、上位1,000のウェブサイトの実際のユーザーモニタリングパフォーマンスデータをクエリできるBigQueryのデータセットです。
誰がこれを何のために使うのかは全く想像ができませんが、誰か面白い使い方を考えるんでしょう。

プレゼンの構成とか

今年のプレゼンは奇妙に分断されていると感じました。プレゼンの内容にかかわらずすべてのプレゼンは30分で終わりました。
そんなこともありあまり関係無い話題にもかかわらず2,3人のスピーカーが30分をを共有していたようなプレゼンも多くありました。

スピーカーが1人だけでも、特定のテーマそっちのけでカバーしなければならないもののリストをひたすら話すだけというものもありました。こんなプレゼンだとテーマが分かりにくくなります。

とはいえ自分なりにまとめてみます。

Keynote（Ben GalbraithとDion Almaer）：リスト消化型プレゼン。 HTTPS、自動入力、認証、WebメディアAPI、信頼済みWebアクティビティ、Webコンポーネント、CSSグリッド、ES6 + ES2016、WASM、MDN Web Docs、開発ツールなど。
The New Bar for Web Experiences （Thao TranとChris Wilson）：Keynoteの延長。これもリスト消化型プレゼン。「バー」としてService Workerを使うように別の言葉で甘い言葉をささやくことは、なかなか開発者に浸透しないこのテクノロジーを使ってもらうようにする試みです。
Integrating with Operating Systems （Owen Campbell-Moore）：Owenにはたくさんのアイデアがありました。新しい「ホーム画面に追加」（A2HS）モーダルフロー、信頼できるWebアクティビティ、Android用のFirefoxとSamsung Internet BrowserでPWAがサポートされるようになりました。マイクロソフトでは、WindowsストアでPWAをサポート開始。もっとあります。ウェブメディアAPI、Service Workerのバックグラウンド同期APIおよび通知API Web共有API。支払いリクエストAPIとその悪い双子のGoogleペイメントAPI。新しいワンタップサインアップAPIと自動サインインAPI。そして「one more thing」。2018年にはChromeのデスクトップがPWAをサポートします。
Kickstarting Your Journey to Progressive Web Apps（Ewa Gasperowicz）：Lighthouseなどの分析ツールを使用して改善すべき点を決め、PWAの前提条件に優先順位を付ける（画像の最適化、ブラウザのキャッシュ、コード分割、HTTPSの使用など）この後実装して再分析。
Fast by Default: Modern Loading Best Practices （Addy Osmani、Ilya
Grigorik、Bryan
McQuade）：このプレゼンでカバーするリストも巨大。最初のスライド、スクリーンショットが下にあり、良さそうな提案のリストがありますが、どれもAddyが詳細をカバーする時間はありませんでした！
彼はJSを150KBに抑えることについての数字の詳細を話しました。
その後、IlyaとBryanが突然Chromeユーザーエクスペリエンスレポートを発表しました。
Addyに戻り、彼はfont-display: optionalについて話しましたfont-display: optional 、
navigator.connection.effectiveType 、 link rel=preload 。
Addy最後にPinterestとTinder
PWAをケーススタディとしてプレゼンを終えました。このプレゼンがいい例ですべてをカバーしようとしたため、特定のテーマは何もありませんでした。
Workbox: Flexible PWA Libraries （Jeff Posnick）：
WorkboxはSW
APIはとても扱いにくい中、Service
Workerを自動的に生成するための素晴らしいライブラリです。Workboxは以前からあるsw-toolboxとsw-precacheライブラリで構築されています。
Wordpress + PWAs （Surma、Dan
Walmsley）：Surma（彼の名前は単語1つです）はWordpress上で構築されたPWAのデモを行いました。
AutomatticのDanは、ソースコードは公開されていないWPのJetpackプラグインも簡単なPWAサポートを提供していると話しました。
Progressively Improving E-Commerce （Sam Dutton、Rowan
Merewood）：実用的なアドバイスでいっぱいですが相変わらずリスト消化型。重要なコンテンツを最初に表示する（メニューバーではなく、主要な製品の写真）、ページの負荷を安定させる（イメージサイズを事前に宣言する）、イメージを最適化する、スクロールリストに
Intersection Observerを使う、プレースホルダイメージにimage-trace-loaderなどを使う。予測読み込みにはlink rel=prefetchを使用します。 Lunaによるオフラインのクライアントサイド検索。フォームにマークを付けてautofillを使います。
Building a Modern Media Experience （Francois Beaufort、John
Pallett）：Shakaプレーヤーに呼び出し、link rel=preloadの代わりに、 <video>タグのpreload属性を使い、 media session APIを使いスマホとAndroid
Wear Watch間でメディア再生タイムラインを同期させ、visibilitychangeイベントまたはIntersection
Observersで動画を一時停止させます。
The Web for the Entire World （Tal Oppenheimer）：インターネット利用に関する興味深いデータ。
特にインド。中国とインドは共に米国よりもインターネットを利用している。インドのスマートフォンユーザーの33％が毎日ストレージ容量を使い果たしている。
24％が100ドル未満のスマホ。インドのユーザーのうち少なくとも53％は今後3年間、2Gネットワークを使う。
デビットカードの数はクレジットカードの28倍。また実用的なヒントのいくつか：Chrome
63には、デバイスのメモリ容量を知るnavigator.deviceMemory
APIとクライアントヒントヘッダ、ネットワーク品質を予測するnavigator.connection.effectiveTypeがあります。
（そしてもちろん、Googleの誰もService Workerのメリットを話さずにインドについて30分の話をすることはできません）。
Modern Tooling, Testing, and Automation （Eric Bidelman、Paul Irish）：ほとんどのDev
Toolsの機能と同様、文章にするのは難しいです。
動画を見たほうがよく分かるでしょう。Paulは、CSSグリッドレイアウトの検査、「ローカルオーバーライド」（Dev
Toolsに保存されたGreasemonkeyの「ユーザースクリプト」を作成する方法）、新しいリアルタイムのパフォーマンスモニタ、類似のイベントのフィルタリングとグループ化のためのコンソールログの強化、PWAように強化されたApplicationタブについて話しました。
しかしプレゼンの途中で、Ericは、Chromeを自動化するためのすばらしい使いやすいNode APIであるChrome Puppeteerの話を始めました。
その後Paulに戻りデベロッパーツールの＃1バグを修正してステージ上で表示し、複数のリモートクライアントがChromeをデバッグできるようにすることを発表しました。
The Future of Loading on the Web（Sam
Saccone）：どのような機能が今後Webプラットフォームに登場するのか、そしてそれらがどのようにWeb上のローディングを変えるのかという話。
結果として基本的に今日使用できる実用的な取り組みはありません
😞。SamはV8は自動的に解析されコンパイルされたJSのキャッシュを開始すると述べているため、細かいキャッシングがこれまで以上に重要になります。
彼はasync import('./blah.js')を使ってダイナミックなインポートを呼び出しました。これはnetwork.connection.effectiveTypeまたは.rttと組み合わせて、大きなバンドルまたはそれより小さなモジュールをダウンロードするかどうかを決定できます。
次のページ、H2キャッシュダイジェスト、H2プッシュ中のオーバープッシュを防ぐ方法。次に、スクリプトとイメージの明確な優先順位。
デコードを遅らせることができる非同期画像（不可解なことに、それらは依然としてメインスレッド上でデコードする）。
WebWorkerがメインスレッドがコミットできるDOM変更のリストを生成することを許可するAPIであるDOMChangeListがあります。
DOMChangeListはSharedArrayBufferを介して共有することができ、Webワーカーがメインスレッドと直接メモリを共有することができます。
V8 Today and in the Future（Thomas
Nattestad）：V8がまた速くなりました🎉。また新しいES6とES2016の機能は最高速度で完全にサポートされるようになったので、babel-preset-envを使って最新のChromeで最近のJSの機能を使うことを検討してください。
Real World WebAssembly （Alex Danilo、Deepti Gandluri）：
WASMは最近のすべてのブラウザでサポートされているので、実際に使用することができます。
WASMの画像デコーダとIDEを含むいくつかのクールなデモが紹介されました。
近日発売予定：スレッド、改良されたデバッグ、固定幅SIMD、ゼロコスト例外処理（現在はJS内でC++の例外がシミュレートされています）、ガベージコレクション。
End-to-End Polymer Apps and the Modern Web Platform（Taylor
Savage）：Polymer主張者はいつも皮肉者に思えます。このプレゼンも例外ではなく、皮肉っぽい「javascript-industrial
complex」の話で短期間の考え方が長期間のエコシステムの健康よりも優先される話など。（相変わらずPolymerがイマイチ人気がでずWeb
Componentが流行らない理由に陰謀説があると思っているんだろうか？）続いてTaylorはPolymer
3を発表し、bowerからnpmに切り替わり、HTML ImportsからES6 Modulesに切り替えることについて話しました。（ GoogleはHTML
importsのサポートをやめようとしるみたいだが、
Safari、Firefox、Edgeもサポート予定はないようだ
。）。その後Polymerの開発者経験の問題を簡単に認めてから、Polymerの開発者経験に関係のない4つの機能について話しをしました。彼はあなたがGoogleの150KBの制限（ルートあたり50KB）にとどまるのに役立つツールがあると言いましたが、これがどの機能であるかは言いませんでした。
彼はWeb Componentが「アプリケーションレベルのコンポーネント」（詳細なし）に対して有効という話をして、 Redux for
Polymerの紹介、prpl-server-nodeへリンクすることを話しました。これのどれもPolymerの開発者経験の問題の解決策にはなりそうではなく、TaylorやPolymerチームが実際に問題を理解しているかどうかを深く疑うことになりしたが。
でもその次に…
lit-HTML （Justin Fagnani）：Polymerチームの新しいフレームワークですがPolymerの要素はまったくありません。
UIが純粋な状態の関数であるHTMLテンプレートをベースにしたJSXを含むReactっぽい印象。しかし重要な点は、Web
Componentを使用しないことです。
ReactコンポーネントをWCとしてラップすることができるように、lit-HTMLをWCでラップすることはできますが、メリットは何もありません。
興味深いアプローチですが、それはまだ1.0ですらなく非常に新しく、Polymer、Angular、Svelte、Skate、Stencilと直接競合します。ちょっと様子見ですかね。
Creating Media Without an App （Mat Scales、Jennifer Lin、Peter
Shin）：InstagramのJenniferとPeterは、PWAへのアプローチを進めました。
彼らはWorkboxとShakaのプレーヤーを使用すると同時にWebGLのパフォーマンス機能を至るところに活用し、満足なパフォーマンスを実現する必要がありました。またオフラインの画像アップロードにBackground
Sync APIを使っています（ここでデモが失敗します）。その後Instagramチームは外れ、ChromeチームのMatが戻ってきてMedia Session
API、Image Capture API、Media Recorder API、イメージ変換にWASMを使用することを話しました。
The Future of Immersive Experiences on the Web with VR and AR（Josh
Carpenter、Brandon Jones）：WebVRはまだ公開されていませんが、1.0は実験的な最初での試みの後の2.0が引用符付きで紹介されました。
WebVR
2はヘッドセット以外のデバイスの「マジックウィンドウ」UIをより簡単にし、最適化を容易にするためにより規範的なレンダリング手法を使用し、入力APIをラップして使いやすくし、スプラッシュ画面が必須になったので、
読み込み中に真っ暗な画面をみなくて良くなりました。またAppleのARKitライブラリと競合してい
AndroidのARCoreライブラリの出荷が発表されました。

Q＆Aパネル

パネルは私の意見ではほとんどのプレゼンよりもはるかに優れていました😁。

リーダーシップパネル

モデレーター：Chris Wilson
パネリスト：Darin Fisher、Parisa Tabriz、Grace Kloba、Thao
Tran、Tal Oppenheimer、Matt McNulty、Alex Komoroske、Alex Russell

AMP対PWA？ Darin：ゴールは速いウェブです。
なぜ今年はPWAサミットがないのですか？ Chris：PWAだけではありません。
JavaScriptバイナリASTをサポートしていますか？ Alex R：Service Workerがパースしてコンパイルされた出力をキャッシュするなど他のアプローチがあります。バイナリASTには長期的な影響がありますが、すべてがわかっているとは限りません。
デスクトップの「ホームスクリーンに追加」？ Alex K：今でも一応できますが、隠されています。 Owenはここで何か新しいことのスクリーンショットを見せました。今後数カ月それを期待してください。（Chromeフラグを見ておきましょう）
ES6をtranspileするか、直接書き込むべきですか？ Alex R：あなたのユーザーは誰ですか？ユーザーが直接サポートしている場合は使用してください。それ以外の場合はtranspileしましょう。
WebKit / Blinkフォークについては何が良いか悪いのですか？ Alex K：現在Blinkの周りに素晴らしいコミュニティがあります。私たちの目標はできるだけ速くウェブを動かすことです。 Alex R：私たちは競争を大事にします。別のチームが何かクールなことをしたら、私たちは追いつく必要があります。 Darin：非互換性はもっとあると思うかもしれませんが、コードの上にすでにたくさんのifdefセクションがあり、すでに効果的にフォークされています。 Alex K：悪化する可能性のあるものの1つは、ブラウザ間の互換性の問題です。私たちには、ウェブテストで働く「予測」チームと、他のオープンソースブラウザで差を埋めるチームがあります。
いくつかのチームがレンダリングエンジンあるいは1つの大きなブラウザで作業する必要がありますか？ Alex R：Web開発者として、私は1つのブラウザが欲しいです。しかし競争とは、1つの大きなブラウザが停滞することはできないということです。 Alex K：ブラウザ戦争は今のところ良くなっています。我々はお互いに協力し合う素晴らしい仕事をしています。 Grace：これらの技術的問題に近づくには、多様性に固有の価値があります。
PWAやAndroidインスタントアプリに関するGoogleのアイデンティティの危機はどうなっていますか？ Parisa：もう一度いいますが競争は素晴らしことです。Googleの内部でさえ競争を大切にしています。世界はより多くの選択肢がある方が良いです。
検索結果にAMPを強調表示するのはなぜですか？私たちは検索チームではありません。
Chrome専用サイトって何ですか？私たちはそれを好まない。私たちは内部的に動いて彼らを止めさせようとします。
どのくらいのストレージをウェブサイトでちゃんとオフラインで保存できますか？Alex R：この制限を大幅に増やしました。ユーザーのディスク容量の1%まで。
なぜGPSにPWAをインストールできないのですか？Darin：一応できます。そしてTrusted Web Activitiesを使うことでそれをさらに簡単にすることができます。
あなたは今後10年間で何を最も誇りに思うでしょうか？ Alex R：スマホの後の次のフォームファクタの変化があってもウェブが生き延びるのを助けることができれば。 Alex K：健全な競争。 Matt：ユーザーを最優先にすること。 Tal：すべてのユーザーのためにWebを構築しました。 Thao：一度ビルドすしてどこでも動作するようになる環境。Grace：次のプラットフォームを扱う。 Parisa：HTTPSの成長と、セキュリティで保護された監査可能なPKIの導入。 Darin：Chromeで21年間働いていること。

フレームワークパネル

モデレーター：Addy Osmani
パネリスト：Andrew Clark (React), Jason Miller (Preact), Steve
Orvell (Polymer), Rob Wormald (Angular), Tracy Lee (RxJS), Chad Hietala
(Glimmer), Sean Larkin (Webpack), Malte Ubl (AMP), Alex Russell

あなたのフレームワークに最も有益な新しいブラウザ機能は何ですか？ Jason：DOMChangeList。 Rob：+1 DOMChangeListとObservables。 Tracy：+1 Observables。 Malte：ウェブワーカー用のDevツールの改善 Real weak references. Steve：WCがネイティブ要素ができない事ができるようになること。 Andrew：要素を非同期にする。 Async append（DOMChangeListと似ています）。
フレームワークの選択にはどの基準を使用すべきですか？ Alex：バイト単位でどれくらいのヘッドルームを使いますか？
フレームワーク同士の協力は？トレイシー：それは素晴らしいだろうが… Sean：Vueはいい感じで動作します。 PreactはすでにVueコンポーネントをインポートできます。 Jason：Webコンポーネントをコンパイルすることにはみんな賛成できるよね？Steve：WCは相互運用を行うように設計されています。 Rob：AngularコンポーネントがWCを吐き出すのようになればいいんですが。 Andrew：WCはクールですが、Reactチームの人間としてReactコンポーネントをWCに置き換える必要があると納得していません。人々はあなたがvdomを取り除くことができると言いますが、私たちはカプセル化のためだけでなくメモ化や計算の変更、スケジューリングのためにも使用します。 Alex：WCとVDOMは直交しています。 SkateJSはCustom ElementでVDOMを使用しています。
WebAssemblyはどのようにフレームワークに影響を与えますか？ Chad：それはJSを補足する存在です。 Jason：パフォーマンス重視のところではpolyfillとして使用します。
OSSの多様性をどのように改善できますか？ Tracy：私達は女性のテクノロジー産業への取り組みを支援しています。ジュニアの女性開発者が数多くを抱えていますが、彼女たちをシニアにする方法を見つけなければなりません。 Sean：Webpack Africaのようなアウトリーチ活動をしています。

Mediumの元の記事