HTML Conference 2018 メモ

[kdnk]

HTML Conference 2018 のメモ

[kobayang]

React製SPAにおけるパフォーマンスチューニング

#html5 https://speakerdeck.com/maxmellon/reactzhi-spa-niokeru-pahuomansutiyuningu @maxmellon_9039 `pipeline-operator` 圧倒的なユーザー体験 - パフォーマンス - リッチな表現 - オフラインでの動作 SPAにおけるパフォーマンス - 初期レンダー - SEO ユーザーの入力に迅速に対応する BFF redux-pluton AirSHIFTの話 シフト表の作成 **シフト表の切り替えに時間がかかっているという問題があった** ボトルネックのほとんどが Scriptiong Rendering -> HTMLのレンダー時間 Painting -> CSSの適用時間 - **真因を特定するまで**計測ことが重要 ## 調査方法 - Scriptingの内訳をみる - 関数のコールスタックを調べる - React内部で何が起こっているかを調べる - DevTools - Performance Profiler - React Dev Tools - Hight Update - Profiler - Network Taming - **User Timing** - ある点からある点までの処理時間が入れる - React 16から - 何もしなくても見られる ## 真因を特定するにはまだ課題があった - ユーザーの操作とComponentのレンダリングの関係性がわからない - 何がきっかけに再レンダリングされているかわからない - reduxのmiddrewareにした - アクションとComponentのレンダリングの関係が調べられる - どの操作で何がレンダリングされたかがわかる ## 改善のアプローチ - 処理時間を減らす - 関数の処理時間を短くする - メモ化 ( `reselect`, `memoize` ) - 計算量を地道に減らす - **無駄な処理をしない** - 呼ぶ必要のない関数を呼ばない - 無駄に新しいstateを返さない - **reduxの設計を見直す必要があるので難しい** - Reconcilation - 仮想DOMのTreeをCheckして実DOMに適用するか計算 - Reconcilationを減らすアプローチ - 木構造を小さくする - `react-virtualized` - 描画範囲外Unmount - スクロール方向を見てMount - 不要なReconcilationをしない - shouldComponentUpdateをかく - コンポーネントを小さく区切る - 技術的に難しい要素が少ない - propsが小さくなるので、`React.memo` - **FatなComponentはダメ** ## なぜヒアリングまで発覚しなかったか - CPUの処理能力がすごく低かった - 顧客の環境でパフォーマンスは計測しなければならない - Dev toolsで仮想的に調べられる - Fast 3G - x4 slowdown ## 楽に shouldComponentUpdate したい - PureComponent - recompose/pure - React.memo - 基本的に全て shallowEqual してくれる - `fbjs/shallowEqual` - React.memo - $$type を書き換えて内部の updater のロジックを差し替えてる - *ちょっと早いんじゃないか？* `shouldComponentUpdate`で速くなるのは `rendering`ではなく、`scripting` `Paperpeer` - 操作を記録しておいて、エミュレーションしてくれる

[kobayang]

コンパイルターゲット言語としてのWebAssembly、そしてLINEでの実装

#html5 @uta__tti # Agenda - プログラミング言語をつくるとは - Wasmをターゲット言語*にするWEB言語の設計 *コンパイラがコードジェネレーションとして吐き出す言語 - Wasmバイトコードを生成するコンパイラの作成 - LINEでの実践 ## プログラミング言語を作る ### なぜ作る必要があるか？ - Wasmのコンパイルターゲット言語としての可能性を調査 - Wasmに直接コンパイルする(v.s. LLBM IR) - Webで使う場合 - 容量を減らす必要がある - ユースケースを考慮した設計 - ユースケースとはどんな？ ### 作った - 言語を設計する - 機能と文法を決める - GCは？メモリは？Call Chainは？ - セミコロンはいる？ - 想定しているユースケース - 好み - **好みは重要** - どういう言語を作りたいか - 他の言語のいいところを考えてみる - 楽しい - 設計を形にする - EBNF (Extended Backus-Naur form) - 他の言語の仕様書を読むといい - *Goはおすすめ* - 言語のコンパイラをかく - コンパイラフロントエンド - Lexer - 意味を持つ最小単位 - Token stream - Parser - Token stream -> AST 変換 - Parser generator - EBNF to Parser - Parser combinator - Parser を組み合わせて Parser を作る - Parsec in Haskell - DSL for parser - Desugarer - sugar syntaxの解除 - AとBが同じ - Type checker - Semantic analyzer - **Hindley-Milner type system** - *Typescriptの型推論とかの勉強になりそう* - コンパイラバックエンド ### Wasm - Stack machine (v.s. Register machine) - Value Type - Integer - i32, i64 - Floating-point number - f32, f64 - Complex types - Tuple - Array - Wasm memory - Linear - Virtual - 実際のメモリとはマッチしない - JS, Wasm でメモリを宣言 - (memory 1) - Memory allocation - 手動で管理するしかない - Memory freeing - しない - GC, Reference counting, Handling memory fragment - *自分で書こうとすると大変* - そこまで必要ない ## LINEでの実践 @kawasako **WASMをどうやって使っていくか？** - 大量の演算が必要な時 - YOKIMOCHI - 社内プロダクト - Web Tracking System - Wasmで圧縮/解凍 WASMでENCODER, DECODERを実装

[kobayang]

Tech Feedのつくりかた

#html5j - Angular - Ionic - Ionic4への移行が難しそう ### UIフレームワークのジレンマ - エンジニアにとってGood - それなりのUIにできる - デザイナーにとってはBad - デザインの自由度が制限される - カスタマイズが不毛、工数かかる - 良質なコミュニケーションしか解決策はない - デザイン段階でコンポーネント化すべき - どう実装するかの話 ## Cordovaは不可欠だが辛い Capacitarは代わりになり得るもの？ - ReactNative - - 黒魔術化していないものがない ネイティブとのUXのズレがある ## サーバーサイドTypescript Node.js モノリシック Loopbackというフレームワークの上で構築 - NestJS - TypeORM Clasp GASをローカルで使える TypeScriptに揃えることで、サーバ側とクライアント側のAPI Callの記述が統一できる。（らしい） サーバー側 `function CatsApi.create ` クライアント `await CatApi.create()` 同じ感じでかけて良さそう 何回も「銀の弾丸はない」と言っていたのが印象的だった

[kobayang]

アクセスビリティ、はじめよう！

#html5 ## アクセスビリティとは？ A11y 色々な人が色々な状況でアクセスできるもの ユーザビリティ 特定のユーザにとっての使いやすさ ユニバーサルデザインとの違い 一つのものをみんなが使えるようにすること ## 色々なツールを使うことがある - VoiceOver ## 使う？使わない？ WCAG2.0, 2.1が今出てる レベルA, AA, AAAがある - レンダリング結果を使うので、Javascriptを使っても大丈夫 - 離れた部分が変化してもわからないことがある - エラー表示、ポップアップ、タブ切り替えなど - インクルーシブHTML - 一から始める - デザイニングWebアクセシビリティ

[kobayang]

光を超えるためのフロントエンドアーキテクチャ

#html5 https://speakerdeck.com/mizchi/guang-wochao-erutamefalsehurontoendoakitekutiya あまり綺麗にまとまってない。。。 ## Agenda 16msの壁がある -> なんで16msかと思ったら、60Hz -> 1/60 -> 16ms - 16ms 以上の世界 - Cache Aware - 16ms 未満の世界 - マイクロチューニング - 設計パターン VR: 90hz ~ 人間: 70~100hz Ref. フリッカー融合頻度 フロントエンド技術の目標をどういう風に設定するか？ 小さいスコープ 大きな視点 通信を発生させたくないけどしたら最小限に抑える --- ## 16ms以上の世界 CDN Edge で構築済みのHTMLを返す CDN Edge は賢くない - KVS + α キャッシュの扱いは難しい CACHE AWAREの設計 サーバーは更新系に合わせてInvalidateをする GET 更新系は何らかのフック ### 勘所 キャッシュにセッション依存情報を使わない セッションに依存するViewはLazyに 副作用があるなしでむちゃくちゃ気をつける必要がある モナドみたいな構成になる - Varnish Surrogate Keys - ORM Hook -> ActiveRecord after save Edgeが複雑だったらEdgeを賢くする PRELOADING - w3cにpreload - resource-hints - HTTP/2 Server Push - NEXT.JS `

[kdnk]

2018-11-25 webassemply

## プログラミング言語を作るとは - なぜ - LLVM を経由 - 容量をへらす - ユースケースを考慮した設計 - https://github.com/uta_tti/kou ## 作る - 言語設計 - 機能と文法を決める - 想定しているユースケース - このみ - 型安全 - Braces over indents - パースしやすい - expression-oriented - すべてが式である - ユースケース - Wasm - バイトコードの容量を小さく - 想定は js 開発者 - 設計を形に - specification - EBNF - 他の言語の仕様書を参考に - コンパイラをかく - Lexer - 構文解析 - Parser - Token → AST - Parser generator - EBNF → Parser - Parser combinator - 小さいのを組み合わせて、Parser をつくる - Or just write from scratch - Desugarer - Syntactic suger - Type Checker - 静的解析 - Hindley-Milner type system - App - Code gen - AST → Target code - Wasm bytecode - Stack machine - jvm など - i32, i64, i32, i64 - vs. Register machine - Complex machine - Memory - Liner - Virtual - Memory allocation - 手動管理 - Memory freeing - しない - GC - Reference counting - Handling memory fragment - - ユースケース的に必要ない - Wasm Code gen. tip ## Wasm をターゲット言語にする ### WB 言語の設計 ## Wasm バイナリコードを生成する ### コンパラの作成 ## LINE ### FRONTEND-STANDARDIZATION ### WASM をどうつかっていくのか - 大量の演算が必要なとき - 実験的な意味合いも強い - 社内 Product - 可視化ツール - ユーザがどこをどれだけ触っているのかのデータは膨大 - データを独自の形式に圧縮/解凍 - やること - エンコード - x, y, value - 行列に変換すると、x, y はいらない - 歯抜けのデータができる - 圧縮できる zip とか - 元データ - WAT の場合 - about 600 lines - kou - about 70 lines - 成果 - 1.4mb → 255kb - 1/5 まで圧縮 encode 処理よりも 3 ~ 4 倍高速 - 所感 - 中で何をやっているのかは、想像しやすい - wat 書くよりはるかに楽 　- log ほしい - Uint32Array - 大きな動画とかだと、メモリを食い過ぎる - wasm 使いたいモチベーションと相反

[kdnk]

2018-11-25 web components

https://speakerdeck.com/aggre/realistic-web-components?slide=21

- webcomponents.js - shadow dom は完全再現できない ## 近況 - custom elements - shadow dom - html templates → ▲ - html import → es modules ## 基本 - ハイフンないとエラー - HTMLElements を継承して、class 定義 ### custom elements - callback 機構を備えたクラス - costructor - connectedCallback - テンプレートの挿入など - disconnectedCallback - attributeChangedCallback - adoptedCallback - あんま使うことない ### shadow dom - attachShadow - mode: open or close - close は基本的につかわない - dom がカプセル化された状態に - css が簡単に - Shadow dom を持つ要素は小要素を表示しない - slot 要素があると、消えた要素がそこに割り当てられる - attribute を渡すと部分的にレンダー - slot - shadow dom ないから、外側の要素を操作できる - ex - プロジェクトを超える - プロジェクトを超えて、共通の実装をまとめることができる - コンポーネントライブラリ - iron-autogrow-textarea - pinch-zoom - ライブラリ作者は、web-components でつくるといい - https://www.webcomponents.org/ - 共通コンポーネント - micro frontend - micro service をフロントエンドに - ex. web components に react を隠蔽できる - ページの関心と、記述の関心の分離 - ssr - ssr 済みの html を hydrate(仮想 dom の作りなおし？) - shadow dom と slot で hydrate なしにできる - 実装を標準で出力 - 使えるところで使うべき ## 使い所 ## 現実的な開発 - 主な手法 - vanilla - lit-html - lit-html アプリを web components にする - lit-element - angular/vue ### vanilla - 疲弊する - ゼロ依存なので、軽い・見通しがいい ### lit-html - polymer で登場 - 軽量なテンプレートライブラリ - html, render, directive という API を持つ - tagged template literal でテンプレート生成 - 仮想 dom のような動き - 変わらない部分は、DOM の再描画をしない - lit-html が勝手にやってくれる - @Event - @click - ?attribute - ?clicked (boolean とか) - .property - .myFunc - まとめ - lit-html 使うと便利 - 属性値が文字列に - テンプレートだけを lit-html にするメリットはあんまない ### lit-element - `extends LitElement`する - TypeScript Native - lit-html の利点を持ち込める - web compoennts のライフライクル - デコレータ便利 ### lit-html でアプリを書く - クラスが出てこない - テストしやすい - すべてが関数 - FP 好きならおすすめ ### fit-html - redux + lit-html ### directive - render から独立した更新処理がかける ### lit-html, hyperHTML, htm の違い - lit-html - html template instantiation - polymerlabs/template-instantiation

[kdnk]

2018-11-25 Performance by mizchi

## more than 16ms - CDN edge = kvs + a - cache aware - cache がいっぱいある - 参照系 = kvs - ### 設計 - セッションがあるものは lazy に - 集合 - 一個更新されたらすべて捨てる - 副作用 vs 純粋関数 - 複雑？ - Fastly: Varnish Surrogate Keys を使う - ORM フック - 複雑さに対応すればいい - AWS Lambda@Edge - CloudFlare Workers - Fastly Cloud Platform - CDN = Redis, Server = mysql ### preloading - 単純に対象を `fetch(endpoint)` 飛ばしておくだけでも効果はある - ブラウザ cache にのるので - Guess.js - https://github.com/guess-js/guess - ユーザ数がある程度ないと機能しない - をヘッダに挿入 - dev.to - onmouse した瞬間に fetch - 賢い先読みはコストが掛かる - preload を頑張って書く - 副作用を分離した綺麗なコート ゙ を書く => キャッシュ破棄が予測できる 😇 ## less than 16ms - インメモリ or background - 泥臭い micro チューニング ### 初期化 - react + dom の展開で 1 秒とか - lodash, moment とか - javascript を eval する時間を削る - 手段 - ES2015 Dynamic Import - ie で動かない - Webpack: Code Spritting - javascript を分割 → dynamic import 風 - Webpack: Dead Code Elimination - tree shaking - 大体は効かない - prepack - レイアウト抑制 - 再計算が走る - ガタッ」や「ピクッ」という悪体験 - スケルトンスクリーン - AMP に学ぶレイアウト抑制 - CSS は全てインライン化 - キャッシュヒット率が落ちる - クリティカルパス - header が大事 - 高さと色があっていればなんでも ok - 初期化遅延/オフスレッド処理 - WebWorker #### スクロール & レイアウト計算 - スクロールのために再計算 - 広告とか - shouldComponentUpdate とか ### 低遅延環境の為の設計パターン ### 楽観的 UI - Like Button とか - ログインとか ### クライアントファースト設計 - クライアントがあって、サーバがあるという発想 - 自己完結しているときは使える - ゲーム・ツールとか - firebase と相性がいい - 改ざんに弱い ## OFF THE MAIN THREAD ### フレーム最適化 ## ref https://mizchi.hatenablog.com/entry/2018/04/15/011520

[kdnk]

2018-11-25 amp

## amp - JavaScript をつかわない ## Components ### web components - amp-carousel - amp-form - amp-bind - page 上に state - amp-list - amp-cache - 任意のエンドポイントにアクセスできる。cache を経由せず。 ### Responsive - layout 属性 - layout: fix, layout: responsive, layout: fill - srcset - media query - 宣言的に書くほうがきれい ### New Components #### コンポーネントたち - amp-lightbox-gallery - https://www.ampproject.org/docs/reference/components/amp-lightbox-gallery - amp-image-slider - amp-date-picker - airbnb が amp に置き換えた？ - amp-date-countdown - amp-google-document-embed - advanced-video-docking - youtube みたいにスクロールすると動画が移動 - amp-next-page - document page の 無限スクロール - 記事を読み終わると、次の記事がでてくる - multi page application でも、無限スクロールの恩恵を - amp-stories - facebook / instagram の ストーリー - きれいなものしか出せない - amp-inputmask - 電話番号、クレジットカード - 正規表現的なものをかける - amp-fx-collection - scroll-triggered-fadein - What's new in AMP, Q4 2018 にまとまっている ### LP だけじゃない - 一休 https://www.ikyu.com/kyoto/ ### PWA - service worker にも対応 - amp-install-serviceworker - workbox? ### One-line PWA ### Things to fix - url - google.com/amp/www.example.com からはじまる - 治せるようになる - signed exchange - ドキュメントに署名　& 署名元のオリジンで表示 - ブラウザはオリジンで表示できる - dev preview がでている - dev tool でも確認できる - js が使えない - amp loves JavaScript - TypeScript でかけるようなチューニングも始まっている - main thread で動かしたくない - Worker DOM - web worker で script が動く - DOM API がないので、使い道がない - DOM API を web worker 側に再構築 - React in amp も可能に? - ampscript - 制限はある - prevent default とか実装できないとか - bit.ly/jsinamp - amp conf 2019