トーク

フロントエンド開発では必ずと言って良いほど利用するnpmパッケージマネージャですが、なんとなく選んでませんか。

本セッションではあなたのプロジェクトに適切なパッケージマネージャをnpm、yarn、pnpm、bunの4種類から
インストール速度、依存関係管理、互換性、セキュリティ、運用コストなど様々な観点で解説します。

【セッション対象者】
・ 普段なんとなくnpm installしてる人
・ プロジェクトのnpmライブラリアップデートで疲弊してる人
・ フロントエンドとバックエンドの両方でnpmライブラリを利用していてパッケージ管理に悩んでる人

Webに掲載した動画に字幕をつけることは「アクセシビリティ対応」や「追加機能」として扱われがちではないでしょうか。

本セッションでは、字幕を視覚的なUIコンポーネントの一部として、「設計段階から組み込む」という視点を軸に
「字幕の表示位置とレイアウト干渉」「切替導線のわかりづらさ」「再生中の音声とのズレ」「ダークモードでの可読性不備」など
よくある落とし穴とUI設計を具体的な実装例を交えて解説します。

字幕を後付けの対応ではなく、標準的なUIコンポーネントとして扱うためのポイントをお伝えします。

Reactでデータフェッチを行う場合、useEffectとuseStateを組み合わせた実装をすることが多いのではないでしょうか。

本セッションではReactのSuspense機能を用いることで、読み込み状態の管理、エラーハンドリングをより簡潔に行う方法を解説します。
また、openapi-react-query-codegen を使いOpenAPIから型安全なクライアントを自動生成、さらにReact Queryとの親和性を活かし
ReactのSuspense機能で「待つ」UIを簡単に表現する実践例を紹介します。
自動生成されたカスタムHooksとReact Suspenseにより、TypeScriptの型安全な読み込み状態制御やエラーハンドリングを実現。
実際の事例をもとに、開発体験の向上とSuspenseの具体的なメリットをお伝えします。

配信者の求める「自分らしい配信画面」を技術的な知識なしで実現できるデザインツールをどのように実現するか。
汎用化された共通コンポーネントとCSSを活用し、複雑GUIでユーザーが簡単にアレンジできる配信画面デザインツール・配信アセットの提供を行ってきました。

このセッションでは、汎用的でありながらテンプレートとしてのベースデザインの拡張性を維持し、ユーザーが追加でいくつかのパラメータでのカスタマイズが行えるようにした手法、可変サイズに対応するために行っている工夫などをお話しします。
また、現在開発中の新サービスにおけるこの手法の変化や拡張とともに、OBS内のブラウザという特殊な環境における事情と制約、配信画面という壊れてはならないものを壊さないために行ってきたこと、安全に壊す技術についても合わせてお話しします

Storybook v9 で大幅に強化されたテスト機能は、コンポーネント開発の品質向上に非常に役立ちます。

しかし、Next.js App Router (RSC 使用)を採用していると、何も考えずにコンポーネントを実装すると Storybook の環境整備につまづくケースがあります。

Storybook では experimentalRSC フラグによる RSC サポートが試みられていますが、現時点（Next.js v15.3.3）では安定して動作しておらず、RSC 依存のコンポーネントは描画できない状況です。

本セッションでは、こうした制約の中でも Storybook のテスト機能をフル活用できるコンポーネント設計を目指し、RSC 依存を最小限にとどめる実践的なパターン・注意点を解説します。
Storybook を活かした堅牢なフロントエンド開発を目指す方におすすめの内容です。

Biome は JavaScript, TypeScript, CSS などの Format や Lint を行うツールチェインで、設定のシンプルさや高速であることから支持が広がっています。
これまで利用者がルールを追加することはできませんでしたが、v2 からは GritQL によるプラグイン定義が可能になり、独自ルールを定義できるようになりました。

しかし、ESLint プラグインが JavaScript で柔軟な記述ができることに対して、Biome がベースとする GritQL は宣言的なクエリを記述するため、表現力には違いがあります。

今回のプラグインサポートによって、ESLint エコシステムにあるライブラリやプロジェクト独自のルールはどこまで Biome に移植可能になるのか、具体例を交えて紐解いていきます。

LLM に外部データを渡したり操作させたりする手段として、Model Context Protocol（MCP）が注目されています。
MCP では当初通信方式として Server-Sent Events (SSE) をサポートしていましたが、3月の仕様改定からは代わりに Streamable HTTP が採用されました。

本セッションではこの仕様変更を出発点に、HTTP ベースのリアルタイム通信の選択肢である

• WebSocket
• Streamable HTTP
• Server-Sent Events
  を整理し、それぞれの仕組みや適切なユースケース、利点・欠点を比較します。

MCP の RFC における議論をヒントに、Web におけるリアルタイム通信をあらためて体系的に理解することを目指します。

ほとんどのスマートフォンには前面カメラ(インカメラ)と背面カメラ(リアカメラ)が付いており、 ブラウザの getUserMedia API からカメラ映像を取得することができます。
しかしカメラというのはデバイス上でただ 1 つのリソースであり、解放や再利用などについては慎重に扱わなくてはなりません。
加えて、スマートフォンというどうしても端末依存の挙動が発生する環境であるため、「手元やレビュワーの端末では問題なく動いたが、 QA フェーズで動かない端末があった」ということが発生しがちです。
このトークでは、スマートフォンでカメラを扱う際に、ナイーブに実装すると起こり得る(端末によっては動かなくなる)処理・実装の例と、これらを回避するためにどのような実装を行うべきかについて話します。

概要

近年、Popover API の登場や Dialog API の進歩によって「Top layer」という新たな概念が身近になり、z-index に依存しない実装が可能になりました。このセッションでは、Top layer の仕様から、実際に触ってみてわかったことやニッチな仕様まで、まるっとスリっとゴリッとエブリシングお伝えします！

背景

私の所属するテックタッチ株式会社では、第三者の Web サイト上に操作ガイドを表示するプロダクトを開発しています。最近では様々な Web サイトで Top layer が利用されるようになり、それを考慮した機能の実装が必要になりました。その実装をするうえで得た学びを共有できればと思っています。

想定聴衆

• Top layer について理解を深めたい方
• Web 標準に興味がある方

株式会社WinTicketではクライアント(Web,App,Server)から送る行動ログを数百行のスプレッドシートで管理しており、閲覧のし辛さ、更新漏れが課題になっていました。
また行動ログのスキーマはクライアント側のコードで独自で定義をしており、期待する行動ログの構造と実際に送るリクエストに不整合が起きることもしばしばありました。
本セッションでは、Protocol Buffersでログスキーマを定義して自作のGo製protocプラグインを用いてログ仕様ドキュメントと型安全なクライアントコード(TypeScript)を自動生成し、ログ実装の保守性・信頼性を向上させた事例をフロントエンドエンジニアの視点で紹介します。

近年はフロントエンド領域でも自動テストを導入することが一般的になってきています。
私はコーディングの中でも特にテストが好きで、よく自動テストの導入などを手伝っていたりします。

そんな自分が今からテストが書かれていないReactアプリケーションに対して、テストを導入するならどうするかをテーマにテストの導入方法や向き合い方などについて紹介させていただきます。

• フロントエンドのテストは何のために存在するのか
• テストをどこから始めるか
• テストしやすいように設計を変更する
• テストが書けないなら、常にテストを書くべき理由

最新のChromeでは、オフラインでも生成AIを使える機能が搭載されており、その機能をJavaScriptから呼び出すことができます。
このGemini Nano in Chromeについては以下参考資料の頃の情報から更新しつつ、5月に発表されたGemini in Chrome（Chromeから直接AIを使う機能の方）も踏まえてお話しできればと思います。
ブラウザ上で動くAIのことを知って、ユーザーのブラウザ体験が生成AIによってどう変わるか想像できるようになりましょう！

ターゲット: Webアプリケーションを開発しているフロントエンドエンジニア
伝えたいこと: Chromeに搭載されている・される予定の生成AI機能の情報をキャッチアップしてほしい！
参考資料: https://www.docswell.com/s/gatchan0807/ZN1V6G-2024-11-23-110000

昨今話題のMCP（Model Context Protocol）について、概要を知っている方やプラットフォームが提供しているものを利用したことがある方は多いかと思います。
ですが、「自分でMCPサーバーを立ててみる」という経験をされた方はまだまだ少ないのではないかなと思い、今回の発表を聞いて実際にやってみよう！と思えるようにお話しします！
この技術自体はこれまでフロントエンドに関わって仕事をしてきた方にとって、意外とそんなにハードルが高くないものなので、ぜひ触ってみましょう！
合わせて、私が実際に触ってみてわかったハマりどころ・注意点も含めてお話しできればと思っています！🙌

ターゲット: 生成AI時代に取り残されたくない（自分のような）フロントエンドエンジニア
伝えたいこと: フロントエンドエンジニアの土壌があれば、これに手を出すことは怖くないし、キャリアの糧になる

既存の物件検索サイトは保存できる検索条件の上限や、価格の変更を手動でチェックするなど、業務効率を阻む制約が多く、SaaS単体では解決が困難です。
そこで、私たちは拡張機能を前提にSaaSを設計しました。
拡張機能があることで既存のWebサイトを拡張したり、管理画面と連携することができます。

管理画面にログイン中なら拡張側も自動認証できるスマートログイン。
ダウンロード直後のPDF図面をService Workerが捕捉し管理画面へ登録するスマートアップロード。
content-scriptが埋め込んだ UI 要素と拡張機能のlocalStorageをstorageイベントで双方向同期するなど、
普段のフロントエンド開発ではなかなか取り組めない技術の組み合わせを紹介します。

当日はライブデモを交えてWebを “壊さず拡張する” 次世代フロントエンドの実践知を共有します！

フロントエンド開発の品質とスピードを保ち続けるためには要望の本質をとらえた設計と実装が重要ですが、実際の開発では目立つ要素である画面の実装や瑣末な文言に気を取られがちです。

Why「なぜ必要か」→How「どう実現するか」→What「何が出来たか」の観点でPRを段階的にレビューするという概念自体は特別新しくありません。しかし、フロントエンド開発の現場で実践してみると期待以上の効果がありました。当初はレビューの負荷を下げる目的で始めた取り組みが、チーム全体に「表層ではなく土台から積み上げる」文化をもたらしたのです。

• 誰もが知るWhy→How→Whatという枠組みが、なぜフロントエンドのPRレビューで特に有効だったのか
• どう導入すれば同じ効果を得られるのか

このトークでは、これらについて実践的な知見を共有します！

JavaScriptで0.1 + 0.2を計算すると0.30000000000000004になる現象、経験ありませんか？

これはJavaScriptがIEEE 754という二進浮動小数点規格に従っているため、十進数を正確に表現できないことが原因です。
ECサイトの価格計算などで誤差が生じ、実際にバグの温床となっています。

この問題を解決するため、TC39ではDecimal（正確な十進数計算）の標準化を議論中ですが、
decimal.js等の関連ライブラリが広く利用され、圧倒的需要があるにも関わらず、5年間進展がありません。

用途は異なりますが、最近TC39 Stage 4に到達した浮動小数点関連のFloat16Arrayと比べ、なぜDecimalは停滞しているのか？
TC39のproposal-decimalを読み解き、なぜ需要があっても標準化が困難なのかを共有します。

現代のフロントエンド開発は、様々なフレームワークやライブラリやツールが急速に進化しており、どんどん複雑化しています。
そのため、「覚えることが多いな」と感じる方が大勢いるかと思います。

このセッションでは、数あるJavaScriptフレームワークの中でも、特にシンプルな記述で簡単に使える(※)Svelteと、それに様々な機能を搭載したSvelteKitについてお話します。
私が過去、役に立たないWebアプリをSvelteで大量に作って得た知見を皆様に共有させていただきます。

※個人の感想です

【話すこと】
・Svelte/SvelteKitの特徴
・入門の手引き

【こんな人におすすめ】
・Svelteについて全く知らない、あるいはかろうじて名前ぐらいは聞いたことがある
・Webアプリをラフに作ってみたい

ひとつのWebアプリだけで完結しないUIやサービスでは、複数のページやタブをまたいで状態を保持し、必要に応じて復元・連携する仕組みが必要になります。

本トークでは、配信画面支援サービスにおける実例をもとに、localStorage・IndexedDB・PostgreSQLを組み合わせた三層構成による状態永続化の設計と実装について紹介します。

また、localStorageのstorageイベントを活用し、配信画面と設定画面といった複数のWebアプリ間で状態をリアクティブに同期・共有する仕組みも実現しています。こうした設計を通じて得られた知見をもとに、ストレージの選定指針や同期の工夫、実装時の落とし穴などをお話しします。

react@experimentalで導入されたViewTransitionコンポーネントは、ブラウザのView Transition APIをReactに統合する新しい組み込みコンポーネントです。

これまでもReactとView Transition APIを組み合わせることは可能でしたが、DOMの更新に対してstartViewTransitionを手続き的に呼び出す必要があり実装が煩雑になりがちでした。ViewTransitionコンポーネントはこのプロセスをReactのトランジションの概念と統合し、マウント、アンマウント、移動といった状態変化に応じたアニメーション実装を簡単にします。

本トークでは、このViewTransitionコンポーネントの基本的な使い方から、ネイティブアプリのような洗練されたアニメーションを実装する実践的なテクニックまで、デモを交えて解説します。

Webページの初期表示速度、どこまで最適化できていますか？
HTTP/1.1 時代の常識を一歩先へ進めるのが 103 Early Hints です。
このセッションでは、クライアントとサーバー間の通信に「ヒント」を挟み込み、リソースのプリロードを可能にする103 Early Hintsの仕組みと効果について紹介します。