AIが書き散らかしてしまうリアクティビティが雑なコード！
ESLintのカスタムリンターを作った話をします。

JSXで書ける！hooksで状態管理できる！描画の自由度も高い！なのにあまり周囲で採用を見ない「PixiJS React」の話をします

PixiJS React は、2D Canvas 向けの高速な WebGL ライブラリ「PixiJS」を React プロジェクトで扱いやすくするためのラッパーです。
パフォーマンスの高さと柔軟な描画力をそのままに、React の世界観で使えるのが大きな特徴です。

• JSXでいつも通りコンポーネントとして記述できる
• useStateでReactのライフサイクル上で扱える
• WebGLの恩恵を手軽に受けられる

実際のプロジェクトでの活用事例をベースに、他のライブラリとの違いや、運用上の工夫・ハマりどころも交えて、その魅力を余すことなくお伝えします！

小規模なチームではフロントエンドの経験や得意分野に関わらず、全メンバーがコードレビューや開発に参加する必要がありますが、CSS、フレームワーク、UI設計への苦手意識が大きな障壁となりがちです。

本セッションでは、container/presentationパターンをベースとしたファイル分割による責務とテスト対象の明確化、TypeScript graphを活用した変更影響範囲の可視化、ドメイン固有のカスタムESLintルールによる設計ガイダンスとコード品質の自動化など、段階的な環境整備によってチーム全体のフロントエンド参加率とレビュー効率を大幅に改善した事例を紹介します。

特にAI生成コードが普及する現在、属人的なスキルに依存しない構造化されたレビュー体制の重要性についても言及します。

2010年代初頭に「フロントエンド」というワード、技術分野を見かけるようになって興味を抱き、40代半ばとなった2015年よりフロントエンドエンジニアとしてのキャリアを積み始めて10年が経ちました。

この10年の間にHTML、CSS、JavaScriptもいろいろ進化や変化を続けてきました。

HTML5が浸透し始めた頃から5.1、5.2を経てHTML Living Standardへ。
テーブル、floatをレイアウトで使っていた時代からFlexboxを経てCSS Grid Layoutへ。
JavaScriptはES6、そしてES20XXやTypeScriptへ。
jQuery全盛の時代からVue.js、Reactへ。

本セッションでは、10年間の経験を踏まえつつフロントエンドについてどのような変化をしてきたのかを振り返り、フロントエンドの過去、現在、そして未来を考察していきます。

以前はCSS側でime-modeを指定すればIMEをOFFにするだけで済んでいたIME入力制御ですが、現在ではセキュリティやアクセシビリティの観点から、ブラウザによる強制制御はできなくなっています。
その結果、OTP入力のような「必ず半角数字で入力してほしい」場面で、全角数字が入力されて2マス分消費されてしまうといった課題が生まれてきます。
このトークでは、過去の入力制御手法から、現在主流となっているinputmode や type属性・バリデーションなどの手法を整理し、現在のIME入力制御のベストプラクティスをお伝えします。

WICGで提案されているSoft Navigationsは、SPAにおけるpushState()等による履歴遷移を、ナビゲーションとして検出・測定可能にする仕様です。従来のNavigation TimingやWeb Vitalsでは対象外だった同一ドキュメント内の遷移にも、LCPやCLSといった指標を適用できるようになります。このLTでは、ユーザ操作やDOM変化などに基づく検出条件、現在の実装状況、そしてWebパフォーマンスの観測設計に与える影響について紹介します。

ClineやGitHub Copilotのようなコーディングエージェントの登場により、エンジニアが従来のチャットによるLLMとの対話からAIエージェントを使用する機会は増えてきていると思います。
一方で、生成AIアプリケーションの開発という点でも、業務をワークフローとしてAIエージェントに実行させるAgentic Workflowアプリケーションの開発というのも増えてきています。
本トークではAgentic WorkflowアプリケーションのUI実装をする際に発生した複雑な状態管理に立ち向かうために行ったことについてお話しします。

話すこと

• チャットアプリケーションとAgentic WorkflowアプリケーションのUI実装における違い
• Agentic Workflowの状態管理を行う際の複雑さ
• XStateを使用した解決策の提案

ライブラリやSDKをメンテナンス/品質保証する際、ある特定バージョンや配布形式、またそれらの任意の組み合わせによってデバッグや動作確認をしたいケースはしばしばあります。 もしそれがnpmパッケージであれば、個別にビルドするのでは手間がかかり、また幾つものバージョンを事前にバンドルするとアプリケーションサイズが膨大になってしまうことが容易に想像できます。
この課題は、Dynamic ImportとViteのビルド設定をうまく組み合わせることで解決することができます。

このトークでは、Viteの具体的なビルド設定の内容を踏まえ、実際にビルドが実行されてからランタイム上でパッケージが解決されるまでのフローも解説しながら、この課題に取り組むにあたり工夫が必要だった点や実装時の注意点を紹介していきます。

AI補完が頼りないと言っていたのも2年も前。いまやAIは欠かせない存在にまで上り詰めています。
AIは世の中にある情報をもとに学習するので、普及率が高いとは言い難いSvelteは不利かもしれません。
そんな世の中でSvelteを選ぶ理由を紹介します。

・Svelteとは何か
・速い・軽いだけではない、Svelteが優れている点
・AIとの相性

フロントエンドにおける状態管理は、Reactの進化とともに変化してきました。Reduxの登場と普及、Recoilによる宣言的な分離、Zustandのミニマルな設計。そしてReact 18で登場した useSyncExternalStore により、Reactは「状態をどう扱うべきか？」に対して新たな指針を提示し始めています。

本トークでは、これらのライブラリが生まれた背景と技術的課題を時系列で整理しながら、代替わりの必然性と設計思想を考察します。特に useSyncExternalStore に焦点を当て、React標準の視点から状態管理を見直すきっかけを提供します。

日々のフロントエンド開発において、施策による時限的なUIの変更、新機能のリリース、A/Bテストなどのたびにコード修正・レビュー・デプロイに追われていませんか？

従来のUI開発では、サーバーからデータを受け取るだけでなく、画面構成やUI仕様の変更にもクライアント側の改修・リリースが必要でした。
その結果、開発サイクルが長期化や複数のプラットフォームでサービスを展開している場合、提供同期や仕様ズレ、互換性問題も発生しがちです。
SDUIでは、UI設計情報そのものをサーバー側で管理・制御し、クライアントは設計図に従って安全・迅速にユーザーにUIを提供することができます。

セッションでは、SDUIの技術的構成の例、実際の現場改善ポイント、導入に向けたTipsをコンパクトに解説することで現場で試せるナレッジを共有します。

HTML標準がHTML Living Standardに移行し、Web標準は日々変化し続けています。しかし「この新しいHTML要素、うちのターゲットブラウザで使えるの？」「非推奨になった属性を使っていないか？」といった互換性チェックはフロントエンド開発者には付き物です。
既存のeslint-plugin-htmlやeslint-plugin-compatでは、JSX内のHTML要素・属性の互換性チェックまではカバーしきれていません。
そこで本トークでは、私が開発したESLintプラグイン"eslint-plugin-compat-html"を紹介します。このプラグインはbrowserslist`設定に基づき、JSX内のHTMLタグ・属性のブラウザ互換性を自動チェックします。

https://github.com/satojin219/eslint-plugin-compat-html

マルチプロダクト開発において、ブランドの一貫性を保ちながら迅速にUIを提供する、デザイントークンを活用した開発基盤を解説します。
決済サービス導入事例をもとに、私たちがなぜ一般的なprimitive semanticの2層にcomponentトークンを加えた「3層構造」を導入したのか。その理由と、2層構造の限界、そして3層構造がもたらす柔軟なカスタマイズ性について深掘りします。
技術の核はCSS Variablesです。外部ライブラリに依存しないシンプルな構成ながら、UIライブラリのコードに一切手を加えることなく、利用側がトークンを注入するだけでデザインを自在に変更できる高い柔軟性を両立。私たちの実践から得た、一貫性と開発速度を両立させる設計思想を共有します。

1920×1080の解像度のモニターを使っているお客さんが「レイアウトが見づらい」というので、よくよく話を聞いたら拡大/縮小「150%」で見ているという！
さすがにそんな変な拡大率「150%」になんて合わせて綺麗にしてくださいなんて言わないでほしいと思いますよね？
……それ、ちょっと間違いです！

間違っても「100%で見てもらわないと……」なんて言わないように、ぜひWindowsの「拡大/縮小」と「ディスプレイの解像度」の話を知ってください。

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

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

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

Reactでの開発に慣れていた私が、SvelteKitを使ってポートフォリオサイトを構築したところ、高速で開発することができました。本セッションでは、状態管理やコンポーネント設計に悩んでいたReactとの比較を軸に、SvelteKitの驚きの軽快さ、宣言的なUI設計、ファイルベースルーティング、SEO対応など、個人開発で実感したメリットをお伝えします。一方で、SvelteKitの課題や規模による使い分けのポイントにも触れたいと思います。

Webアプリケーションにおけるページ遷移は、コンテンツが切り替わるたびに体験が途切れがちです。そんな中、Chromeで利用可能な「View Transitions API」は、ページ間の遷移にアニメーションを加えることで、よりシームレスで滑らかなUXを実現できます。本セッションでは、ReactやSvelteKit、Next.jsなどモダンフレームワークへの導入や、DOMの変化をCSSアニメーションと連携させる具体的な手法を解説。導入時の制限や落とし穴、どんな場面で効果的かといった実践的な知見をお伝えします。

CSSにも関数的な進化が訪れています。abs()、sign()、sibling-index()、sibling-count()、progress()など、最新のCSS関数を活用することで、これまでJavaScriptで処理していたようなロジックをCSSだけで実現できるようになってきました。本セッションでは、これらの関数の基本的な使い方から、実際にどのようなインタラクションやデザイン制御が可能になるのかをお話します。

「iPhone SEでは大丈夫だったデザインが、iPhone 15 Plusで見ると文字が小さくて読めない…」そんな経験はありませんか？

iPhone SEの375pxからiPhone 15 Plusの430pxまで、わずか55pxの違いですが、約15%の画面幅の差がデザインに大きな影響を与えます。
本セッションでは、「異なる画面幅でも全く同じ内容を表示する」という方針で解決した実装手法を紹介します。pxからremへの移行、画面幅に連動するfont-size設定、CSSカスタムプロパティを活用した効率的な実装方法まで、BtoCサービス開発での実践的な経験をお伝えします。

振る舞い駆動開発（BDD：Behaviour-Driven Development）は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、認識のズレを防ぎやすくなります。

本セッションでは、TypeScriptでBDDを始めるための基本的な考え方と実践方法を紹介します。Cucumber.jsなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。

TypeScriptでテストを書いて、これからBDDを始めたい方に向けてわかりやすく解説します。