HTML5Conference2018Japan のまとめ

【追記：2018/11/26】書き終わって整理したので、間違ってたり何かあれば Twitter でマサカリください。

行ってきたのでまとめ。

急ぎでゴリゴリ書いてるので、あとで追記したり書き直したりするし、もし間違っていたら Twitter で連絡貰えればすぐに対応しますので、ご了承を。

🔑 基調講演

スライド：＜見つけたらはる＞

1. Web of things について

by 岩井将行

  • IoT デバイスに今後は Web of things になっていく。つまり、デバイスが Web への接続／API の実行／JSON の解釈、などを行う。日本ではまだ購入できないが m5stack などのデバイスなどがそれ。

2. カンファレンスについて

by 吉川徹

  • 今年のこのカンファレンスは 1 日で 1600 人の定員が埋まったところからも、HTML5 自体の注目度は今まで以上に上がってきている。
  • 今まではネイティブが先に技術的に新しいモノが使われて、こなれてきてから Web に導入されてきた。だが、最近はネイティブでこなれる前に Web にも早く導入されるようになってきている。例えば WebXR や WebAuthentication など。速度のギアが更に速くなっているように感じているから今年のテーマは**“The web is shifting to the next gear”**。

3. 仕組みを作る仕組みを、作る仕組みを作る

by えーじ @ google as developer advocate

  • Web 標準を取り決める仕組みなど Web を作っていくための仕組みについての話。

  • 最近の進化技術：「Video + Picture in Picture」「WebRTC」「WebXR」「WebAuthentication」「WebAssembly + WebAudio」

  • Origin Trial：昔は「ブラウザ名 prefix ＋機能名」で命名していたが、実装者もそれで実装してしまうため負債が大量に生まれた。それを解決するための新しい手段でドメインベースで行う。

  • Extensible Web Manifest ( e.g. WebComponents / CSS Houdini / Service Worker)：低レイヤーで API を作成しておき高レイヤーの仕様を柔らかくしておくことで、技術のグロースと共によりよい方法が生まれた時にその部分は可変できるようになった。

  • Virtual-scroller(LayeredAPI)：ページ上の表示領域以外をレンダリングしない技術。

  • Async local storage(LayeredAPI)：非同期に書き読みが出来るローカルストレージの技術

  • AMP：ページの速度向上のための FW で。速度優先の専用の WebComponent を利用することでページの表示速度が遅くなる原因を生み出さないで機能を制限することで速度を早くする。問題点として、現在では更に高速にしようと google のキャッシュサーバから配信している仕組みが提供されているため google のドメインからページが提供される。そのため、ドメインが google のものに見えるし、クッキー情報などを google が持ってしまうことになる。この問題の解消のために、WebPackaging 技術が進んでいる。

  • Web Packaging：別のドメインから配信しても元々のページから表示されているように見せる仕組み。そのために署名(Singed Exchange 機能)を行うことで実現。

所感

  • ①IoT を通してリアルと Web が更に密接に繋がり

    ②Web 界では経験則重視で今までよりも積極的に新しい技術を採用されていく流れを感じられ

    ③ 具体的な技術で今〜未来にどのような技術が策定・実装中なのかを整理

    といった形でよい塩梅で話が構成されていた。

  • 特に ③ でかなりの数の新しい技術の紹介が行われたので新しいもの好きの自分的には少なくとも、概要レベルで ③ のすべての技術は抑えておきたいものである。

👍 ZOZO のグローバル EC のフロントエンドアーキテクチャ設計

内容

Zozo.com のグローバルサイトのフロートエンドのアーキテクチャに対する改善の話。

  • 問題 ①：アプリケーション全体としてのアーキテクチャが考慮されていない設計状態だった

    • → 解決：フロントエンドとバックエンドのそれぞれ両方でクリーンアーキテクチャをまるっと持つようにした。

  • 問題 ②：フロントとバックの接続を行う改善を行いたい課題が出てきた。

    • → 見送り案：BFF の導入はフロントが実装しないといけないのでコストが高いので見送り
    • 採用予定：GraphQL の導入予定

  • 問題 ③：Vuex での状態管理が信頼できる唯一の状態になっていない状況だった。

    • → 対応：Vuex の状態管理をリソース単位から View 単位に変更で解決。

  • 問題 ④：サーバ側で非同期で更新される情報をクライアントでどう表示するか？

    • → 対応：クライアントでよしなにやった。

  • QA：API Gateway を導入しなかった理由は?

    • → 知見が社内に少ないかつ中間サーバでパフォーマンスが取られる可能性もあるので今は見送っている

所感

シンプルに１つ１つの課題に対して地道に選定〜導入を行った話だった。同様な課題があるケースでは参考になるのではないかな、と思う。

ただ、個人的には「フロントにロジックを持たないようにする設計をどう作り上げるか？」や「フロントに状態を持たないような設計」とかの方が好み

あと、「GraphQL の案」と「BFF の案」みたいに発表されていたが、GraphQL って BFF では・・・？

何より問題 ④ に対して解決の案でロングポーリングや ServerPush とかを説明されていたが、最終的には解決対応が「クライアントでよしなにやった」的な感じでぬるっと終わったので「？！」感が強かった。

ZOZO クラスのレベルの規模のサイトとなるとおそらくコードや組織のしがらみが大きくなっていそうなので、シンプルなりファクタや改善を行っていくだけでもかなり大変だと思うが、脳筋で進めずにゴリゴリと改善・リファクタも行っていくスタイルは素晴らしいと思う。。ZOZO は個人的に好きでもあるし期待。

👍 「それ、AMP で作りませんか？」--- Rich で Responsive かつPWAな AMP の作り方

概要

AMP を使った、爆速前提の「キレイで使いやす＝豊富で機能性を持った」ものを作ること方法の話。

  1. AMP とは
  2. AMP の基本的な使い方の話
  3. AMP のレスポンシブの使い方の話
  4. NewAMP コンポーネントの話
  5. Service Worker との話
  6. 直すべきこと（AMP cache のドメインが
  7. 今後は JS を使える環境を提供する！

ポイント

  • 実は AMP に対する google エンジニアのコントリビューターは 22%

  • AMP とは、js を使わずに爆速軽量な OSS のライブラリで画像の最適化／CDN の提供まで用意されている。

  • なんで速いのか？の理由は「パフォーマンスにおけるベスト・プラクティスを AMP に全部ぶちこんでいる」からなだけ。

  • React とかの VirtualDOM をつかなくても Web の標準として WebComponents てのがある。

  • PWA と AMP で親和性が高い

  • AMP cache という仕組みがあり、AMP を使えば自動的に Google が提供する CDN を使わせてもらえるので CDN を準備しなくても良い

  • AMP cache の仕組みは残しつつドメインをオリジンにしたいので頑張ってる。→Singed Exchange でそれを実現できる予定。現状、Web 標準のための策定中。

  • ユーザが JS を書けるように頑張ってる → ユーザが JS を書き出すと速度がどうしても遅くなるような書き方をするケースがあるので、JS を動かすために WorkerDOM という JS をメインスレッドでなく WebWorker で動かすための機構を作成中で頑張ってる。

所感

概念として AMP は知っていたけど、実装レベルでの使うやり方の話だったのでとてもわかりやすかった。

今回の説明で強く感じたのは、ライトなアプリケーション・ページの場合は AMP の導入は費用対効果が尋常ではなく高いように感じる。速度が高速になるからもあるし、AMP 縛りならパフォーマンスの経年劣化もほぼ起きずメンテコストもほぼない。何より画像最適化やキャッシュレイヤーの担保までされているのでインフラ構築も不要だしバグも生まれない。

新しい AMP コンポーネントでは「無限スクロール」「Picture in Picture」「パララックス」なども存在しており表現できる範囲がかなり広がっている。概念を知っているレベルの人は google の参考集があるので、一通り見ておくと AMP で出来る範囲がなんとなくわかると思う。

というわけで、学習・実装・管理コストに対しての成果物クオリティが高いのでライトなアプリケーション／ページに対して積極的に使いたい。

ただ、自分のように Gatsby や Hugo などの StaticSiteGenerater を使っている人としては、プラグインが作成されていないと使えないのですぐに実装出来ないのは残念。

👍 PWA の導入で得られた成果と見えてきた課題

内容

  • PWA 導入による成果
  • PWA 導入後の改善活動
  • パフォーマンスを保つための取り組み
  • まとめ

所感

FW なしの JS で SW もゴリゴリに書いて進めているみたいなので、パフォーマンスに特化した話を聞きたい時に良い題材。

PWA はどのデバイスでも使えるような状態になっていると思っていたが「iOS safari では全然使いもんにならない」レベルでログインできないとかクリティカルな問題が散見するみたい。ただ、今から SW の導入を検討するならフルスクラッチではなく抽象化されたレイヤーが Next/Nuxt/WorkBox とかで提供され始めているので、ここらへんで進めると良いと思った。

また、Perfomance Budgetという、パフォーマンスメトリクスに対するモダンな考え方を導入していたので、ぜひとも継続してそのナレッジは貯めてカンファレンスなどで発表していってほしいと思う。ただ、こういうモダンな手法を取りいれても「うん、それで？」となってしまうような組織の理解は、なんというか「知見が浅い管理者」と「優秀なエンジニア」というよくある構図に見えたので少し悲しい気持ちになった。

👍 Web プラットフォーム再考 ～ PWA のもたらす未来の光と影 ～

  • by ものえおさむ、eegozilla、chikosk | ルーム B（1F）
  • スライド：＜見つけたら貼る＞

内容

  • ネイティブに出来て Web に出来なかった 4 つのこと
  • PWA の 8 つのメリット
  • PWA の価値を高める 4 つの API
  • PWA・Web・ネイティブの比較
  • PWA による功罪
  • PWA のベストプラクティス

ポイント

  • AppStore などでのリリースはプラットフォームに 3 割の料率を取られるわけなのでネガティブに捉えられがちだが、**AppStore はプラットフォームとして「アプリクオリティの担保」「決済の保証」など色々やってくれるのは実は法外な金額ではないのでないか？**と問題提起
  • PWA 化による WebAppManifest で UX がむしろ悪くなったケースもあり得る。きちんとユーザーの UX を向上を設計しない PWA はただの毒なので導入する際は要注意されたし。ネイティブや HTML5 の中間の UX なので、うまくユーザにリーチできるように。

所感

  • PWA 始まりの背景〜機能〜メリデメ〜経験などを網羅的にキレイなプレゼンだった。

  • 「PWA は作り手の次第で薬にも毒にもなる技術である」という強いメッセージだった。

👍 HTTP の今と未来 ー BBR, HTTP/2, QUIC の基礎から 5G 試験ネットワークでのブラウザベース評価試験まで

内容

  • HTTP/3 とは
  • 5G とは
  • HTTP/3 を試した結果

ポイント

  • 大容量・多種接続・低遅延を謳われる 5G だがよく紹介に使われる数値はあくまで最大値〜参考値なのでユーザ数・環境・基地局の調整でも大きく変動する。実際に、4G の速度は 1Gbps と謳われてるが計測値はそんなに出ないでしょ、とのこと。

  • 曰く「ネットワーク技術の変化を知らない Web 開発者ヤバい」「HTTP/3 時台なのに HTTP/2 + BBR 使ってなければ周回遅れ Web エンジニアが HTTP2/BRR をしろ」の煽り

  • 世界初の HTTP3 の調査結果なので今後 HTTP3 周りの実績値を知りたい時にめちゃくちゃ重宝する。と思われる。

所感

  • めちゃくちゃ早口の詰め込み教育的な感じだったが、わかりやすくてよく理解できるのはすごい。輻輳についてわかった気にさせてもらえる。

  • TCP/IP と HTTP 周りは「俺、いつか勉強するんだ・・・」のフラグがずっと立ちっぱなしになりがちなジャンル。というのも、仮に TCP/IP や HTTP プロトコルを知らなくても、だいたいの業務は出来てしまうから、どうしても後回しになりがちな勉強範囲だと思う。ただ、勉強するときに、このスライドはかなり有用なのでおすすめ。

🎉 総括

  • 1 日で 1600 名の定員が埋まるだけのことあって面白いセッションが大量にあって満足。内容的にも「サービスのアーキテクチャ」「PWA の導入事例」「キャッシュ戦略の考え方」「HTTP/3&5G のネットワーク」etc…と、かなりバリエーションに富んでいるので自分の聞きたいものを選択式に聴講できるので知見が深まった。ただ、自分が聴講した分とは別の裏側のセッションに気になるものもたくさんあったのでそっちも見たかったが。

  • 前々日のカンファレンスのNode 学園祭のまとめの総括でも書いたが、今回のカンファレンスでの具体的な実装系の話では特に GraphQL の話はところどころで聞こえてきたので、2018~2019 年で GraphQL の導入事例がかなり増えるのではないか、と思う。ので、フロント／バックの担当者は早めに経験した方がよい技術になると思った。

あとがき

おかしいな・・・。前回の Node 学園祭のまとめが 8000 文字オーバーだったので、今回はだいぶ絞って書いたはずなのにこの記事も 7000 文字オーバーだった・・・。もっとスマートな書き方をしないと・・・