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でどのように扱い、アプリケーション上で視覚的にどう反映するかを紹介します。再利用可能なコネクションの設計、ライフサイクルに応じたイベント管理、スコープに基づいた状態の共有といった観点から、実例を交えて解説します。

Matter.jsは、Webブラウザで手軽に物理演算を扱える比較的軽量なライブラリです。例えば、以下のような表現が可能です。

・オブジェクトが重力や衝突で自然に動く表現
・ユーザー操作に反応して弾む・転がるインタラクション
・配置や衝突判定を伴うインタラクティブな演出
・物理法則に基づいたアニメーションによる動的UI

一方で、描画や更新の扱い方によってパフォーマンス面での課題が生じやすくなります。
本発表では、配信画面デザインサービスにおける事例をもとに、Reactと組み合わせた遊び心満点の物理エフェクトの実現方法を紹介します。
エンジン共有や再計算の抑制といった設計上の工夫から得られた、物理演算をWeb表現に活かすための実践知を共有します。

あなたのWebサイトも、手頃に「ぷにゃっ」と動かしてみませんか。

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サービス開発での実践的な経験をお伝えします。

LLM 時代に急増した「死んだexport」をKnip×ESLintでゼロ化する提案です。
ESLintだけでは検出できない、テストやStorybookで利用されている関数にも対応し、
私の担当するプロダクトでも10以上の関数を削除しています。

内容

1. Knip設定 & ESLint連携
2. Storybook・テスト用のexportへの対処
3. GitHub Actionsで再発を防ぐCIフロー
4. Claudeによる削除候補レビュー PoC

対象

プロダクトの信頼性を高めたいフロントエンド開発者

持ち帰れるもの

明日の30分で完了できる設定。それ以降は不要な関数とコンポーネントがゼロに。

—

ライブデモ込みの30分です。
私も以前、不安感を持って開発をした経験があり、そんな思いをする方を減らしたいと考えて提案をしています。

普段の開発を行っていると、mdnのCSSリファレンスを端から読むことってそんなに多くはないと思います。
ですが改めて読んでみると、「知らなかったけどこれは便利だな！」というものから「このプロパティいつ使うん？」とつい思ってしまう様なマイナーなものまで、様々なプロパティと出会うことができます。
今回の発表では、mdnのCSSリファレンスを全て読んで見つけたマイナーなプロパティを紹介しながら、何とか業務内でも用いることが出来そうな用途を可能な限り捻り出して紹介します。
「自分でmdnを通読するのはめんどくさいけど、何か面白いものがあるなら知りたい！」という贅沢な方々に向けて、すぐに業務に役立つ訳ではないけれど知っておくといつかどこかで使えるかもしれない知識をお届けします。

知れること

• 一般的に広く使われていないが、特定の用途で便利なプロパティ
• 通常では使わない特異なプロパティ

私のチームは現在、長年利用されているレガシーシステムの移管プロジェクトに取り組んでいます。

アプリからインフラ、組織体制まであらゆる面で見直しと再設計が必要となり、当然フロントエンドも大規模なマイグレーションが必要となりました。

しかし蓋を開けば遠い昔に見たMarionette.jsやUrushiなど古のフレームワーク群が数多く登場。
フロントエンドエコシステム黎明期に作られたスクリプト群に対し、現代の静的解析はまともに機能しませんでした。

当然ながらAIエージェントも適切に回答できることが少なかったため、自力で解読して再設計することから始めました。

ステップ数は1ファイルあたり3000〜10000強。
それらをモダンな構成へ移行する試行錯誤のなか、巨大フロントエンドをモダンに仕上げる「ツボ」があることに気がつきました。
それらについて、私たちの挑戦と共にご紹介いたします。

「overflow: auto を指定したのに横スクロールできない」「長いコンテンツが親要素を突き抜けてしまう」そんな経験はありませんか？
私自身、横スクロールが効かない問題に直面した際、原因は親要素に設定された flex-direction: row でした。
実は、こうした構造的なレイアウト崩れは、FlexboxではなくGridを使うことでスマートに解決できるケースが少なくありません。
本LTでは、実際に遭遇した問題を通じてFlexboxの仕組みを解説しつつ、Gridレイアウトがより適切な選択肢となる理由をお伝えします。
min-width: auto の罠、不要なdivの増加、非セマンティックなHTML構造といった問題が、Gridでどのようにスマートに解決されるかを実例を交えて紹介します。
「とりあえずFlex」から一歩進み、意図に応じたレイアウト手法を選べる開発者を目指しましょう。

「あ、このアニメーション気持ちいい！」 - そんな体験には再現性があります。

本セッションでは

1. なぜ心地よさがユーザー体験を向上させるのか
2. 心地よいアニメーションの設計
3. Motion での実装テクニック

をデモ中心で解説します。
フロントエンド初級者でも「セッション後すぐに試せる」具体的 Tips を持ち帰れる内容です。

モノリス化が進んだプロダクトの中で、「ユーザー影響の少ない画面から段階的にフロントエンドを切り出していこう」
そんな構想から始まった、バックエンド・フロントエンドの分離プロジェクト。
Next.js を使い、OpenAPIで型生成を行い、アーキテクチャパターンを学び…将来的にプロダクト全体への展開も視野に入れていましたが、
結果的に今は「撤退」を選ぶことになりました。
本セッションでは、どんな構想を立て、なぜ実行に移し、そしてどこで限界を感じたのかをリアルに共有します。
同じようにフロントの切り出しを検討しているチームにとって、立ち止まって考えるきっかけになれば幸いです。

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

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

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

package by featureは、機能や関心ごとにディレクトリを切るディレクトリ構成です。
/hooksや/contextsといった技術ごとにディレクトリを切るpackage by layerはひとつの機能が分散して配置されるのに対して、package by featureはひとつの機能が一箇所にまとまっているのが特徴です。

しかし、実際にどのようにfeatureを切っていくのかについて取り上げている情報は、まだ少ないように感じます。

一方で、コンポーネントのDomain(関心)に特化した分類には、コンポーネントを関心・状況・基礎の3つの軸で分類することで体系的に管理できるBCD Designという手法があります。

そこで、本セッションではBCD DesignにおけるDomainの概念を応用し、featureをどのように切り出していくのかについて具体例を交えて紹介します。

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

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

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

LINEのミニアプリやLIFFを活用すると、スマートフォン向けのアプリを手早く構築できます。
この仕組みをつかった、イベントむけ謎解きゲームアプリのご紹介です。

Vite+React のSPAに@line/liff SDKを組み込んでいます。

• 基盤がLINEだからターゲット層が広い
• 認証つきなので、オンボーディング、正誤判定やランキングなどのゲーム要素と相性がいい
• QRコードリーダーでチェックインやクーポンのもぎり
• LINE公式アカウントのトークタイムラインやMessaging APIとも連携した仕掛け
• ヘッドレスCMSとも連携させれば運用効率も◎