- 2024/11/23
- https://jsconf.jp/2024/
LT: UI 開発における ヘッドレス UI ライブラリの重要性とデザインシステムへの取り入れ方
UI開発の難しさ
- ネイティブアプリのようなUIを求められる
- ヘッドレスUI
- スタイルを持たないUIライブラリ
- 振る舞いは提供してくれるがスタイルは何もない
- たいていはAPGに準拠
- 従来のUIライブラリ
- スタイルも提供される
- 上書きするための労力
LT: A Tour of Anti-patterns for Functional Programming
- TAKASE Kazuyukiさん
- https://speakerdeck.com/guvalif/a-tour-of-anti-patterns-for-functional-programming
関数型プログラミング
- JSで関数型プログラミング
- 設計の勘所に使いたい
- 安全な開発にもつながる
- 例外じゃなくて
EitherやResult - エラーにも種類がある
- 欠陥があった場合にクラッシュさせるべき場面も
- Railway Structure
- fp-ts
- effect-ts
LT: Storybook との上手な向き合い方を考える
Storybookの設定
- Storybookはzero config?
- 導入はすぐ終わる
- preview.jsにいろんなことを書かないと
- メンテする覚悟をもって入れないと
- Storybookを何故使うか
- レビューの支援
- テストに使う
- Storybookでe2eはやりすぎなのでは
- composeStoryでtesting-libraryでいいのでは
- v6時代は押されていたが最近はブラウザで動かす方に注力している印象
LT: あなたの知らない Function.prototype.toString() の世界
Function.prototype.toString()
- 関数のソースコードを取り出せるAPI
- 関数の転送
- 関数はシリアライズできない
- toStringしてevalすれば使える・・？
- Puppeteerの中でそれをやってる
- ネイティブコード判定
- 組み込みの関数はtoStringしてもとれない
[native code]ってとれる- 正規表現で見れば判定できる
- 実用的な用途はない・・？
- Dependency Injection
- AngularJSで使われていた
- 引数でControllerにServiceをDIするところで使われてる
- 荒業すぎてminifyで壊れる
React への依存を最小にするフロントエンドの設計
フレームワークへの依存
- 依存が最小とは
- JSのみで書かれた部分の多さ
- Reactなしで動くコード
- testライブラリなしで動くコード
- なぜ依存を最小にするのか
- 技術選定
React CompilerとFine Grained Reactivityと宣言的UIのこれから
- ssssota (TOMIKAWA Sotaro)さん
宣言的UI
- Reactをはじめモバイルにも取り入れられてる考え方
- 仮想DOMと宣言的UI
- 宣言的UIを実現するための仕組みとして仮想DOMが使われた
- 仮想DOMのオーバーヘッド
- 仮想DOMの処理は純粋にオーバーヘッドでしかない
- 仮想DOMのツリーを探索する
- 仮想DOM自体の構築
- React Compiler
- SolidJS
- jsxを使ってるが仮想DOMは使ってない
- 状態は全てsignalで管理し更新されるとDOMを更新する
- Fine-Grained Reactivity
- 制約
- 関数は1回しか実行されない
- 算出プロパティは関数にしないとダメ
- 早期returnはできない
- Svelt5とVueVapor
- Fine-Grained Reactivity
- return書かない
- jsxじゃないから独自記法
Vapor Revolution: Unleashing Vue evolution and Potential with Vapor Mode
Vue Vapor Mode
- Vapor Mode
- vueの新しいコンパイラ戦略
- Solidに影響された
- Vueを支える技術
- Vapor Modeでどうなるか
- Vapor Modeの利点
- パフォーマンス
- 互換性
- 従来の仕組みのサブセットとして動く
- 相互運用性
- 混在させて動かすことができる
- IR(Intermediate Representation)
- データ構造やコード表現のこと
- 実行可能なコードを生成する
- 最適化もする
- ツリーで表現させる
幸せの形はどれも似ているが、不幸なプロジェクトはそれぞれの形がある
パフォーマンス
- パフォーマンスは時間の経過とともに劣化する
- 計測しておかないと何が原因かわからない
- パフォーマンス課題はどうして発生するか
- 計測してない
- 計測できると知らない
- コード量と比例しないことも
- 1箇所変なものがあるとそれで悪化する
- ドキュメントで非推奨と言われてることをやってる
- 非機能要件に対する指摘が言いづらい環境
- パフォーマンスと機能追加
- 中身がないのが一番はやい
- でも機能を追加していかないといけない
- バジェットを食いつぶしていくということ
- 想定することはできないから計測する
- 推測するな計測せよ
- フロントエンドの計測
- 合成モニタリング
- 開発者のPCでスロットリング入れて
- Web Vitals
- Lighthouseで計測
- コードは見ない方がいい
- 思い込みがない状態で外から最初ははかる
- Devtoolsと解析を繰り返す
- 合成モニタリング
- Lighthouse
- FCPはサーバが重いことが多い
- LCPは非同期のラウンドトリップの問題
- TBTはバンドル処理
- CLSは初期画面のCSSのガタツキ
- SpeedIndexは合計なので見なくていい
- LCPを追っていく
- Lighthouse的には2.5sで100
- Devtoolsでどれが重いかでるが、それを出すまでの過程に問題がある
- Performanceタブで見ていく
- 縦のかたまりがどれくらいあるかその単位で見る
- Networkタブ
- sizeとtime
- 重そうなやつをブロックして計測してみる
- 3rdpartyブロックするとか
- webfont本当に重いのかとか
- SourcesタブのOverrides
- ファイルを置き換えられる
- 空配列にしてみて計測とか
- ソースコード解析
- 問題を絞り込んでからソースコードに入る
- CPPU/Network/RTT
- 最小のコードで再現するものを作る
- 計測手段
- console.log
- console.time/timeEnd
- Date.now
- performance.now
- debugger
- ひたすら探索して特定していく
- ライブラリの中のこともあってそれは大変
- そこまで特定してコードを改善していく
- 問題を絞り込んでからソースコードに入る
LINEヤフーにおけるPrerender技術の導入とその効果
- Masanari Hamadaさん
- Tomoki Kirakuさん
- https://speakerdeck.com/narirou/lineyahuniokeruprerenderji-shu-nodao-ru-tosonoxiao-guo
先読み技術
- Webの先読み技術
- 行動を予測して先回りすることを模索し続けている
- preload
- linkタグに先読みするコンテンツをセットする
- それがないと成り立たないものにつけて優先して読み込む
- prefetch
- 次のページで必要なものを読み込む
- HTTP Cacheに保持させる
- Private Prefetch Proxy
- crossoriginでやるとどこを見てたか伝わってしまう
- 匿名化したサーバを返す仕組み
- Speculation Rules API
- 元はprerenderだったがjs処理が必要なのでこれに変わった
- 宣言的に条件を書く
- どの要素をどのページで先読みするのか
- ページの描画やjsの実行もされる
- ログなど注意
- prerenderの場合の振り分け等必要
- Sec-Purpose:prerenderヘッダ
- document.prerendering
- prerenderchangeイベント
- 導入テスト
- ヤフートップのニュースリンクで検証
- 読み込み速度は6.9%改善
- CTRや広告への寄与はなかった
- iframeは先読みできないので広告にはきかない
- prerenderしたけど表示されなかったケースが85%
- アクセス増に対して予測される増強が大きかった
- 密集したリンクはマウスで迷ってる時に発火してしまう
JavaScriptのモジュール解決の相互運用性
相対パスのimport
- ESM/CJS
- ESMなのに拡張子省略できるパターン
- importだけど中身はcjs
- next/angular
- emsだけど省略できる
- vite
- importだけど中身はcjs
- TypeScriptとESM
- importに.tsと書くかどうか
- ts5.7で.tsを.jsに書き換えるオプションができた
- バンドルされて動くなら.tsと書いていい
- import path alias
Web標準の進化を止めない！Baselineというブラウザサポートの考え方
- Mariko Kosakaさん
Web標準
- 新しい機能がたくさん出ているが全ブラウザ対応しないと使えない
- 新し目のものを使う時にわざわざ確認しないといけない
- The interop project
- ブラウザベンダーや開発に履いている企業が集まる場
- 次に何をやっていくか足並み揃えるために話し合っている
- 年単位で次どうするか決める
- それを実現するテストがあって進捗状況が見られる
- とは言っても本番で使えるか考えるのは大変
- caniuse見る？mdn見る？
- 開発者みんなチェックしないと
- gapがgridでは使えてflexはダメだったとか確認ミスも
- Baseline
- Baselineの情報源
- Baselineのチェック
- Lintとか
- PR出した時にCIでチェックとか
