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

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

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

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

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

私たちの開発体験を高めるものとして、ソースマップは必要不可欠ともいえる存在です。しかし、ソースマップをじっくり眺めたことがある方は少ないと思います。

かく言う私も、「元のコードへの参照を保持してくれるJSONのやつ」という程度の認識でした。しかし改めて中身を見てみると、"mappings"というフィールドには「AAOI;AAPJ,SAASA,kBAAkB...」といった4~6文字程度のアルファベット列がたくさん詰め込まれいています。

これはVLQというアルゴリズムによって生成される文字列なのですが、今回のセッションではこのロジックなどを中心に、ソースマップがどのように生成され、元のコードへの参照をどのように保持しているか説明します。

小規模なチームではフロントエンドの経験や得意分野に関わらず、全メンバーがコードレビューや開発に参加する必要がありますが、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年間の経験を踏まえつつフロントエンドについてどのような変化をしてきたのかを振り返り、フロントエンドの過去、現在、そして未来を考察していきます。

「useEffectってなんかわからんけど使わない方がいいらしい」

ReactのuseEffectって便利ですよね。
ですが本来の用途とは異なる使い方をされることが多く、公式ドキュメントにも「そのエフェクトは不要かも」という項目が作られるほどです。
しかし非推奨ではなく本来使われるべき用途があります。
正しい使い方とは何か？AIにコードを書かせるとuseEffectを多用する部分も見られ、正しく使っているか見極める必要性が増してきました。

本セッションでは、useEffectの役割を使用例を交えながら説明します。
なぜ非推奨と言われるような風潮になっているのか、現代のライブラリ事情も合わせて解説します。
useEffectの使い方を見極められるようになれば幸いです。

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

概要

フロントエンド開発においてよく使われるようになったTypeScriptはJavaScriptに型の構文を追加した言語ですが、そのままではブラウザで直接動かすことはできず、実際に動かすにはトランスパイルやバンドルを経て最適化を行う必要があります。
発表では、TypeScriptのコードがどのようなプロセスを経てブラウザで動作するのかを図解しながら、5分で誰でも理解できる発表を目指します。

このテーマを選んだ理由

「とりあえずTypeScriptを書いて（AIに書いてもらって）画面に描画されているからOK」の段階を卒業し、ビルドプロセスを理解することは開発効率向上、トラブルシューティング精度向上、パフォーマンス配慮、さらにAIネイティブの若手育成など、TypeScriptを自由自在に用いることができるフロントエンドエンジニアとして成長するために、様々な効果が期待されます。

研究の世界が抱えているフロントエンド課題について発表します。
皆さんは普段とあまり接点がない領域かもしれませんが、新しい視点として興味を持ってもらえたり、この分野に挑戦してみたいと思うきっかけになればと思います。
学術論文は、複雑な数式を含むことや研究者自身による執筆・整形・公開が特徴の、現在主にPDF形式で配布されるの存在です。しかし、PDFは見た目を忠実に再現する一方で、文章構造や意味の保持が困難
です。近年、アクセシビリティ向上等のためにウェブ版の論文も増えていますが、多くの課題を抱えています。出版社によるウェブ版の残念な事例と優れた事例の両方を取り上げます。最後に、先進的な取り組みとして、arXiv.orgの論文をHTML化する「ar5iv」プロジェクトと、PDFの意味構造を豊かにするLaTeXの「Tagged PDF」プロジェクトを紹介し、この分野の未来と可能性について話します。

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

「Conditional Types、Infer、Recursive Types...」TypeScriptの複雑な型を学んでも、仕事で活用する機会はあまりありません。
しかし、これらの型は、私たちが日常的に使っているライブラリの内部で重要な役割を果たしています。
ライブラリ側で複雑な型定義が行われているからこそ、私たちは柔軟かつ型安全にライブラリを利用できます。
本セッションでは、TanStack Routerの実際のコードを理解することで、複雑な型定義がどのように使われているかを解説します。

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

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

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

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

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

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