PWA Night Conference 2022
ライブ URL
Aトラック
https://youtu.be/m4TUdXTAukc
Bトラック
https://youtu.be/prHiwKGZQYI
イントロダクション
oVice の使い方ツアーよき
ジョブボード、採用につながるのでやりたい
運営はひと目で分かるようにアイコンを統一
オープニング
オープニング映像があるとクールで盛り上がる
Enjoy the Future がテーマ
PWA とは言っているが PWA に限定しない
StreamYard を使って配信している
Slido でアンケート → 最初にやるのがちょっとしたアイスブレイクにもなって良い
質疑応答は Twitter ハッシュタグでも受け付けるスタイル
行動規範の定義大事、身内以外の人が増えてくると特に
基調講演: Enjoy the Web / 原一成
CyberAgent のテックリード
最初に Web に触れたきっかけは90年代
VAIO のコンピュータで FrontPage 書いてた
テックリードとして大事にしていること
参考：フロントエンドエンジニアの価値はどこから生まれるのか
フロントエンドの区別は難しい → 明確に決まっているものではない、人の手で境界づけられる
バックエンドの余り物がフロントエンド
フロントエンドは不確実性の塊 → 変化が早く複雑で難しいのは必然
いち開発者として大事に思っていること
変化を前提とした個人スキル
フレームワークを使える、けどフレームワークに依存しないスキル、コラボできる
英語も掛け算できるコラボスキルの一つ
テックリードとして大事に思っていること
ポートフォリオ → Stable が70%、Transition が20%、Challenge が10%
Ameba ブログのフル刷新
トラディショナルな構成がボトルネック
チャレンジしつつ標準化 → Isomorphic、Lazy Load、HTML Server Cache
リスクを下げるため人気のライブラリを採用 → React、Redux、Express
AmebaNews のシステム改善はリターンが見込みにくかったため、管理しやすい構成に変更
デスクトップとモバイルで構成が異なっていたものを統合
SPA vs MPA → 当時の AmebaNews だと違いがあまり感じられないため MPA にした
こえのブログは作りきり寄り (運用発生しない前提)、チャレンジング
PWA でネイティブアプリっぽく動く
Web Components や WASM を利用
新しい学びが多かった
Now 今取り組んでいること
生産性の向上
CMS の利用
編集者とデザイナーとエンジニアでうまく分業できずにいた → 余分なコミュニケーション発生
microCMS を利用して CMS でページ量産
デザイナーがデザイン → エンジニアがコンポーネント / 関数を作成 → 編集者が CMS 上でブロックを定義 / 並び替え
作業が重なり合わないためスムーズ
リリースまでのリードタイムが7日軽減
shopify も活用
デザインシステムにも投資
デザイナーとエンジニアで「何が正しいか」が分からない
色と状態をすべて定義
ブランドを体現するためのデザインシステム
らしさ BRAND / 届け方 ING
Spindle UI という名前で公開
実際の開発の様子は Web+DB Press vol.127 で公開
専門性を高める取り組み
個人メリットも組織メリットもある
「Yatteiki」という名前で業界スキル習得、3ヶ月ごとに実施
Ameba アクセシビリティガイドラインを定義、定期的にアップデート
ログから CLS 改善 → Web Vital JS でコンポーネントを調査して対応
デプロイのしやすさも整備
Future 気になる技術 (Web App 方面)
PWA ではなく AWA (Advanced Web App)
Instant & Seamless Navigation 快適なナビゲーション
View Transitions
かつて Shared Element Transition とか Page Transition とか呼ばれたもの
また変わるかも
Project Fugu API Showcase
Web UI
Open UI、Dark Mode など
CSS だと Container Queries (従来 Media Queries でやっていたもの)、Cascade Layers、Viewport Units、:has など
エンジニアの技術は年輪みたいなもの
t-wada さんが紹介していた名言 → 限りなくシンプルなデザインというものはなかなか教えられるものではない
質疑応答
スピードが早い中で Challenge にどう対応していくのか、がチームの課題だが...
チームにとって共通の課題となっている技術にフォーカスしてちょっとずつ学んでいく
フレームワークを学ぶというより、フレームワークが解決している課題が何か、1段深堀りする
フレームワークに依存しないスキルにつながる
この技術が伸びそう、この技術は伸びなさそうという嗅覚、軸みたいなものを知りたい
経験則と、どれくらいシェアがあるかなど
また、そのチームや人によって何が良いかは変わるため、トレンドに合わせていくかプロダクトに必要なものを選択していくか決めても良い
技術を選ぶときはその人のモチベーションにも関わるため、そこが結構重要だったりする
最新技術はどれくらいの頻度でキャッチアップしているか
頻度はない
Twitter 見ていると流れているのでそういった意味では毎日
頭の中やメモなどに残しておいて、面白そうだなと思ったら詳しく調べる
Yatteiki について詳細を聞きたい
リーダがテーマを3つ決め、参加者が自分でテーマを選ぶ
やりたいことを自分で決めて取り組むので、変えたかったら変えても良い
「今度はパフォーマンスやってみようかな」など
スポンサートーク
あらかじめ用意していた動画を流すスタイル
その場で話すとグダったりする可能性もあるためか？
ウェブサイトに魅力ある演出を！JavaScriptライブラリ「GSAP」の活用術 / 池田 泰延
今日話すのはクリエイティブ系ウェブサイトの技術
アニメーション
標準機能
CSS Transition
CSS Animation
Web Animations API
animate 関数や、愚直に時間経過で style に属性更新など
GSAP や Anime.js なら複合モーションの統合管理や DOM 以外への適用 (WebGL など) も可能
ライブラリ
GSAP、Popmotion、Anime.js など
GSAP (Green Sock) にフォーカスして紹介
パーティクル4万でもフレームレート50出る (ヌルヌル)
GSAP はパフォーマンス高い
活用箇所
Google マップのローカルガイド
イラストを動かしているところが GSAP の技術
利用していることが Wappalyzer で分かる
ICS MEDIA
どれくらい使われているかで言うと、国内で34.3%、海外で46.5% 利用している
ライブコーディング
gsap.to('.rect', {x: 1000, duration: 4})
x軸方向に動かす
.to ではなく .from にすると逆方向にできる
stagger: 0.1 とすると複数要素をずらせる
ease: 'expo.out' でゆっくり終わる
スクロール連動演出
スクロールで発火する手法
カロリーメイトのサイト
スクロールに連動する手法
muraflex のサイト
パララックスエフェクト感
スクロールに連動し、固定させる
BLUE HAMHAM
ScrollTritter.create({ trigger: '.likeButton', start: 'top center', toggleClass: 'is-active', once: true, markers: true })
パーティクル演出
tl.from(dot, {...})
random にすれば疑似乱数で一様分布
パーリンノイズというものを使えば規則性のある乱数を生成できる
直前の乱数に近い乱数を得られる
月曜日に記事配信予定
十数年続くライブラリ
GSAP は昔は TweenMax という名前だった
Flash 時代から存在
Google Trends を見ても anime や tween より人気
独自ライセンスのため注意 → 多くのケースでは無料だが、課金コンテンツでは有償
一過性のものにはなりたくない、という想いから更新が続いている
ユーザの意見を反映するため、ユーザ出資が適切と判断し、その上で継続的で一貫性・信頼性のある品質に取り組んでいる
解説ビデオなど、学習コンテンツも充実
Dive into Cloudflare Workers / 和田 裕介
Cloudflare Workers はエッジで動く、スーパークラウド Glue としての役割、小さく高速、デプロイが簡単
D1 = SQL が CDN でエッジで動く、最近オープンα版が出た
Hono というフレームワークをりようすると D1 が使える (和田さん作)
Deno、Bun、Express で動く
cdnjs につながる
npm i -D wrangler → wrangler init -y
設定ファイル1つでデプロイできる
npm deploy でデプロイ完了
Hono を使えばベーシック認証も楽
wrangler d1 create <project-name> でデータベース作成完了
wrangler d1 execute <project-name> --file file.sql でファイルを実行
React エコシステムはこれまでどう変わってきて、これからどう変わっていくか / 大岡由佳
今後のトレンドを見極める目を養うことが目的
React 17 は18のための踏石、準備的バージョンでありメジャーリリースなのに新機能なし
ロジックの書き方の変遷、mixins → hoc → render props → hooks
Meta に常勤担当者がおらず、CRA プロジェクトは既にメンテナンスモード
人気ライブラリが複数あってどれ使えば良いのか
Next: 飛ぶ鳥を落とす勢い、SSR、SSG、ISR
Remix: SSR 専用、サーバの挙動を細かく制御可能お
Redwood、Blits: Rails に触発された、ORM まで含むフルスタックフレームワーク
Gatsby、Astro: 静的サイトビルダー
Meta やばい：cambridge Analytica 事件、ブランドイメージ低下、主要プレイヤーの退社、業績低迷、リストラ
状態管理どうすればよいか
使わない：Context API のみ、もしくは useReducer を組み合わせて頑張る
Flux アーキテクチャ：Redux、シンプルが良いなら Zustand
Atom アーキテクチャ：Recoil、書きやすさなら Jotai
クエリキャッシュとして使う：TanStack Wuery、シンプルが良いなら SWR
情報収集なら
This Week In React がおすすめ
Twitter の @sebastienlorber の方を見ても良い
State of JavaScript
JavaScript ライジングスター
npm trends
あとは Chrome のニュース
質疑応答
React が選ばれる理由は何か
もともとはコンポーネント指向を広めた存在であり、選択されていた
関数だけでコンポーネントを書けるようにしたりと、開発者心をくすぐられる
有名プレイヤーたちを巻き込んだりして話題集めもうまかった
もし React を見限るとしたら
React (笑)
Deno Fresh、Preact を注視している
後悔しないデザインシステムの始め方 / takanorip
デザインシステムを始めるときに考えたい5つのこと
解決したい課題は何？
デザインシステムを始めるとプロダクトが良くなる？
誰のためのデザインシステム？
運用・浸透施策は？
ROI はどれくらい？
解決したい課題は何？
目の前の課題の解決に集中する
他社のデザインシステムを目指さない
大きすぎる目標は続かない → 小さい課題解決を積み重ねる
Ubie の場合、独立した色々な要素があった → UI ガイドライン、デザイントークン、コンポーネント、ボイス&トーン、デザイン原則・思想
それらをまとめて Ubie Vitals という名前でデザインシステムとした
デザインシステムを始めるとプロダクトが良くなる？
どうユーザに還元されるのかを考える
デザインシステムはあくまでプロダクト・品質向上のための手段
誰のためのデザインシステム？
使われないデザインシステムはすぐ腐る
きちんと使われるシステムをつくる
運用・浸透施策は？
浸透・運用されて初めて効果を発揮する
つくることをゴールにしてはいけない
あらかじめ浸透施策を考えておく
ROI はどれくらい？
デザインシステムは直接お金を生むプロダクトではないため ROI を検討すべき
ROI を考えないと、どれくらいリソースを透過すべきか議論ができない
また、プロジェクトの中での優先度も考えられない
デザインシステムを始めなくても良いケース
現状困っていない、困る予定もない
プロダクトが小さい、変化がない
課題を解決する How はデザインシステムだけではない
デザインシステムは「○○らしいデザインを構築するためのシステム」 i.e. 「○○らしいデザイン」が確立していない状態でつくれない
Webパフォーマンス高速化とこれからのアーキテクチャ / 浜田 真成
Core Web Vitals は変化を前提とした値
変更がある場合は Chrome Speed に ChangeLog が掲載される
2021年の ChromeDevSummit では Smoothness (滑らかさ)、Responsiveness (応答性) が追加される予定と発表
2022年に INP (Interaction to Next Paint) を追加
ユーザの入力に対して反映・反応が終わるまでの時間を表した指標
75パーセンタイルのスコアで 200ms 以下の値が良好とされている
INP はアプリケーションが存在する間ずっと計測され続けることになる
これからのパフォーマンス指標で重視されることは UI/UX
滑らかさ・応答性の考え方からも分かる
初期表示が早いことではなく、快適な操作性
考慮しておくべきパフォーマンス指標
ユーザに近いキャッシュ戦略
リソース取得優先度の最適化
メインスレッドからの分離
ユーザに近いキャッシュ戦略
ブラウザ (Service Worker / Storage / Local Cache) ←→ CDN Edge ←→ App
ユーザに近い位置、すなわちブラウザに近いところでキャッシュした方が高速に返却できる
Edge Workers: CDN Edge で関数を実行し、柔軟に動作を定義できるようになった
edge-function の機能を Next に統合
BFCache: ブラウザの戻る・進むを行ったときに local cache から読み込む
Private Prefetch Proxy: 先読みの技術、遷移先を先に読み込んでおく
これまで同一オリジンだと Guess.js などがあった
クロスオリジンの場合はセキュリティが課題だった
CONNECT Proxy という匿名化されたサーバを用意しておいてキャッシュさせる
リソース取得優先度の最適化
順序を最適化させるのが重要
ブラウザにより最適化が進んでいる (自動でやってくれる) が、ブラウザが判断するのは取得したデータをパースした後
その前にやるのが Priority Hints という技術 → <img src="..." fetchpriority="high"> のように書く
これまでにもあった ResourceHints と異なるのは low も指定できる点
103 Early Hints: リソースの先読み情報を返却するためのリクエストを返す Web 標準仕様
メインスレッドからの分離
ブロッキング (Long Task) をいかに減らすか
Service Worker によるサードパーティスクリプトの実行
Partytown というライブラリ：3rd-party script を ServiceWorker 内で実行
React 18 からはストリーミングサーバレンダリングが登場
Suspence と React Server Components を使うことで部分的なレンダリングが可能になる → クエリコロケーションの考え方が広がっていく
Yahoo の取り組み
実際にやっている取り組み → Priority Hints の導入、BFCache を有効化
Priority Hints の導入で AB テスト
A パターンでは LCP 対象画像に importance="high"
CT パターンでは <link rel="preload"> で先読み
結果、有意差なし
BFCache の有効化
一覧と詳細を行き来することが多いため、かなり期待できる
しかしキャッシュが有効課される条件が複雑
unload イベントハンドラを使用していたり、読み込みが完了していない iframe が存在すると無効化されてしまう
1つのサブフレームでも上記の条件に当てはまると BFCache が使えない
今後の方向性に向けたアーキテクチャも色々考えている
private prefetch proxy、Glanular Chunking、React Suspence、Server Components、Relay Graph QL によるクエリコロケーション、etc.