「HTML5 Conference 2018」に参加しました

イベントページ

矢倉さんのセッションの、「Webは小さな仕様をつくる流れで、ライブラリを作りやすくする低レイヤーを整備（レゴブロックのように）」というのが印象的だった。基調講演のえーじさんの説明と合わせて、Extensible Web Manifestoが今回ようやく腹落ちした。
後は、最後のWebXRの未来感がすごくて刺激になった。

私が参加したのは次のセッション。

基調講演

吉川徹、えーじ、岩井将行

• １ヶ月にWebにアクセスするデバイスの数: 50億以上
• Webの進化
• 動画、Picture in Picture
• WebRTC: ビデオ会議など
• WebXR: WebでAR/VR
• Web Authentication: 指紋や顔でログイン
• WebAssembly + Web Audio: EUROPAのデモ参照
• 仕組みを作る仕組みを、作る仕組みを作る
• 「仕組みを作る仕組み」= web　を作る仕組みを作る
• オープン性
• GitHubで議論
• Browser Feature Status Dashboard
• 相互運用性
• ２つ以上のブラウザが実装しないと標準として認めない
• Origin Trial
• オリジンを限定（申請）して、新しいAPIを一定期間実験的に試す
• ベンダープレフィックスによる混乱から生まれた
• Extensible Web Manifesto
• 低レイヤーのAPIをまず作る
• 例）Web Components, CSS Houdini, Service Worker
• Layered API
• virtual-scroller: 画面全部のレンダリングをスクロールに応じて動的にして、パフォーマンスを改善（ネイティブやReactでは普通に使われている）
• async local storage
• AMP (Accelerated Mobile Pages)
• ページの高速化
• 多くの制約（により高速に）
• Web Componentesベース
• 課題: URLが変わってしまう（Googleのキャッシュから配信するため）
• Web Packaging => URLが変わらないようにできる
• Signed Exchange, Bundled Exchange
• Feature Policy
• 利用できる機能を制限、もしくはレポートを受け取る
• "Web is the only platform no one owns." Dave Winer
• Webをよりよくするために
• 勉強会への参加・登壇
• ブログを書く
• ドキュメントの翻訳（MDNの翻訳会もある）
• 仕様やブラウザベンダーへのフィードバック

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

権守健嗣

設計を見直す上で考慮した技術とアーキテクチャー

• アプリ全体のアーキテクチャーを意識しておらず、フロントがアプリ層、データ層にも、バックエンドがプレゼン層にも介入
• アプローチ１: フロントエンドがビジネスロジック（アプリ層）を持つ
• クロスプラットフォーム実装: React Native, Weex, Flutter, Xamarin, NativeScript, Cordova, Titanium Mobileなど
• Webも使えるもの
• Cordova: 遅い
• Titanium Mobile: 情報がない
• Kotlin/Native, Kotlin/JS: セキュリティを考えると難しそう
• アプローチ２：それぞれでアーキテクチャーを持つ
• クリーンアーキテクチャーの思想を導入
• Vue.jsのコンポーネントがUse Cases（ビジネスロジック）を包含
• domainディレクトリ配下にRepository, Entityを配置
• applicationディレクトリ配下にサービスやモデルを配置
• フロントとバックエンドでAPIに求めることが違う（フロントは一括でほしい、バックエンドはシンプルにしたい）
• BFF (Backends For Frontend): 実装大変、パフォーマンスに影響
• GraphQL: フロントはクエリでデータを一括でとれる、バックエンドはシンプルにできる
• 状態管理: VuexのSingle source of truthを実現できていないため、状態変更が正しく検知できない
• 状態変更の検知
• レスポンスで変更したリソースを返す: API内部の非同期変更に対応できない
• ポーリング: リアルタイム性が増すと、サーバーの負荷が大きい
• サーバープッシュ: コストに懸念
• WebSocket, Server-Sent Events, gRPCの双方向ストリーミング
• 現在は、フロントで適切に情報を取りに行くことに
• Vuexの使い方: StateをやめてPage単位で管理
• 共通はcommonを用意
• ディレクトリ構成を整理

2018年のHTMLやCSSやAPIとか

矢倉眞隆

• Webは30間近（1989年3月誕生）
• Webページからはじまり、Web 2.0でJSが再発見、HTML5で勢いづく、最近は落ち着いた？
• 大きな仕様はつらいので、小さな仕様をつくる流れに
• ライブラリにやさしく、ライブラリもプラットフォーム、ライブラリを作りやすくする低レイヤーを整備（レゴブロックのように）
• HTML
• 画像関連
• lazyload: 遅延読み込み
• importance: 読み込みの重要度
• decoding: 遅延デコード
• 使い方
• カルーセルの最後の方の画像のimportanceをlowにする
• 真ん中くらいの画像はlazyloadをonにして、フッターの画像はimportanceをlowにする
• フォーム
• (inputmode)
• enterkeyhint: Enterキーの見た目を変える
• passwordrules（提案中）
• スタイルの共通化
• <fieldset>と<legend>
• <button>
• スタイルのリセットをしやすいように
• CSS
• レイアウト
• Gridが使える
• Subgrid提案中
• Flexboxにgapプロパティ（Firefoxのみ）
• フォント
• Fonts Module Level 3
• Level 4のVariable Fontsも対応（MS Edgeのデモサイト参照）
• ダイナミックサブセッティング（必要なものだけとってくる）の標準化が検討中
• Scroll Snap
• スクロールをピタッとさせる（スライドみたいに）
• Scrollbar styling
• スクロールバーの色と幅をカスタマイズ（scrollbar-width/color）
• Houdini
• WebKitで実装開始
• Custom PropertiesをCSSだけで書けるように
• WebComponents
• WC元年（FF実装、Edgeが実装開始）
• 検討中の機能もたくさん
• Form participation
• Template Instantiation
• Lightweight default styling
• WCは「HTML要素をつくる」もの、フレームワークとは補完関係
• 新しいものを探せそうなところ
• Google Developers
• Mozilla Hacks / MDN

Web Components のリアル

aggre

資料：https://speakerdeck.com/aggre/realistic-web-components

• Web Componentsの近況
• Chrome, Safari, Firefoxはpolyfills不要、EdgeはDevelopingに
• polyfills: webcomponents.js
• Web Componentsの基本
• Custom Elements
• Shadow DOM
• ES Modules
• HTML Templatesは開発者は直接使わない
• HTML Importsは非推奨
• Custom Elements
• 標準のコールバック機構を持ったクラス
• constructor()
• connectedCallback(): 小要素として接続されたとき
• disconnectedCallback()
• observedAttributes(): 属性が変更されたとき
• adoptedCallback(): あまり使わない
• Shadow DOM
• DOMをカプセル化
• CSSが外に影響しない
• <slot>: Shadow DOMをつけると、元々の中身が消える。消えた中身はslotに入る
• プロジェクトを超える
• 例えば、ブランドアセット（<brand-mark>を定義）
• ライブラリ
• 例えば、次のようなものは、VueでもAngularでも何でも使える
• <iron-autogrow-textarea>
• <pinch-zoom>
• ライブラリを探す場所
• Webcomponents.org
• GoogleChromeLabs
• マイクロフロントエンド
• Web Componentsの中にReactを隠蔽することもできる
• ページの関心事と技術的関心事を分離する
• SSR
• SSR用のDOMを用意しておいて、アプリで書き換える。さらに、slotを使うと、Shadow DOMから自由にいじれる。
• 現実的な手法
• lit-html: 属性値が文字列になる制約がある、Functional Programingにはおすすめ
• lit-element
• Angular/Vue

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

ものえおさむ、eegozilla、chikoski

• PWAの基本
• PWA: ネイティブアプリのようなUXを提供するWebアプリの概念
• オフラインサポート
• プッシュ通知
• バックグラウンド処理
• アイコンの追加（インストール）
• PWAの価値を高めるAPI: CSS3, WebAssembly, WebVR, Web Payment
• PWA採用例: Twitter Lite, Instagram, Googleマップ
• PWA vs モバイルWeb vs モバイルApp
• 機能: Web = PWA < Native
• 開発
• Web/PWA: JS / 任意エディター / Webブラウザ配布
• Native: PFごとの言語 / PFごとのIDE / PFごとのアプリストア
• ユーザー体験

引用元: https://html5experts.jp/uskay/25391
• アプリの審査、購入と課金: アプリストアがやってくれていることも多い
• PWAはユーザーにメリットがあるのか？
• Packt（電子書籍）
• プッシュ通知でのセールおしらせは便利
• タブと検索窓がないのがつらい
• Qiita
• ググった後、強制的にPWAに飛ばされる
• 記事をタブで残しておけない
• Yahoo! JAPAN
• ホームアイコンのオファーがうざい
• ながら見なので、ホーム画面においてもメリットない
• ABC 2018 Spring（発表者自作のイベントサイト）
• キャッシュのせいで思ったように更新されない
• 端末ごとの挙動の差
• ユーザーにとってのメリットをよく考えないとかえってUXが悪くなる
• パフォーマンスがPWAがネイティブに勝ることはない
• ユーザーのパラダイム（マジョリティのマインド）を理解して、PWAの機能を使うべき（自分のプレゼンスのためではない）

WebXR: Beyond WebGL

小山田晃浩

• WebXR Device API
• ARとVRの両方のAPI
• KhronosのOpenXRとも連携している？
• Chrome Canaryでhttps/localhostで動く
• ARのレイヤー
• XR imaginary
• WebGL scene
• デモ
• ARで床にキューブをおく
• ARで床にきのこをはやす
• ARで床にりんごをおく
• glTF
• 3Dモデルのフォーマット
• Facebook、MS Officeなどが対応
• Facebookに投稿
• パワポにはりつけてアニメーション
• CodeGridのglTF入門の記事参照
• セキュリティ
• 視線トラッキング
• バーチャルキーボードの入力をチート
• 視線から状況をチート
• etc
• まとめ
• WebXR Device APIでブラウザさえあれば、WebでVR/ARが可能になる
• iOSでは、制限はあるがすでに実現されている
• glTFが重要な標準になる