皆さんはフロントエンドの技術をどのように身に着けていますか？
おそらく勉強会に来られるような方であればなにかしらの素振りはしているでしょう。
しかし、新しいフレームワークやライブラリが出る度に毎回ブログを作っていませんか？これでは退屈な気がします。
かといって、個人で運営が必要なWebサービスづくりはハードルが高いでしょう。
その中間、ちょっとしたネタアプリやミニゲーム、ツールづくりは非常にオススメです。実用に近いところで技術的な評価もでき、メンテナンスも強く求められないちょうど良さがあります。

そこで本セッションでは自分が技術的な素振りをするに当たって、テーマ選びや技術選びで意識していること、素振りの実例を紹介します。
仕事ではチームで回せる技術やデザインに落ち着かせるでしょう。個人で作るのであれば、ちょっとだけワクワクするものを作って仕事にも使える技術やスキルを身に着けましょう。

FigmaやMiroのようなGUIでドラッグアンドドロップ出来るようなWebアプリを誰しも一度は作りたくなったことはあるのではないでしょうか？
高度なWebツールやゲームを作成しようとするとWeb上でGUI操作を行いたくなることは多々あると思います。
このセッションではWeb上でドラッグ＆ドロップを実装する幾つかの方法についてサンプルコードを用いながら深掘りしていきます。

Laravel 9.x からバックエンドのバリデーションルールを使ってフロントエンドでリアルタイムバリデーションを行うことができる Laravel Precognition という機能が追加されました。

Precognition ライブラリを使う中で見つけたバグを修正して PR を出した話や、普段見ることの少ないライブラリの裏側で何が起きているのかについて解説しながら、Laravel でのリアルタイムバリデーションのやり方について紹介します。

目次

• Precognition とは
• リアルタイムバリデーションのやり方
• ライブラリの仕組み
  • コアの処理について
  • フロントエンドツールでの差分
  • ライブラリのバグ修正

日経電子版は法人および個人のお客様から多くの環境でアクセスされており、私たちは、Webアプリケーションのユーザー体験と開発効率を向上させながら、より多くのユーザーに安全な利用環境を提供することを目指しています。 そのため、開発チームではブラウザのサポートポリシーを継続的に検討し、アプリケーションのビルド設定を最適化しています。

このLTでは、toC Webサイトにおいてエンドユーザーに提示する理想的なブラウザサポートポリシーと、実際のアクセス状況を考慮した現実的なブラウザポリシーのバランスについて議論します。また、各ブラウザベンダーのリリースサイクルを考慮し開発チームがどのようにブラウザサポートポリシーを調整しているかの知見も共有します。

GraphQLを採用することにより、型安全性やデータフェッチの柔軟性などの恩恵を享受することができます。
一方で、GraphQLのメリットを最大限活用するためには、キャッシュ戦略やFragment Colocationなど、考慮するべきこともいくつかあります。これらを踏まえてどのGraphQLクライアントを採用するかは非常に重要です。
そこで、このセッションではGraphQLクライアントに求められる要件と、技術選定の観点を具体的な事例を交えて紹介しようと思います。

具体的には下記の内容をお話しする予定です。

• GraphQLのメリットとユースケース
• キャッシュとFragment Colocationの重要性
• GraphQLクライアントに求められる要件
• GraphQLクライアントの紹介と比較
  • Relay, Apollo Client, urql
• 具体的な選定事例

近年CSSにはlayerやscopeなど大きな新機能が提案・実装されています。これらはCSSのcascadingという基本的なモデルに新しい概念と柔軟さを与え、フロントエンドの開発者にとってはCSS設計のパラダイムを変えるほど大きなものです。
このトークでは、それらCSSのcascadingに影響を与える新しい提案と機能について紹介し、それらが今後の開発にどのように影響を与えるかを考察し、聴講者の皆様が今後のCSSについて考えるきっかけを提供します。

株式会社ヒューマンサイエンスが提供するJamstackサイト構築において、ヘッドレスCMS『storyblok』をオフショア開発先との協議において選定しました。日本ではあまり知られていないstoryblokの特徴や機能を紹介したいと思います。
また海外の開発先とのJamstack構築の経験を共有したいと思います。

1．storyblokの紹介
機能概要
ビジュアルエディターでの管理画面デモ
2．Jamstackをオフショア開発した知見
どこにどんな風に
プロジェクト詳細
苦労話と学んだこと

実際に使用してみた上でのstoryblokのヘッドレスCMSとしての魅力と、グローバルな視点でのプロジェクト実施の経験を紹介したいと思います。

少ない工数で開発を進めなければならない時があります。 そんなとき、フロントエンド開発と既存のサービスを組み合わせると、想像以上に柔軟性を維持でき、早くモノが出来上がる場合があります。このような開発手法は、フロントエンドエンジニアの戦闘力を安易に増大させる具体的なものだと思います。今回は一例としてHeadlessCMSを使った方法を紹介します。

例えば、自社HPやメディアサイト。
顧客が見る画面と運用者が見て管理する画面を用意する必要がある場合について考えてみる。
3つのアプローチ

1. STUDIOなどのノーコードツールを利用したアプローチ
2. フロントエンドとバックエンドをスクラッチで開発するアプローチ
3. フロントエンドはスクラッチ開発して、バックエンドはheadlessCMSを利用するアプローチ

これらの3つのアプローチを比較し3の優位性を示していきたいと考えています。

iOS/Androidアプリを１つのコードで作れてしまうFlutter、Googleゴリ押しのこのフレームワークは今ではWEBアプリやデスクトップアプリ、組み込みアプリの開発にも使えるようになっています。
そんななんでも(?)出来るFlutterですが、モバイル開発での実務での使用は弊社や他社でもそれなりに実績がある印象を受けますが、WEBアプリで使用された話は僕の周辺ではあまり聞きません。
果たしてFlutter for WebはReactやVue.jsなどのようにある程度の実務で使用できる領域まで進化を遂げているのか検証をしてみました！

2022年6月に HTTP/3 が RFC で標準化されてから一年以上が経過し、 HTTP/3 を利用しているサイトは 25% を超えているようです。
しかし、 HTTP/3 が HTTP/2 と比べてどう変わったのか、フロントエンドの領域でどのように貢献するのかといったことを把握していない方も一定数いらっしゃるのではないかと思います。

このセッションでは

• HTTP/3 や QUIC の概要
• TCP と UDP の違い
• HTTP/3 は HTTP/2 の何を改善したのか

といったことに触れつつ、 HTTP/3 がフロントエンドの領域でどのような貢献をするのかといったお話しができればと思います。

個人開発や研修では自由な技術選択が可能ですが、業務では異なります。特に、ReactがメインのチームでNext.jsを導入しようと考えた場合、多くの制約と納得が必要です。
内心ではNext.js導入が最善だと感じつつも、それだけでは上長を説得できません。
そこでNext.jsの良さを具体的に示すため、Reactとの比較、利点・欠点の調査、導入の障壁と解決策を掘り下げ、上長に提示しました。
結果、新規サービスでのNext.js導入を決定しました。

本トークでは、Next.js導入の経緯、課題と解決策、おまけとして状態管理ライブラリの選定について共有します！

背景

Webフロントエンドという領域は最もユーザーに近しい領域です。だからこそ多くの人々に価値を伝えるため数々の施策をスピード感を持って打っていく必要があります。一方でサービスの成長に伴い、コードベースのサイズも肥大化しその結果ビルドパフォーマンスの悪さが開発を回す上で大きなボトルネックになることに陥いがちです。UXと同じくDXの改善も重要でしょう
そこで日経電子版という巨大で息の長いコードベースでのビルドパフォーマンスの改善の取り組みと、皆さんのフロントエンド開発を爆速にできるような知見やtipsを紹介します

Agenda

• JavaScriptの処理系が変わるアグレッシブな変更を日経電子版ではどう安全に適用していったか
• CSSinJSなどbabelでしか扱えない処理系を抱えながらもなるべくswcで処理されるようにしてビルドを更に高速化する取り組み
• 知見、効用

UX is 「爆発だ」

• VEと異なりUXは定量化しにくい
  →ユーザーの感情を重視する = 芸術

UX is 「思いやり」

• 相手の立場に立って物事をかんがえること、顧客中心主義
• 具体例
  • 不適切な説明テキスト → 配慮が足りない
  • 過剰なオプション設定 → ありがた迷惑

UX is not 「特別なこと」

• ユーザーとの接点がないと思っている業務にも、ユーザーはいる。
• 具体例
  • コーディング → あなたの書いたコードを改修したり、あなたの書いた関数を利用する他の開発者はユーザーである
  • 読みやすさや再利用性を考えて設計・実装する ＝　UXを向上させている
  • 議事録を書く → あなたの書いた議事録を読む他のメンバーはユーザーである
  • 要点をハイライト、要約も合わせて投稿する = UXを向上させている

ソフトウェアを開発するにあたって、デザイナーとエンジニアの良い関係性とはどのようなものなのでしょうか。
デザイナーとエンジニアの関係性は組織やチームによって異なりますが、昨今ではデザインシステムの文脈でもデザイナーとエンジニアの協力関係が重要になっています。
今回のトークでは、とあるUIコンポーネントの開発プロジェクトをもとにデザイナーとエンジニアのコラボレーションの意義とUI品質を底上げするための取り組みについて紹介します。

▼内容
・デザイナーとエンジニアの関係性において起きる課題
・ソフトウェアにおける品質の定義
・UIコンポーネント開発においてデザイナーとエンジニアが協力するための取り組み
・デザイナーとエンジニアのコラボレーションが品質に与える影響

@shadcn/uiやTailwind LabsのCatalystを中心に、自分のプロジェクトにコードをコピーペーストで追加するコンポーネント集が注目を集めています。一見古臭い方法のように思えますが、必要なコンポーネントを選んでプロジェクトにコピペで導入することには大きなメリットがあります。

従来のコンポーネントライブラリはnpmやCDN経由で導入し、コードの中身には触れず、スタイルは上書きしてごまかしつつ運用する必要がありました。
しかし、こういった形態のコンポーネント集はコードが手元にあるため、カスタマイズが柔軟に行えます。余白などのスタイリングはもちろん、使わないボタンサイズや影など、不要なプロパティを削除できます。新しいコンポーネントの追加も作法を守れば簡単です。

こういったコンポーネント集のメリット・デメリットや、実際にカスタマイズしながら実務で導入した例を紹介します。

概要
HTMLでユーザー登録のフォームを作成するとき、正しく<input>のautocomplete属性を指定すると、入力したパスワードとユーザー名をパッスワードマネージャーに保存されて、 ログインの場合はパスワードマネージャーからユーザー名とパッスワードが取得されます。 このトークでその属性を紹介します。

内容

1. autocomplete属性について
2. ユーザー登録フォームに使えるautocompleteのvalues紹介
3. ログインフォームに使えるautocompleteのvalues紹介

テーマ

The frontend framework is a backend framework.といった形でフロントエンドの価値を再定義し、T3 Stackなどの話題にも触れながらフロントエンドの最近の技術と潜在的な魅力を伝えること
（普段はほぼNext.jsしか使ってないですが、NuxtやSveltekit、freshなども話題に盛り込めたらと思います）

目次

はじめに
フロントエンドとバックエンドの比較
フロントエンドフレームワークの実態
フロントエンドエンジニアにできること
T3的な思想と技術
まとめ

背景

Next.jsなどのフロントエンドフレームワークでは、フロントエンドといいつつAPI作成などバックエンド領域の機能が備わっていて、フロント完結でも多様なアプリケーションを作れるようになりました。
その中でのフロントエンドの楽しさを体系化します。

概要

流れの早いフロントエンド界隈で、さまざまな技術が日々進化しています。
その中でも注目を浴びたトピックである「RSC」。
そんなRSCをいち早く使いこなすためのTipsを紹介します。

目次

• はじめに
• RSC とは
• RSC の特徴
• 実際の実装とコード（クライアントコンポーネント）
• 実際の実装とコード（RSC①）
• 実際の実装とコード（RSC②）
• まとめ

内容

RSCのデータ取得周りの特徴を活かして、UX向上のためのTipsを紹介します。
まずはクライアントコンポーネントを使用した場合の実装を紹介します。
その後に「サーバーでのデータ取得」に着目した惜しいRSCの使い方を紹介して、その上で抱えている問題点を明示します。
そして、結論としてこれまでに提起した問題点に対する解決策として「非同期を解決しない」RSCの使い方を紹介し、まとめに入ります。

概要

普段Androidアプリエンジニアをしている私ですが、趣味でフロントエンドエンジニアの友人と開発する機会がありました。
その際に「型」という言葉の解釈で話が噛み合っていないことに気付きました。
その理由はTypeScriptとKotlinの型システムが異なっているという点にありました。
TypeScriptの型システムを「構造的部分型」、Kotlinの型システムを「公称型」といいます。
本トークではUIの実装例を題材としながら、それらの型システムの違いを学んでいきます。

目次

• はじめに
• 公称型（Kotlin）での型定義
• 構造的部分型（TypeScript）での型定義
• Jetpack Compose（Kotlin）でのUIの実装
• React Native（TypeScript）でのUIの実装
• 結論（公称型と構造的部分型の違い）

フロントエンドのテストは壊れやすい、めんどくさいなどの理由でやらない選択してました。
みなさんもそんな経験ありませんか？

アクセシビリティを理解するとフロントエンドのテストが楽になる！し、
フロントエンドのテストを書くとアクセシビリティが理解しやすくなる！

話すこと

• WAI-ARIAとは
• アクセシビリティを理解するとテストが楽になる仕組み
• テストを書いていて気づいたWAI-ARIAの誤解