トーク

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

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

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

フロントエンドのテスト、うまくいっていますか？重いE2EテストやVisual Regression Testの偽陽性など、やったことがある人にしかわからない落とし穴があるのがフロントエンドのテストです。このLTでは、私が現場で直面したフロントエンドのトラブルとその解決策をノンストップでお送りします。

例えばこんな話：

• Visual Regression Testの偽陽性をガッツリ減らす方法
  • placeholder画像の読み込みタイミングによるブレを軽減する自作npmパッケージもご紹介
• テストフレームワークを段階的に移行した話
• APIの仕様変更にAPIモックを確実に追従させた話
• テストコードを後回しにして失敗した話と解決策
• などなど…

単なる「あるある」では終わりません。現場で実証済みの解決策を10連発でお届けします。

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 フェーズで動かない端末があった」ということが発生しがちです。
このトークでは、スマートフォンでカメラを扱う際に、ナイーブに実装すると起こり得る(端末によっては動かなくなる)処理・実装の例と、これらを回避するためにどのような実装を行うべきかについて話します。

Push APIを活用すれば、Webサイトからネイティブアプリのようにプッシュ通知を送ることができます。
しかし、実際にはFirebaseなどのSDKを使って導入することが多く、内部の仕組みを学ぶ機会は多くありません。

本セッションでは、W3CのPush API仕様を紐解きながら、外部サービスに頼らずにフロントエンド・バックエンドをフルスクラッチで実装します。
通知が届くまでに、フロントエンド、ブラウザ、バックエンドサーバーがそれぞれどのような役割を担い、どう連携して動作しているのかを解説します。

概要

近年、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)を自動生成し、ログ実装の保守性・信頼性を向上させた事例をフロントエンドエンジニアの視点で紹介します。

株式会社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時代に取り残されたくない（自分のような）フロントエンドエンジニア
伝えたいこと: フロントエンドエンジニアの土壌があれば、これに手を出すことは怖くないし、キャリアの糧になる

文字と同じく数千年の歴史を誇る「改行」。あまりに身近なものなので、文章を読む時はその存在を意識することすらありません。しかし、開発の場面で改行を扱うとなると、「改行コードが複数パターンある」「CSSに似たような改行系プロパティが色々ある」といったややこしい事実に直面するうえ、挙動が思いのほか複雑なので表示崩れをはじめ様々な観点で思わぬトラブルを招く厄介な側面があります。

本セッションでは、テキストデータ・HTML・CSSのそれぞれにおける改行周りの厄介ごとを文字入力の歴史やタイポグラフィの知識などと絡めて紹介。さらにテキストデータにおける改行の扱い方から改行を制御する多種多様なCSSプロパティの使い分けまで、実務に役立つ改行のアレコレを扱います。

たった20分で、「なんとなくの実装」から脱却し、改行と自信をもって向き合えること間違いなし！

既存の物件検索サイトは保存できる検索条件の上限や、価格の変更を手動でチェックするなど、業務効率を阻む制約が多く、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アプリをラフに作ってみたい

WebSocket通信はリアルタイム性に優れる一方で、接続状態の把握・イベント処理・再接続戦略など、状態管理が煩雑になりがちです。

特にReactアプリケーションに組み込む際は、通信状態をUI上にどう表現するか、状態をどこまで共有するか、といった設計がUXに大きく影響します。

本トークでは、接続・切断・待機・エラーといったWebSocketの状態をReactでどのように扱い、アプリケーション上で視覚的にどう反映するかを紹介します。再利用可能なコネクションの設計、ライフサイクルに応じたイベント管理、スコープに基づいた状態の共有といった観点から、実例を交えて解説します。

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

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

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

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

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

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

CSSは不完全な言語です。JavaScriptのようなプログラミング言語でもなく、デザインツールが完璧に再現することもできません。

宣言的で、コンテキストに依存し、あらゆるデバイスで予測不能に動作するCSSの言語特性は、「互換性に縛られた未知で無限の空間」である「Web」という媒体において、実は必然的かつ合理的な設計判断だったのではないでしょうか。

昨今のCSSWGでの仕様策定を俯瞰すると、Inheritance、Defaulting、Cascade、Specificity 等の根底の設計思想を尊重しつつ、より洗練された形で活用可能にする傾向が見受けられます。

本セッションでは、CSS がなぜこの設計思想を継承し、どのように発展させ、どのような変化がこれから予想されるかを、Cascade Layers・Scope・Container Queries などに焦点を当てつつ考察します。