user
Shun Namiki

Freelance full-stack Endigneer @ Shibuya, Japan

Published on Nov-25th, 2018 ( 11 min read )

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+機能名」で命名していたが、実装者もそれで実装してしまうため負債が大量に生まれた。それを解決するための新しい手段でドメインベースで行う。// TODOあとで詳しく調べる

  • 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を導入しなかった理由は?

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

所感

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

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

あと、「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文字オーバーだった・・・。もっとスマートな書き方をしないと・・・

arrow_back

Previous

Go Global Meetup#1のまとめ

Next

東京Node学園2018(Conference@JP)のまとめ(その2)
arrow_forward