次世代 Web カンファレンス 2023 メモ
Performance
performanceについてのWeb技術
アプリのパフォーマンスについて
パフォーマンスとセキュリティはトレードオフ
低スペックなマシンでも快適に動くようにする
early hintsで返すリソースはoriginから返しても遅いのでは
CDNから返す
レイヤーが増えて複雑になってきている
ページ遷移
private prefetch proxy
ユーザーの行動をトラッキングしないといけない
プライバシーとの兼ね合いの問題
iCloud private relay
CDN経由になる
ブラウザはシングルスレッドなのでWorkerの活用は魅力的
メインスレッドの処理改善について
ボトルネックの計測
ベースラインを定めておいて、それを超えたら改善に走る
ベースラインを定めるのは難しい
パフォーマンスバジェット
ライブラリについて
hydrationが遅い
GraphQL
Qwik, SolidJS
Edge
SSG
ページが多すぎると現実的ではない
SSR
CPU負荷が高い
SEOのためにやってる
パフォーマンス指標
CWVはパフォーマンス計測の民主化
Testing
普段どんなプロダクトでどんなテストを書いているか
thinceller.icon みんなフロントエンドのテストが中心
話題
(Testing Libraryを使った)コンポーネントテストについて
テストをいつ書くか
設計の確認のためのテスト
テストが書きにくかったら設計が悪い可能性が高い
責務が大きすぎる、など
テストを書く環境を先に作っておく
実装者と別にQAエンジニアがテストを書く
ブラックボックス・ホワイトボックステスト
テストの書きやすさについて
実行しやすさ
標準出力の綺麗さ
ひな形コード生成ツールの活用
hygen
scaffdog
過去の資産
どの程度前DRYにするか
Storybook
Atomic Design
粒度に応じて内包するroleの数のアサーションをする取り組み
VRTの方針
UIライブラリを使っているのであれば細かいコンポーネントのVRTをしてもあまり意味がない
page単位などでスクショをとる
そもそも大きなスタイル崩れが許容できないかどうか
テストの実行速度
CircleCIのjob並列化
テスト実行時間の平準化
テストコードを消すことについて
flaky test
レポートを集めて分析する
RSCなどライブラリ・フレームワークの変化によってテストはどうすべきか
ブラウザテストに依っていくのでは
テストの定量評価
テストコードがあることによってどれくらい事業にメリットがあるのかどうか
QAの負担軽減
QAの人的コストとテストのコストの比較
Tooling
Viteってなに?
frontend tooling
バンドラの上に構築するベストプラクティス集と開発サーバ
担当が明確に分かれているわけではない
バンドラの繋ぎ込み
開発サーバ
CSSのハンドル周り
開発サーバのSSR周り
今走っていることで面白いこと
Rolldownの開発が裏で走ってる
Rspackののチームとコラボレーションしている
SSRのNode依存の解消
Rollup 4.0
SWCのパーサを使っている
Rollupに渡すときにtreeをバイナリ?で渡しているが、UTF-8のワーニングの場所をUTF-16の場所に変換するような関数がある
rollup/parseast
Biome
今はバンドラはあまりやっていない
LinterやFormatterに注力
CSSとかのParser/Linter/Formatter
まずはHTML Parserを優先度高くやる
その先のVue/Svelte/Astroサポートを目指す
HTMLはparseに関してもSpecがあるが、Angularとかはないよね
roadmapは来年頭くらいに出せる
ASTも一から考えている
Prettier
テンプレート系のパーサはAngularのパーサ?をフォークして魔改造して使っている
一番実行に時間がかかるのはパース部分
ツールの内部のRust化によって、ツール開発者とフロントエンド開発者の境界が明確になっていく
やる人はやるしやらない人はやらないからあまり影響ないのでは
Rustでプラグインを書くのはハードル・抵抗があるのでは
今BiomeのPRがいっぱい来ている
APIの扱いやすさを工夫している
JSでプラグインを書けるようにする、というのはやらない
バンドラはLinterよりJSのプラグインは実現しやすそう
構文木の一部をやりとりする、みたいなのがバンドラにはない
BiomeはTreeを完全に新しく作っているので既存のものを使えない
Formatterは結構適当なASTでもprintできる
CSSのfont-familyのvalue、グローバルに定義されているキーワードでなければ"を外せるが、そのキーワードはまとまって書かれていないので仕様書を順番に見ていって列挙するしかなかった
Lightning CSS
Prettierのパーサーを書き直そうとしている
typescript-eslint/parserを使っている
なんでbabelのtypescriptパーサを使っていない?
知らない
変えたい
estree互換で速さが売りの他のパーサは知らない
型情報はいらないからオーバーヘッドになっている
高速化したい
ESLint
Biome / deno lintなどはあるが意識しているか
JSのプラグインを考えると全然競合になり得ない
flat config
flat compat
各Pluginがバラバラな方法で対応している
typescript-eslintの対応方法で進めたいから待ってる
なぜ決断したのか
いろんな問題が解決する
ESM サポート
plugin側もcommonjsしか使えていない
plugin側が一番嬉しいはず
Prettierもconfigはどうにかしたい
Biomeのconfigはjsonのみ
ViteはTSでconfigを書ける
configをエントリーポイントにして一度esbuildでトランスパイルしてファイルに書き出してから読み取っている
Node.js以外のライタイムの登場の影響
Biomeは明らかにNode.js向けのLintもとりあえず入れている
pluginという概念はBiomeにはそもそもない
ESLintはむしろcoreからlint ruleを外し始めている
Biomeのバイナリは大きくなっていく一方
formatterだけ使いたいから〜みたいな要望
Prettierは内部をmonorepoにしたい
Jestみたいに(たぶんbabel-jestとか)
Prettierのembeded formatting
JS内のSQL format
prettierのimport pluginは相当やばいハック
prettier plugin tailwindも
ニーズがわかる
Frontend Architecture
クライアント寄りからサーバー寄りへ
振り子、螺旋
表示のパフォーマンス、操作のパフォーマンスの改善
SSRの遅さ、bundle sizeの遅さ
作るものの性質(要件)によって向き不向きがある
ログインが必要なアプリケーションの場合
CSRするのか
SSRするのか
表示速度改善のためにすべき
しかし、originのCPUリソースやCDNなどのインフラコストはかかる
それを費やしてでも体験を改善すべき、という線引きができるかどうか
可用性の面でSSRするようなサーバを置きたくない場合がある
自前SSRフレームワーク
ちょっとしたパラダイムシフトに対応させるコストが出せなくて、今はNext.jsを使ってもらっている
負荷試験でデータセンターを飛ばした経験
RSC
GraphQLはどうなるか
技術・アーキテクチャの実験場
事業(アプリケーション)の成長
コンウェイの法則
組織構成が変わることはだいたい良い
変化しやすいようにしておく
チームのゴールやミッションを明確にしておく
アンチパターンは何でも屋さんになってしまうチーム
横断組織の面倒をみる範囲を緩く定めておく
人材の流動性を確保