プロポーザル

私が書いた import ... assert { type: "json" } のコードは、ある日書き換えを迫られました。

仕様策定を担うTC39でStage 3まで進んだImport Attributesのキーワードが、assertからwithに変更されたためです。
Stage 3は採用してもほぼ安全。その思い込みが崩れた瞬間でした。なぜこの変更は起きたのか。TC39ではどのような議論が行われているのか。実体験をもとに追いかけます。
このLTを通じて、普段は遠い存在に感じるTC39やECMAScriptの仕様策定プロセスに関心を持つきっかけになれば幸いです。

みなさん、フォームをどのように実装していますか？

たくさんの選択肢がある中で、
「Web標準なフォームならシンプルで軽量」
そう信じて Conform を選択しました。

しかし、1万 input を超える大規模フォームの要件の前で、その理想が崩れます。
本LTでは、大規模フォーム開発で直面した課題と、そこから学んだフォームの技術選定における判断軸についてお話しします。

https://daisyui.com/

daisyUI は tailwind CSS の plugin です。
CSS, tailwind 初心者の私からすると

「えっ CSS だけでそんなコンポーネント実装できるの !?」

という気づきがたくさんあるコンポーネントです。
daisyUI の巧みなコンポーネントの紹介と、その実装方法を追うにあたってたくさんの学びがあった体験を発表します。

もし今、あの案件を「もう一回やり直せる」としたら。
本セッションでは小規模フォーム案件に対しての失敗体験から、案件終了後に個人で実際に再度SpecDDで0から完成まで開発をやり直したプロセス・プラクティスを共有します。

SaaS開発において、ユーザーの一括登録や各種データの一括登録など種々のCSVを用いた一括登録の機能が作られることが多くあります。一方で、CSVからデータを読み込む際に、ファイルごとに読み込む項目が違えば、バリデーションの項目、エラー表示の内容も変わってきます。このようにCSVデータの読み取り処理は柔軟性を求めると共通化の利点が減り、厳格に作ると再利用性が欠けるというトレードオフが難しい側面があります。

本セッションでは、フロントエンドにおける、CSV一括登録のコンポーネント実装、データパース処理、バリデーション処理の共通化に関して取り組んだ一つの方法を紹介したいと思います。

ZodをフォームバリデーションやAPIレスポンスの検証に使っているチームは多いと思います。そんなZodですが、近年はバリデーション専門というより、データ変換ライブラリとしても進化してきました。私もパイプラインを書いたのをきっかけに、「バリデーションのついでにデータ整形もやってしまおう」という考えが加速しました。

しかし便利さに頼るうち、スキーマ定義のチェーンがビジネスロジック化したり、スキーマを読むだけでは処理の全容が追えないコードになってしまいました。チームから「処理の流れが追えない」「便利そうだけどよく分からん」と言われたこともありました。

本発表では、フロントエンドのスキーマ定義で便利だった実装と、苦しくなった実装を、実際の声と共に紹介します。スキーマに書くべきことと、普通の関数に切り出すべきことの判断基準を、自分なりの失敗から共有します。

Googleが公開したA2UI（Agent to UI）は、AIエージェントが宣言的なJSON記述でリッチなUIを安全に生成するためのプロトコルです。本LTでは実際にA2UIを試した所感を共有します。
任意コード実行を伴うMCP Appsとの設計思想の違いを比較しながら、エージェント時代のUI開発の選択肢を考えます。

概要

フロントエンド開発において必須の存在であるフォーマッターですが、一体どのように我々のソースコードをフォーマットしているのでしょうか。
今回の発表では、Prettierを例にソースコードの解析、ルールの適用、出力などどのようなプロセスを経ているのかを図解しながら、5分で誰でも理解できる発表を目指します。

このテーマを選んだ理由

Prettierのドキュメントには「Prettierを導入する最大の理由は、スタイルに関する終わりのない議論を止めることである」という内容が書かれていますが、チーム開発において「Prettierを実行すればフォーマットされているから大丈夫」と考える状態になってはいけないはずです。内部動作をきちんと理解し、フォーマッターの選定や意図を持ったルール設定など、チーム開発の品質基盤を自分でコントロールできるエンジニアとして成長するための話を展開します。

HTMLメールの実装をしたことはあるでしょうか？

HTMLメールには通常のHTMLとは異なる技術的制約があり、Webページと同じ感覚で実装するとつまづいてしまうことも多くあります。

HTMLメールの送受信についてはIETFが策定したRFCで標準化されていますが、受信したHTMLをどのように表示（レンダリング）するかについては統一された標準が存在しません。WebブラウザにはWHATWGやW3Cによる仕様があり、主要ブラウザ間で表示がほぼ統一されていますが、メーラーにはそのような共通仕様がなく、各メーラーが各自の方法でレンダリングを行っています。
そのため、あるメーラーでは正しく表示されるHTMLが別のメーラーではレイアウトが崩れるといった問題が日常的に発生します。

本トークでは、HTMLメールの実装時に気をつけることをかいつまんでご紹介できたらと思います。

OKLCHは一般的に「RGBより鮮やかな色が表現できる」と言われます。しかし、RGBより鮮やかとはどういう意味でしょうか。
私たちが見ている画面は、R・G・Bの3色の混合で構成されるはずです。OKLCHも最終的にはここに還元される以上、RGBでの指定との差分が出るということに疑問を感じ、調べたことがあります。
そこには、人間が知覚可能な色の空間に対しRGB（sRGB）はその一部しか表現できていないことなどが原因だと分かりました。
このセッションではRGBとOKLCHの座標の違いや、OKLCHが鮮やかである理由について5分で説明します。

セキュリティのためのCSP対応が必要になった際に、CSPは外部リソースの読み込みだけではなく、インラインスクリプト・インラインスタイルに対しても適用できることを知りました。
そもそもなぜインラインスクリプトを保護する必要があるのか、nonceを利用してホワイトリスト的にインラインスクリプトを保護する仕組みについて、簡単なデモを交えながら説明します。

リセットCSSは、ブラウザが標準で持っている要素ごとのデフォルトスタイルを揃えるためのプラクティスとして広く知られています。
一方で、一度組み込むと見直す機会が少なく、古い指定がそのまま残ることもあります。

歴史あるアプリケーションのアクセシビリティ向上に向き合う中で、デザインシステムの適用でも漏れがちな古い画面の改善策を考えた結果、リセットCSSの「たった1行」を削除するだけで改善につながった、という出来事がありました。
このトークでは、なぜその指定が入っていたのかを整理しつつ、現在のブラウザ事情では何が問題になりやすいのか、そしてリセットCSSを見直すときの観点を紹介します。

JSXは、UIとロジックを自然に結びつけられるという優れた開発者体験で、Reactの普及に大きく貢献しました。
その影響はJavaScript以外にも広がっており、Rubyでも「JSXのコンセプトを取り入れた書き方」に挑戦する動きがあります。

このトークでは、Ruby on Railsのフロントエンドに、JSXのコンセプトを適用したRuxというライブラリを紹介します。
これまでのRailsフロントエンドについて軽く触れつつ、Ruxの可能性と課題についてお話します。

Railsユーザーに限らず、JSXに馴染みがある方にも別の角度から楽しめる内容にする予定です。

Reactコンポーネントのテストで広く使われるJSDOMは、ブラウザ環境の代用品であり、レイアウト・イベント・非同期処理などで実ブラウザと差異があります。「テストは通るのに本番で動かない」問題が起こり得ます。
Vitest Browser Modeは実ブラウザ上でテストを実行するアプローチです。本トークでは、Testing Libraryからの移行を通じて見えた技術的な違いを深掘りします。

非同期アサーション: expect.element()とリトライ設計の関係
userEventのAPI設計: setup()が不要になった背景
イベント処理の違い: JSDOMで見逃される実ブラウザ特有の挙動
レンダリングと副作用: DOM APIやイベントループにより異なるuseEffectの振る舞い

JSDOMの限界、実ブラウザテストのトレードオフ、選択基準を実例とともにお話しします。

皆さんはロケールごとに日時をフォーマットする際に、どのようなことを考慮していますか？

もちろんIntl.DateTimeFormatだけで済むのが理想ですが、実際にはIntlで対応できる範囲以上の細かい制御を求められることも多いと思います。

では、フォーマットパターン文字列（yyyy/MM/ddのようなもの）で指定できれば問題ないのでしょうか？残念ながらフォーマットパターン文字列自体の扱いや各パターンに対応するデータがライブラリによって異なるため、この方法も万能ではありません。

このLTでは、「日時のフォーマット」という一見簡単そうに見える機能の背景にある仕様と複雑さについて解説します。現状日時のフォーマットに完全な正解はないと考えていますが、今後国際化を考えたフォーマット機能を実装する際に考慮すべきポイントと陥りがちな落とし穴を可能な限り網羅することを目指します。

カラム定義、行アクション、一括操作、フィルター。データテーブルに必要な機能を「利用者側から自由に差し替えられる」コンポーネントはどう設計すればいいのか。
@wordpress/dataviews、MUI の Data Gridなど、拡張性の高い OSS のデータテーブルを読み解くと、設計指針が見えてきます。何をPropsで受け取り、どこを拡張ポイントにするか。見た目はコンポーネントが担保しつつ、中身は利用者に委ねる構造をどう作るか。
OSSから学んだ設計指針と、それを実際のプロダクト開発に落とし込んだ実践例をあわせて共有します。

Turbo Frame / Turbo Stream にトランジションを簡単に追加できる npm ライブラリがあります。
とても便利ですが、Turbo Stream でアニメーションを付ける際に <turbo-transition> を毎回記述する必要があり、Railsらしい書き心地から少し離れていると感じていました。
RailsでTurbo Streamを利用する場合、turbo_stream.append のようなDSLが用意されており、このDSLを拡張して
turbo_stream.append "tasks", :fade
のように、より直感的にトランジションを指定できるgemを設計しました。

本セッションでは、デモと実装の解説を交えながら、

• フレームワークに手を入れるときの判断基準
• DSLを自作する際に考えるべき観点
  についてお話しします。

このトークはDeno 初学者が深掘りした話です。

「npm installしたライブラリ、何をしているか把握していますか？」
Node.jsではライブラリに全権限が与えられますが、
Denoは「Permission（許可制）」で安全性を確保します。

このLTでは、NodeとDenoの違いを比較しながら、
Denoが守る4つのもの（ファイル、環境変数、ネット、実行権限）をコードレベルでの深堀りを行います。

AIエージェントによるWeb操作が当たり前になる中、私たちはいつまで「壊れやすいDOMスクレイピング」に頼るのでしょうか？Chromeチームが発表した新規格 WebMCPは、この状況を一変させます。
本セッションでは、Webサイトの機能を「AIが直接叩けるツール」として定義し、ブラウザを介して安全にエージェントへ提供する仕組みを、5分のLTに凝縮して解説します。

• 脱・人間シミュレーション: 画面解析を卒業し、構造化されたデータでAIと対話する。
• 2つのアプローチ: HTML属性で教える「宣言型」と、JSでロジックを繋ぐ「命令型」。
• フロントエンドの役割: 「見やすい画面」だけでなく「AIが使いやすい機能」を定義する新常識。
  早期プレビュー（EPP）の内容をベースに、Webサイトが「AIフレンドリー」なプラットフォームへと進化する未来の実装イメージを共有します。

SPAでの画面遷移トラッキングは、アナリティクスやエラー監視に不可欠ですが、
History APIでは popstate + onClick + router監視 といった
複合的な実装が必要で、遷移漏れも発生しやすい課題がありました

2026年1月、Navigation APIがFirefoxでも利用可能となり、
ついにBaseline機能に到達したことで、この課題に対してNavigation APIを使った実装を適用しやすくなりました

Navigation APIによって何が嬉しいのか？を実務で直面した課題ともにReactでの実装パターンをもとに紹介します