JSConf JP(2024)感想

参加したセッション※ライブ配信

トラックA

• React Server Componentsとは何であって何でないか
• Web標準の進化を止めない！Baselineというブラウザサポートの考え方
• Sponsor LT x 12

トラックB

• LT: Promise.try: シンプルで強力な同期/非同期統合の未来 - 実装の深層とPromiseの進化
• LT: JavaScriptを支えるエコシステム（漫才）
• LT: romajip: 日本の住所CSVデータを活用した英語住所変換ライブラリを作った話
• LT: ステップバイステップで進めるYahoo!知恵袋のフロントエンドリアーキテクト
• React への依存を最小にするフロントエンドの設計
• React CompilerとFine Grained Reactivityと宣言的UIのこれから
• Vapor Revolution: Unleashing Vue evolution and Potential with Vapor Mode
• 幸せの形はどれも似ているが、不幸なプロジェクトはそれぞれの形がある
• リアルアセットとWebのシームレスな活用のためのパスキー
• JavaScriptのモジュール解決の相互運用性
• Modular Monolith Monorepo
• JavaScriptのイテレータとイテラブルの概要と課題、未来

トラックC

• LT: UI 開発における ヘッドレス UI ライブラリの重要性とデザインシステムへの取り入れ方
• LT: A Tour of Anti-patterns for Functional Programming
• LT: Storybook との上手な向き合い方を考える
• LT: あなたの知らない Function.prototype.toString() の世界
• You Don’t Know Figma Yet - FigmaをJSでハックする
• 30 Minutes to Understand All of RegExp Syntax
• LINEヤフーにおけるPrerender技術の導入とその効果
• ESLintのカスタムルールで治安維持活動をする
• @effect/schemaによる型安全な軽量DDDの実践

感想

React Server Componentsとは何であって何でないか

• React Server Componentsはアーキテクチャ名
• サーバー側におけるコンポーネント志向データフェッチを実現するもの
• Next.js固有のものではない
  • Next.jsが先行して実装していた

Web標準の進化を止めない！Baselineというブラウザサポートの考え方

• subgrid
• interoperable
  • 全てのブラウザで使える
• The interop project
  • ウェブ機能のinteroperabiltyを増やすプロジェクト
  • web-platform-test
• Baseline：W3Cが規定
  • Newly available
    • 最新のブラウザバージョン、プラットフォームでサポート
  • Widely available
    • 機能がコアブラウザでサポートされてから30か月経った
  • Limited available
    • まだブラウザ互換性がない
• web-features
  • 機能をまとめて定義を作成
• browser-compad-data
  • 自動で各ブラウザの状況を循環して、機能の状況をアップデートするためのプルリクが作られる
• Web Platform Status
  • http://webstatus.dev
• <baseline-status>component
  • 今のBaselineの状況を埋め込んで表示できる

Sponsor LT x 12

• Nuxt.jsとNext.jsを混在させたい
  • ifremeで読み込む（外側Next.js、内側Nuxt.js）
• ミイダス
  • コンピテンシー診断
  • バイアス診断ゲーム
  • ミイダスラップ
• Chakra v3
• RemixSPAmode

LT: JavaScriptを支えるエコシステム（漫才）

• 細かい部分は分からないけど、導入としてどんなものがあるのかを把握するのによかった。
• なんか分かった気になれる。（実際はすぐ忘れるので何もわかってない）

React への依存を最小にするフロントエンドの設計

ケースバイケースではあるけど、視点としては大事かも。
依存性が高い方が開発が早く終わる、コードが読みやすい、プロジェクトの規模が小さい、再開発の必要がない（寿命が短い）etc...の場合は気にしなくて良いと思うし、
規模が大きく、何度も再開発する可能性がある（寿命が長い）とかなら考えておきたい部分もある。
ただプレーンのJSも大きく変わることがあるので、情報のキャッチアップとリファクタリングは継続して行う必要はある。絶対。

幸せの形はどれも似ているが、不幸なプロジェクトはそれぞれの形がある

メモ

• chrome devtoolsをLighthouseの推奨設定に合わせて計測する
• devtools>Lighthouse>Analyze page road
  • 目標：LCP2.5秒
  • LCPまでの経路がチューニング対象
• devtools>performance
  • 縦に読む、密な場所を読む
• devtools>network
• devtools>network blocking
  • サードパーティーを全部ブロックしてみる
• webvitals：GoogleがWeb上で優れたユーザー体験（UX）を提供するために不可欠であるという考え

所感

• 計測はdevtoolsは、私もそう思うし、最近聞いたセミナーでもちょこちょこ聞くからきっと間違いない。
• devtoolsは使って覚えるしかない：ほんとそう。覚えたと思っても、使わないと忘れるし、知らない間に変わってる。ドキュメントを作ってもすぐに風化する。
• 計測にnetworkを使ってたけど、Lighthouseについて初めて知った。こっちのが計測に特化してるのか、なるほど。今後は活用していきたい。
• 具体的なやり方はconsole.log。結局計測は愚直にやっていくしかないんだなぁと。かなりコストと手間がかかるので、仕事としてやるならちゃんと予算をもらわないと無理。予定に最初から組み込むことが必要。あとlogで計測して…のあとはなんとなく分かったけど、できる気がしない。難しい。これも経験が必要な気がする。

リアルアセットとWebのシームレスな活用のためのパスキー

メモ

• ２段階認証で一番時間がかかるのは認証コードが送られてくるメールを待つ時間
• ２段階認証（2FA）の代わりにパスキーを使う
• simple web authn projectを使う
  • Example Project | SimpleWebAuthn
• 既存のログインもできるようにしつつ、ログイン方法が増えたことが分かるよう、ログイン画面のUIを変更
• 会員登録の後にパスキーの設定をするための画面を表示
• 問合せ対応時にパスキーを提案
• メールなどでパスキー対応したことをお知らせ
• 小さい端末でも一目で全ての情報が目に入るようにログイン画面のUIを変更
• パスワードマネージャーを使用しているかどうかで遷移先を変更する
• javascriptが未ロードの場合でもログインできるよう対応（htmlのsubmitを使用）
• 結果
  • 会員登録後のパスキー登録は63％
  • ログイン時間が144秒から12秒に

所感

• 見逃されがちな非機能要件の効率化が対応できてるのすごい
• パスキーの実装は簡単そう
• パスキー使用の促進について、きちんと自社のデータを活用し、対策を検討できている
• 多数への対応のため少数を切り捨てずに考慮できてる

Modular Monolith Monorepo

メモ

• monorepo:1つのリポジトリで複数のプロジェクトを管理する手法のこと。
• Design Docs:Googleなどで取り入れられているシステム設計ドキュメント手法です。開発をする前にプロジェクトの背景や目的、設計、検討した代案などをdocument化します。そしてそれを持って関係者との共有、議論を行うことによって事前に全体を考察し、精度を高め開発後の手戻りを減らすなどが主な目的。
• storybooks:UIカタログ

JavaScriptのイテレータとイテラブルの概要と課題、未来

• Javaでさんざんやったイテレーターの内容だったんで、まぁそうだろうなぁという内容だった。
• JSでイテレーターをどう実装されているのかが分かった。
• 非同期イテレーター・イテラブルについてはまだ理解が追い付いてない気がする。
• Iterator Helpersは初めて知った。あまり使うことはなさそうだけど。

LT: UI 開発における ヘッドレス UI ライブラリの重要性とデザインシステムへの取り入れ方

• セマンティクス：コードの断片の意味
• 無知の無知
  • マウスでは操作できる：キーボードでは操作できない
    • div要素で作成されているため必要なroleが設定されていない
• ヘッドレスUIライブラリ：ドロップダウンリストやモーダル等のUI要素やボタンクリック時のトランジションなどのインタラクション時のロジックなどのAPIのみを提供し、UIのスタイルやマークアップなどは提供しないライブラリやユーティリティなどのこと
  • 最低限のアクセシビリティを担保できる
  • スタイルのカスタマイズが可能
  • スターターキット、shadcn/uiがコンポーネント設計の参考になる

LT: A Tour of Anti-patterns for Functional Programming

• 関数型プログラミング
• Either、Exsult型
• Railway Structure
• effectts

LT: Storybook との上手な向き合い方を考える

• Storybookはzero-configをうたってる
• テストの例：コンポーズストーリ？を使う
  • 実際のブラウザを使うより軽量

LT: あなたの知らない Function.prototype.toString() の世界

• Function.prototype.toString()とは？
  • 関数のコードを取り出せる
• 関数の転送
  • puppeteerで使用してる
• 組み込み関数は取り出せない
  • 組み込み関数の判定に使える

You Don’t Know Figma Yet - FigmaをJSでハックする

• プラグイン：Scripter
  • FigmaでJSコードを書いて操作できる
    • 色見本を一括で作成する
    • フレームの中で使用している色を抽出する
    • フレーム内の文字を拡大する
    • パターンを複製し、ランダムに配置する
    • フレームをランダムに並び替える
    • 要素をアニメーションのように動かす
• 作業の効率化に使える

30 Minutes to Understand All of RegExp Syntax

• 文字クラス
  • /\d/v:0-9
  • /\D/v:0-9以外
  • /\s/v:空白文字（半角スペース、\t、\n、\r、\f）
  • /\S/v:空白文字（半角スペース、\t、\n、\r、\f）以外
  • /\w\v:A-Z,a-z,0-9,_
  • /\W\v:A-Z,a-z,0-9,_以外
• Unicode 文字クラスエスケープ
  • p{General_Category=Latter}/v;
  • p{Currency_Symbol}\d/v;
  • p{sc=Hiragana}/v;

LINEヤフーにおけるPrerender技術の導入とその効果

• Prerender?
• 先読み
  • ユーザー行動を予測し、先回りする
• web標準における先読みの手法
  • ResourceHints:Preload
    • ページ内で使用する優先度の高いリソースを先に読み込む
    • modulepreload、FetchPriaortyAPIへ
  • ResourceHints:prefetch
    • 次のナビゲーションに必要なリソース・ページを先に読み込む
    • PrivatePrefetchProxyへ
  • ResourceHints:Prerender→SpeculationRulesAPI
    • 宣言的なルールをもとに次のページを先読みする
    • PrerenderSafeな実装が必要
      • Prerenderで描画された場合にPVなどに影響がないようにする
• Prerenderを導入することで
  • ユーザー体験は向上した：0.8sec→0.4sec
  • PrerenderHitrate（Prerenderして実際に表示された）は低い：15％
  • PVや滞在時間、広告売上：向上しなかった
  • パフォーマンス改善幅が小さい
  • 広告はPrerenderできない
  • 無駄なリクエストが増加⇔体験、売り上げの向上
  • リンクが密集している（選択肢が多い）とホバー率が上がるため、無駄なPrerenderが増えやすい
• どういう場合に導入する？
  • 導入前後の改善幅が十分にあるか？
  • ユーザーの遷移率は高いか？
  • 迷いマウスが発生しないか？
  • 上記の選定によって、無駄なリクエストとのトレードオフは満たせるか？

ESLintのカスタムルールで治安維持活動をする

• AST explorer

@effect/schemaによる型安全な軽量DDDの実践

• Effect
  • TypeScriptのライブラリ
  • withoutboatsの記事が分かりやすい
  • EffectType：パワフルなPromise