トーク

本セッションでは、大規模ECの200ページ超ある管理画面で6年ぶりのデザイン刷新をするにあたり、全レイアウト、UIコンポーネント40種×3実装（React, Vue2, Vue3）を始めとした広範囲の書き換え実施するという課題に対する1年間の実践を、技術とプロジェクト運営に絞って共有します。

技術面では、レポジトリ統合による開発フロー簡素化、epicブランチへの日次自動マージによるコンフリクト早期検知、先行PJ向けの暫定コピペから後置換戦略などを、
運営面では、ミッションステートメントの共同作成、Notionへの意思決定ログ整備、開発フェーズに応じたチームの組み替え等を実施しました。

結果、約12万行の変更をロールバックなし、SNS炎上なし、退職・燃え尽きゼロでリリースしました。
長期間にわたるPJを成功に導くためにエンジニアの枠を超えて取り組んできたことをお伝えします。

Stencil.jsはWeb Componentsを生成するオープンソースのJavaScriptフレームワークで、ReactやVueなど特定のフレームワークに依存せず利用できます。

コンポーネント単位で独立性を保てるため、既存アプリ全体を作り替えずに、一部だけ新技術を導入も可能です。AIコーディングにも最小限のコンテキストで実装できるメリットがあったり、動的なプラグイン開発にも利用できます。

UIをコンポーネント化しておくことで、将来的なバージョン変更やリプレイス時の事業リスク低減にもつながるのでお勧めです。

https://daisyui.com/

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

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

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

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

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

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

tailwindcssとEveryLayoutはどちらも素晴らしいが、少し極端すぎる。その中間のようなものを目指したのがLism CSSです。
reset.cssからレイヤー定義、デザイントークンとユーティリティクラスの設計まで、サイト全体に関わるCSS設計になっています。

• ユーティリティファーストとレイアウトプリミティブの融合
• 余白とタイポグラフィの設計方法
• コンテンツレイアウト手法

などについてお話しできたらなと考えています。

また、専用のReact/Astroコンポーネントを開発してnpmで公開しているのでその苦労話など。

• Lism CSS: https://lism-css.com/
• リポジトリ: https://github.com/lism-css/lism-css

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

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

HTMLメールには通常のHTMLとは異なる技術的制約があり、特殊な知識が必要だと感じる方も多いかもしれません。

その原因にはレンダリングの標準が存在しないという事情があります。送受信はRFCで標準化されていますが、HTMLの表示方法は各メーラーに委ねられています。独自のレンダリングを行っているメーラーもありますが、実はWebブラウザと同じレンダリングエンジンを採用しているメーラーも多くあります。
もちろん通常のWeb開発とは異なる部分も多くありますが、エンジン毎の特性≒ブラウザ毎の特性を理解すれば、普段のWeb開発の知識が活かせる場面もあります。

本トークではメーラーごとのレンダリング事情を整理し、Web開発の経験と結びつけながら、HTMLメール実装の実践的なポイントをお話しします。

概要

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

このテーマを選んだ理由

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

主要なブラウザやプラットフォームでの対応が進み、Passkeyを採用するサービスも増えてきました。しかし、マルチテナントSaaSに導入しようとすると特有の検討事項が多くあります。
RP IDとドメインの関係はPasskeyが使える範囲を決定づけるため、サービスを提供するドメインの設計に注意が必要です。また、複数テナントを利用するユーザーの認証体験や、テナントごとに異なる認証要件への対応など、フロントエンドにも多くの課題が生まれます。
本セッションでは、Passkeyの基本的な知識をおさらいしつつ、これらの課題に対して私たちがどのような選択をしたのかをお伝えします。

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分で説明します。

プログラミングの初学者にとって、セキュリティは後回しになりがちなテーマです。
学んだとしてもスライドや記事を読むだけで、腹落ちさせるところまでもっていくことが難しかったりします。
現場においてセキュリティに関わる「失敗」は許されません。一方で、失敗から得られる学習効果は非常に大きい。このある種の矛盾をどう扱うか、教える側の立場では悩ましい課題でした。
本セッションでは、学習教材として脆弱なアプリケーションをあえて実装し、セキュリティを学ぶという、「失敗を設計する」ことで安全に学ぶアプローチを提案します。
XSSや認可の誤り、状態改ざんなどのセキュリティの問題がどのように起きるのかを可視化し、どう攻撃されるのか、そしてどう防御するのかを理解したうえで、フロントエンド開発で気をつけたいセキュリティポイントを整理します。失敗を経験値に変えるための学習設計を考えます。

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

Astroではドキュメントに「Astro is an all-in-one web framework」と記載があるようにAstro上でReact, Vue, Svelteなどの他のフレームワークを使うことができます。一方で、ReactはSPAの開発によく用いられ、一方でAstroはMPAの開発に用いられ、これらは非常に対照的です。
本セッションでは、これらの対照的なフレームワークが共存する際に、Astro上のReactはどこまでReactなのかに関して議論したいと思います。

現代のフロントエンドのテストはJestやVitestが主流ですが、それ以前に作られたMocha Chai Sinonを組み合わせたテストは今も多くの現場で動いています。
ライブラリのモダン化はしたいものの、全部を一から書き直したり、一度にすべてを置き換えたりすることが難しいというのが実情だと思います。

本トークでは、既存のテストコードを保ったまま、漸進的にVitestへ移行していった話をします。
BabelのRewire PluginやImmutable.jsなど、当時らしい技術選定と絡んでいた部分も含め、どこで詰まり、どのように進めていったかについて紹介します。

また、ライブラリの変遷を追いかけることで、フロントエンドのテスト戦略が時代とともにどう変わってきたかも振り返れるような内容にしたいと思います。

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

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

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

長年フロントエンド開発を支えてきたSass。
登場の背景には、当時のCSSが抱えていた書きづらさを何とかしたい、という強いニーズがありました。

それから時が経ち、CSSそのものも大きく進化しています。
Sassでおなじみの変数やネスト、条件分岐など、Sassが便利にしてきた領域に近い体験を、標準機能で得られる場面も増えてきました。

このトークでは、Sassで馴染み深い機能を題材にしながら、モダンCSSではどう書けるのかを比較して紹介します。
あわせて、CSSの変化を俯瞰的に眺めることで、今後のCSSの進化について考えてみます。

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

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

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

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

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