HTML5 Conference とは
上記イベントサイトには、
Web技術に関するノウハウや最新情報の共有、そして交流の場
であり、
「Web技術者の祭典」
と書いてあります。 私の中では、Webのフロントエンド技術に関するカンファレンス、というイメージがあります。
参加した経緯
仕事ではサーバーサイド（主に Ruby on Rails）を中心にやってきましたが、これからはフロントエンドも頑張っていこうということで、参加させていただきました。
前職の社内ツール開発や、 Eight の開発で React + Redux は触っていましたし、プライベートでも勉強はしていたので、フロントエンドが全くわからないわけではありません。
とはいえ、勉強会やカンファレンスに参加したことはありませんでした。
今回は、初めてのフロントエンド界隈のカンファレンスということで、楽しみにしていました。
参加したセッションのメモと所感
参加したセッションの内容について、箇条書きのメモに近いですが、まとめさせていただきます。
また、ところどころでコメントを足したり、最後に所感も付けています。
ZOZOのグローバルECのフロントエンドアーキテクチャ設計
電車からスマホで拝見していたためメモを取れず・・・Twitter の #html5j_h を見返して気になったところにコメントさせていただきます。
- state はリソース単位ではなくページ単位
- サーバーサイドで RDB に慣れ親しんで来た身としては、state はリソース単位で扱うものだと思っていました。
- ただ、実際に Redux を触ってみると、State は巨大な JSON であることがわかります。リソースがネストすることもよくあると思います。そうすると、一つのリソースが state の複数箇所に存在するということが起き得ると思います。
- Eight ではnormalizr というライブラリを使って state を正規化していました。（少なくとも、私がいたころはそうでした。）ただ、normalizr は state の中でリソースが散らばるのを防げる一方で、実装が複雑になる印象があります。導入は慎重に検討するのが良い気がします。
- state をページ単位で管理することで、スッキリできるの煩雑にならずに済むのかもしれませんが、やってみないとイメージが湧かないかもしれないですね。実際には、ページをまたいでリソースを共有したいケースはあまりないんですかね。であれば、すべてを SPA にするのではなく、ページが変わる時は普通に画面遷移して、ページごとに一つの SPA を構築？しても良いような気もします。実際、React を勉強し始めた頃はそのように実装していました。
- BFF, GraphQL
- 巨大なアプリケーションになってくると、やはり BFF が欲しくなってくるんですかね。その場合、一つのリクエストですべてのリソースを取ってこれるという意味で、GraphQL は良さそうな印象があります。
所感
全体的に、プロダクトの状況からあらゆる手段を検討して最適と思われるものを導入している感じで、良いと思いました。
一方で、そこまで検討できるチームなら、最初から考慮できるものもあったのでは？と思ってしましましたが・・・メンバーも変わったり、チームの成熟度も高まったりしたこともあるのでしょうか。
FIDO認証によるパスワードレスログイン実装入門
- パスワード認証の課題
- 利便性、安全性の課題
- FIDO
- Fast IDentity Online
- パスワードへの依存度を減らす
- 利便性と安全性を向上する
- 公開鍵認証
- RP
- Relying Party
- 認証器 (Autenticator)
- FIDO の利便性
- 生体認証
- FIDO認証モデル
- ローカル認証
- Authenticator はスマホなど
- FIDO 技術仕様
- UAFとU2F
- Web Authentication API
- CTAP
- クライアントと外部認証器間の通信をサポートするプロトコル
- デモ
- name を入れるだけ + USBセキュリティキーで登録
- ブラウザのユーザー登録で、名前と USB セキュリティキーを登録する、というのは新鮮でした。
- Web Authentication（登録）
- 資料は後日公開してくださるそうです！
所感
- 実際に認証するのはローカルの認証器（スマホなど）なので、生体認証の中身がインターネットに出ることはないとのこと。（という理解です・・・）
- ブラウザ上の Web アプリケーションで生体認証が使えるのは良い！と思った一方で、予想以上に実装が大変そうでした。既にここまで追っているのはすごいです・・・
- 浸透してくるにはもう少し時間が必要なのかな？という印象です。
Yahoo! JAPANアプリ上で動くWebVIewサービス開発〜Web技術で動くライブクイズ「ワイキュー」〜
- アジェンダ
- WebApp on ネイティブアプリ
- メリット/デメリット
- デバッグ方法
- メリット
- 各サービスはそれぞれ自前のBEアーキテクチャを持っている
- 同時に開発できなかった事例
- デメリット
- パフォーマンス
- WebView の生成をしてから、APIを撮ってきて描画する
- ネイティブ機能を使うのは少し手間
- パフォーマンス
- WebView ならでは
- ネイティブの機能を使わせてもらう
- Push
- アプリ任せ
- 通知すべきか、いつ通知するかなどは、各サービスで管理
- ログイン情報は Cookie で管理
- 普通に Webb でログインしている
- Web でログインした情報をアプリと共有して、アプリでもログイン
- URLScheme でネイティブとやり取りする
- Web => ネイティブは URLScheme
- iframe を使って URLScheme を呼び出している
- ネイティブ => Web はカスタムイベント
- 予め取り決めしておいたカスタムイベントをアプリに発火してもらい、JSではイベントを listen するだけ
- 例えば
- ユーザー情報ください
- 未ログインなのでログインさせてください
- 別のIDでログインさせてください
- 終わりなので WebView 閉じてください
- Web => ネイティブは URLScheme
- ネイティブアプリのように見せる
- 実際の開発について
所感
- アプリが大きくなってきて、複数チームに分かれて開発をする場合、WebView という選択肢は良さそうに思いました。
- 巨大な一つのモノリシックなアプリケーションを複数チームで開発することで、コンフリクトが発生することは、サーバーサイドでも話題になります。
- そこでマイクロサービスが一つの解決策になるわけですが、サーバーサイドをマイクロサービスにしてもフロントエンドやモバイルアプリは分割できない、という話はよくありそうです。
- フロントエンドではマイクロフロントエンドという選択肢があるようですが、モバイルにおいては、WebView の一つの解決策なのかもしれないですね。
Node.js まとめ
- Node.js 11 リリース
- あまり変更がない
- Node.js コアポリシー
- small core, less is more
- LESS IS MORE.
- 建築家の言葉
- これ以上引くことがない状態が、良い状態
- シンプルな状態を目指しましょう
Less is More普段の開発でも意識していたい。
- コミュニティのエコシステムで解決できるものは
- では何をやるのか
- Stability (Node.js Core)
- Long Term Support で不具合は2年間修正される
- セキュリティ問題はさらに３年間修正される
- 安定的に運用できる
- LTS 的なことをやっている言語はあまりない
- 新しいバージョンが出たら追従していかないといけない
- V8 & Node.js
- V8 は Node.js 非互換の修正は通知する
- v8/node に Node を fork している
- 自動テストを回して、テストが壊れないことを保証している
- 昔は壊れた
- V8 のバージョンが上げられない => 最新の仕様を取り込めない
- PR毎に CI でテストする
- 全CPU・プラットフォームでビルドしてうまくいくことを確認している
- たまに壊れるテスト (flaky test) に関してはどのプラットフォームで起きるか調査し、修正していく
- フレーキーテスト
- Issue に書いておく
- フレーキーテスト をどこかにまとめておくというプラクティスは、普段の開発でも取り入れたいと思いました。実際、たまに落ちるテストってあるんですよね・・・
- Stability (Node.js Application)
- Performance
- Performance priority is high
- 遅いことを許容しない
- ES2015 の let, const
- 初回は遅い
- var とスコープが違う
- 若干遅くなっていた
- 今は、v8 が頑張ってチューニングしているので、let, const にしても良いかもしれない
- Node の中のコードは var が多い
- ES2015 の let, const
- 必ず定期的に benchmark を取得
- マイクロベンチマークだけではなく、Express を使ったある程度の規模のアプリでもテストする
- keep v8 fresh
- v8 はパフォーマンスチューニングをかなりやっている
- v8 を最新に保つのは、パフォーマンスの点で重要
- v8 のバージョンはメジャーバージョンリリース時までの Stable Chrome に利用されている v8 を利用。
- Worker
- Thread を使えるようにするためのもの
- Node.js はずっとシングルスレッドだった
- Node.js で multi thread プログラミングができる（ついに）
- 何が嬉しいか
- Node.js の需要はサーバーサイドだけではない
- Webpack, Babel
- ファイルを集めてきて、ファイルの中身を呼んでトランスパイルしている
- CPU をめっちゃ食う
- シングルスレッドでは限界がある
- 4つの Babel プロセスに投げる
- 最近入った llhttp というパーサがやばい
- Security (Node Core)
- Security Release は脆弱性が報告される度に修正パッチが作られて報告される
- Security (Ecosystem)
- npm-audit
- npm audit コマンドは脆弱性が報告されているライブラリが自分のパッケージの中にあるか、調べてくれる
- yarn audit もある
- yarn audit は CI の中に入れちゃって良いのかも？と思いました。
- Less is More で機能追加はしないと言っても例外はある
- Web Standards
- Why Node needs web standard?
- internet standard なものも取り入れていく
- Node.js v10.0.0 ~ v10.12.0
- http2
- Promise
- Node.js v11
- http2
- ES Modules
- import で読み込める
- まだ Experimental だが、commonjs も es modules も相互運用できる形で実装されている
- .mjs という拡張子
- nodejs/modules で議論
- Promise in Node Core
- Node.js には非同期処理のやり方が複数
- Callbabck
- Promise
- Stream
- フロントエンドで非同期といったら Promise なので、普通に Promise で書いてました・・・
- Web では Promise がほぼ標準的なので、Promise に集中されていく
- util.promisify
- Callback を Promise 化できる
- fs.promises
- これも Experimental
- Node.js には非同期処理のやり方が複数
- Stream/Promise の親和性改善
- Stream => Promise
- Promise => Stream
- どっちもいける？
- Node.js の今後
- Big News
- Node.js Foundation, JS Foundation はマージしていく流れ
- Unified JavaScript Platform
- Web API も Node.js も ECMAScript も求めているのはユースケース
- 開発者がユースケースを作っていき、仕様策定者側にフィードバックする必要がある
所感
- 古川さんがイケメンだった
- 知識量に圧倒されました。Node.js の最新の動向についてや、WASM や LLVM についてなど、かなり深いところまで理解していらっしゃるなと・・・
- これくらい強い人になりたい
開発者がユースケースを作っていき、仕様策定者側にフィードバックする必要があるという言葉も印象的です。こういう意味でも、ある種 攻めの 技術選定というのは必要なのかもしれないですね。
HTTP の今と未来 ー BBR, HTTP/2, QUIC の基礎から 5G 試験ネットワークでのブラウザベース評価試験まで
- 事前配布資料
- GZip 圧縮していない人は論外
- 低遅延の事例
- 5Gサービス実現に向けた取り組み
- 2018~ 実証実験
- 2020~ 5G実現
- 2022~ 5G高度化
- Web for 5G の課題
- 5G の性能を活かしきれない
- MEC (Multi-access Edge Computing) の活用
- 5G基地局 の前にサーバーを置く？
- 5G の性能を活かしたアプリ提供
- 今まで
- オペレータは土管として NW パフォーマンスを意識
- これからの5G
- エンドユーザへのサービス視点がないとやばい
- 実験環境を提供
- 一緒に作っていく
- 場所の提供
- 5G IoT Studio
- 屋外、屋内での5Gトライアル
- 5G + 基盤技術を用いたトライアル
- 様々な 5G x IoT のデモ見学
- お台場ラボ（テレコムセンター駅）
- HTTP/2 & TCP のおさらい
- 待ち行列の先頭が詰まると待たされる
- 最初のファイルの送信完了まで後続のファイルが待たされる
- TCP の課題・限界
- HTTP/1.1 から HTTP/2 へ
- 単一 TCP 接続上での非同期並列通信
- 今までは単一 TCP で１ファイル
- 今のブラウザの実装では、HTTP/2 なら100ファイルまで
- Google SPDY => HTTP/2
- ここら辺の話は、確か mozaic.fm の以下の回で話をされていた気がします。
- https://mozaic.fm/episodes/2/http2.html
- TLS 1.3
- SSL の新しいやつ
- 初回接続（Full Handshake）
- TCP における輻輳制御
- フルスピードで送ると、回線が細いところであふれる
- パケットがロスする
- 観測して、調整する
- ロス検出
- フルスピードで送ると、回線が細いところであふれる
- 待ち行列の先頭が詰まると待たされる
- HTTP3 QUIC
- HTTP/3 + QUIC Transport
- HTTP/3, QUIC を試すには
- LiteSpeed
- QUIC 対応は商用ライセンス
所感
- スーツに素足で登壇されていて、印象的でした。既に只者ではない・・・
- 結局 HTTP/2 にちゃんと触れることがないまま、HTTP/3 の話が来てしまった・・・
5G×IoT Studio面白そうです。 IoT に疎いので、まず「5G x IoT のデモ見学」をしてみたい。
スペシャルセッション
LTとクイズ大会でした。
1000万以上のWebページをAMPにした話
- weblio
- Why AMP
- 速度改善
- SEO
- ページ表示速度が遅いと、検索順位が下がるかもしれない
- ユーザー数増加
- どうやって大量のページを AMP にしたか
- 段階的に AMP にしていく
- タグがなければ
- GA で計測
- 段階的に AMP にしていく
- 有効な AMP か検証する
- URL の最後に develop...
- Search Console
- 便利な AMP コンポーネント
- 100種類のコンポーネント
- 非AMPページにも使える
- amp-img で画像の遅延読み込み
slamdata/purescript-halogen の紹介
@e_ntyo さん
- PureScriptとは
- いわゆる AltJS の1つ
- psc でコンパイル
- .purs => .js
- 既存の JS コードも再利用できる
- Haskell ライクな関数型プログラミング言語
- 静的型
- 圏論の世界の概念を利用できる
- slamdata/purescript-halogen
- VDOM を利用した UI ライブラリ
- 仮想DOM
- VDOM を利用した UI ライブラリ
ビルドプロセスから考える CSS アンチパターン
@kimamula さん
- CSS 苦手勢
- Flexbox, Grid Layout を使えば、 CSS はそんなに辛くない
- コンポーネントベースなのに、CSS はグローバル
- Bootstrap, 独自CSSなど
- フロントエンドはコンポーネントベース開発が主流
- 使われていないCSSが場bンドルに混入する
- ページのひょうじが遅くなる
- ローカルスコープ化する技術を使えない
- BEM などで戦う
- ポータビリティが下がる
- プロジェクト外で再利用しづらい
- CSS をコンポーネントに含める
- メリット
- code splitting が可能
- ローカルなネームスペース
- メリット
- コードは DRY だが出力が DRY じゃない
- CSS in JS
- ビルド後のコードを考えていない
- JS は DRY だが CSS は DRY じゃない
Preload, Preconnect を利用した SPA サイトのパフォーマンス改善
@yayoc さん
- micro services, BFF, SPA, ...
- Preconnect
- Preload
- 早めに取得
- Prelaod as font / image
- Preload as fetch
- 結果 / まとめ
- Preload / Preconnect は割と簡単
- ルーティングベースで動的に取得可能
CSS組版の救世主 Vivliostyle
@spring_raining さん
- CSS組版？
- Web技術で本をつくる
- HTMLで原稿を書き、CSSでページにレイアウト
- 同人誌、商業誌で使われている
- Vivliostule
- ブラウザにない機能
- Vivliostyle の目的
- 標準化される可能性
- EPUB Adaptive Layout という仕様に対応した EPUB ビューアを
Webb Develop
@kosamari さん
- Squoosh.app 作ったチームの人
- すご・・・
- Input のお話
- Non-fast Scrollable region
- passive: true
- イベントは教えてほしいけど、スクロールはそのままやっちゃってください
最後に
改めて、Web を追いかけるのって大変ですね・・・。普段は今仕事で使うようなアプリケーションレイヤーのことばかり追いかけていて、深いところまで理解せずに使っていることを痛感したような時間でした。HTTP/2, HTTP/3 も触れねばだし、次の仕様を追いかけるような強い人になりたい。
私にとっては初めてのフロントエンド界隈のカンファレンスでしたが、とても楽しかったです。関係者の皆様、ありがとうございました！！
