矢倉さんのセッションの、「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ごとのアプリストア
- ユーザー体験
- アプリの審査、購入と課金: アプリストアがやってくれていることも多い
- 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が重要な標準になる
