プロポーザル

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

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

テーマ

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

目次

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

背景

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

概要

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

目次

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

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

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

話すこと

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