トーク

iframeは、sandbox属性を利用することで、Webアプリケーション本体と切り離された安全なスクリプト実行環境として利用することができます。

しかしながら、iframeをsandbox化すると、Webアプリケーション本体からiframe内への処理呼び出しや、その逆の呼び出しが直接行えなくなります。

具体的には、それぞれのWindowオブジェクトのpostMessageメソッドと、onmessageハンドラーを利用したメッセージングを行う必要があります。この処理の実装は、目的を最低限満たすだけでもかなり重厚になってしまいます。

Comlinkは、この複雑化しやすいメッセージング処理の実装を単純化してくれるライブラリです。

本発表では、実際に発表者が開発で対面したiframe間通信実装の複雑性による課題と、それをComlinkの導入によっていかに解決したかについて解説します。

BtoB向けサービスのフロントエンドアプリケーションを開発・運営にあたっては、扱うデータの量が時間とともに変化していくため、パフォーマンス最適化は避けて通れない課題となっていきます。
また規模の大きい企業様にご利用いただく場面では、エンタープライズ向けブラウザへも観点を向ける機会が出てまいります。
本レギュラートークでは、私が所属するログラスにおいて、直近数年間のサービス運用を通じて得た気付きや実践的知見をもとに、以下のテーマでお話してまいります。

• データ量の多さと向き合うパフォーマンス向上策: 仮想スクロールなどをはじめ、取り組んだ技術的詳細について紹介
• 知られざるエンタープライズ向けブラウザの存在: Chrome Enterpriseは通常のWebブラウザとなにが異なるのかを紹介します

静的Webサイト生成（以下、SSG）という、テンプレートからHTMLを生成する技術があります。

SSGにはNext.jsやAstro, Gatsby.jsなどが広く用いられています。いずれもフレームワークとして様々な機能を備えている一方、プロジェクトによっては全ての機能を活かしきれず、むしろキャッチアップコストの増大に繋がる場合があります。

このトークでは、シンプルかつメンテナビリティの高いSSGの基盤をVikeで構築した際のケーススタディを紹介します。
具体的にはMeguro.es ( https://meguro.es ) のWebサイト開発におけるVikeの活用方法を通して、いかに少ない工数で壊れにくい静的Webサイトを作成したのかお話します。

プログラミングにおいては、実装ミスや外部入力の誤りなど、さまざまなエラーが避けられません。
これらのエラーが適切に処理されない場合、アプリケーションの整合性や信頼性が低下してしまいます。
また、エラーの表現形式やハンドリング方法によっては、コードの責務が不明瞭になることもあります。

本セッションでは、エラーをどのように表現しハンドリングすれば、コードの責務を効果的に明確化できるのかをTypeScriptの実践例を交えて紹介します。

モーダルとはウェブアプリケーションにおいて主要な画面の上に表示される少し小さなウィンドウです。このモーダルは現在のウェブアプリケーションの開発において(比較的)切っても切れないものになっています。

従来、Reactでモーダルを表示させるにはモーダルの開閉状態を管理していました。しかし、Nextjs13からParallel Routesが導入されモーダルの状態管理から解放されました。
本セッションではNextjsを使ったモーダルの実装例から状態管理をせずにUIを構築できることの良さについてお話ししていきたいと思います

本セッションではフロントエンドをより頑健な実装にしていくための関数型プログラミングのエッセンスについてお話しします。
フロントエンド開発においても「イミュータブル」など関数型プログラミングに関連する概念に出会う機会は多いと思いますが、いざ体系的に学ぼうとすると数学的な定義の難しさや手続き型のコーディングとのメンタルモデルの違いが立ちはだかります。
そこで本セッションでは関数型プログラミングというパラダイムそのものの基本的な考え方やフロントエンド開発に特に有効と思われるエッセンスを実装例と共にご紹介し、フロントエンドエンジニアの目線から関数型プログラミングを紐解きます。

自社や個人で開発しているサービスをスマートフォンで使えるようにする方法はいくつか存在する。

スマホのブラウザで使えるようにレスポンシブデザインに対応することや、PWAであればWebフロントエンジニアが得意な方法だろう。
また、アプリを最近話題のFlutterなどのクロスプラットフォームでアプリを開発したり、もしくはそれぞれのネイティブアプリを開発する選択肢もあるだろう。

どのような選択肢が存在するのか、それぞれのメリットデメリットを考え、どのような場合にはどの選択肢がベターなのかをネイティブアプリ開発者の視点からお話しします。

現代のフロントエンドは様々な技術によって支えられています。ライブラリを使えば解決する課題が多くある時代です。

しかしながら、100%自分たちの解決したい課題にマッチするとは限りません。最後の最後は己の力で帳尻を合わせていく必要があります。

本発表で扱う題材はファイルツリーです。エディタを利用している人であれば1度は見たことあるUIです。様々な仕様が存在し、さまざまな責務との境界に面している場所のひとつです。

基本的なデザインパターンや、アルゴリズムを用いて実装することはもちろん、リアルタイム通信やユーザーインタラクションが発生した場合、どのように実装するのか、一緒に考えていく発表をしたいと思います。

本発表の対象者はJavaScriptを知っている人なら誰でも聞ける内容を予定しています。

GraphQLは非常に強力な技術で、うまく使えばWebフロントエンドだけでなく全体の開発体験やユーザ体験を大きく向上させてくれます。
一方で、使い方を誤るとユーザ体験は悪化し、バックエンドやインフラのエンジニアを苦しめ、フロントエンドにまで生産性低下や将来の負債を生み出すこともあり、使えばそれでOKという技術ではありません。

では、ユーザも関係する全ての開発者も、誰もが消耗せずGraphQLの恩恵を享受するには？
それには実装時の細かなTipsからクエリやコンポーネントの設計, スキーマ設計, アーキテクチャ, プロダクトの構成など、様々なレイヤ・抽象度のものが関係します。

本セッションでは関係者みんなが「GraphQLを入れて良かった」と思えるために、Webフロントエンドエンジニアは何を考え・どのような設計・実装をすべきかを具体的なプラクティスとともに紹介します。

「WebアプリはWebスタックでつくり、アプリはSwiftやKotlinでつくるのが正しい」という考えは根強く、多くの現場でWebフロントエンドとモバイルアプリは別物として取り扱われます。しかしユーザにとっては違います。Google検索でアプリを探すように、アプリストアから自分にあうアプリを探します。気に入ったWebアプリはモバイルアプリで使いたくなったり。

本セッションでは、Webアプリの時はユーザが少なかったアプリが、モバイルアプリをリリースすると多くのユーザを獲得した実例から、プラットフォームの特性やユーザ行動の違い、そしてWebアプリをモバイルアプリ化できるCapacitorの簡単な始め方と、モバイルアプリだからこそできる機能拡張についてお話します。

Webフロントエンドからモバイルアプリ領域に手を広げることで、ユーザに選択肢を、アプリにより大きな価値をつくりましょう！

プロダクトを長期運用していると、定期的なマイグレーションの必要性が生まれます。「フレームワークの記法が変わった」「ECMAScriptにプライベートプロパティが導入された」等、誰しも「本当にこれ手作業で書き換えするの？生産性とは！！！」という経験をしたことがあると思います。

様々なマイグレーションを試みましたが、フロントエンドにおいてはESLintの自作ルールは最強のマイグレーションツールになりえます。本セッションでは実際に公開している @rdlabo/eslint-plugin-rules を例に、ルールとマイグレーションの自作を推奨し、簡単な始め方のご紹介をします。

アラカンおじさんのnakayoshix(なかよしX)こと中村良幸です。ヨーガ歴30年のダルシム系エンジニアですが、現在は隠居系フリーランスとしてデータサイエンティスト兼機械学習エンジニア的な仕事をしています。

私はフロントエンド方面に関しては全くの素人ですが、つい最近Twitter(自称X)にてPythonで作られたWebアプリ作成用ライブラリ『Gradio』の存在を知り、これは面白そうだということで早速使ってみたところ、機械学習向けWebアプリが本当に瞬殺で作れることがわかり、この興奮と感動をこの機会に是非皆さんにもお伝えしたいと思いました。

なお、Gradioで作成したWebアプリはHuggingFaceのSpacesでアプリを公開することも可能で、Stable Diffusionで有名なWeb UIの一つstable-diffusion-webuiもGradioを使用しています。

私のフロントエンドエンジニアとしての経験を踏まえて、プロダクションに積極的に導入したいユーティリティライブラリの選定例と実装例をご紹介します。

ここでいうユーティリティライブラリとは、例えばZod(JavaScript、TypeScriptでスキーマバリデーションを表現できる人気のライブラリ)等のコーディングを補助してくれるライブラリです。

各種ユーティリティライブラリの導入はフロントエンドのアーキテクトにおいて、1つの論点となっています。しかしながら、プロジェクト全体でどのようにユーティリティライブラリを活用していくべきなのか・選定するときの観点は何を重視して判断すべきかの知見は、コミュニティには広まっていないと感じています。

このようなユーティリティライブラリの選定の思考を踏まえつつ、zodと共にts-patternというパターンマッチライブラリの導入例を紹介したいと思います。

例えばSHEIN ( https://m.shein.com/jp/?lang=jp )のWebサイト等に実装されているカテゴリ選択するメニューのようなUIを実装したいと思ったことはありませんか？

iOS/Android等でスタックナビゲーションとよばれるこのUIはSP重視のtoC向けのプロダクトではデザイナーからも人気の高いUIです。
しかしながら、スタックナビゲーションのUIの実装例はコミュニティにほとんどなく、SEOやアクセシビリティ、コンポーネントのメンテナビリティなどの要件を満たしながらWebで実装するのはかなり難しいUIになります。

このようなスタックナビゲーションのUIを各種要件を満たしながら実務で実装した経験を踏まえ、実装するに当たっての考慮点と実装例を紹介します。

フロントエンドにおけるコンポーネント設計の目的と設計方針を整理しながら、私の考えるコンポーネント設計方針(コーディングスタイル)とその意図を丁寧にご紹介させて頂こうと思います。

フロントエンドエンジニアとして業務に携わり始めた5年前からコロケーションの概念を中心にコンポーネント設計方針を自分なりに考え実務で適用してきました。

多くのフロントエンドにおけるプロジェクト・コンポーネント設計論が既にコミュニティで多く共有されていますが、実務に適用するには過剰・不足している点が多いと思います。特によくあるミスマッチは「プロジェクトの規模感に合わない」だと考えています。

私の考えるコンポーネント設計論では、コードベースの拡大を念頭に置きつつも、その時々のコードベースに対して常に最適に変更していける点を意識しています。
このような特徴を持つ私のオレオレコンポーネント設計論を共有します。

現代の多くの Web サイトにとって、Core Web Vitatls のような User-centric なメトリクスは非常に重要です。

Lighthouse などのツールは、計測環境を固定して使用すれば、変化の激しい Web サイトに対しての有効な定点観測手法となりますが、一方で実際のユーザー体験とは乖離することもあります。
New Relic などのオブザーバビリティバックエンドにある RUM（Real User Monitoring）機能では、エンドユーザー端末での実測をするため、ユーザー層や固有のコンテンツに依存したより現実的なデータが得られますが、一方で変数が多すぎるため、ある変更がパフォーマンスに与えた影響を把握するのには向いていません。

本トークでは、実際の Web サイトでこれらのラボデータ・フィールドデータをどのように活用して CWV を改善していくべきか話します。

2023年9月、Svelte開発者Rich Harris氏からSvelte5とRunesが発表されました。1
2024年4月、同じくRich Harris氏がSvelte5のRCを発表しました。2

Runesとは一体何者なんでしょうか。
Svelte4とSvelte5ではなにが変わるのでしょうか。

本発表では、Svelte5およびRunesを簡単に紹介します。

発表者はサーバーサイドの開発に強みを持っていますが、必要に応じてフロントエンドやインフラの開発も行う業務プログラマです。
業務でのフロントエンド開発としては、これまでReact、React Native、Vue.js、Flutter(ネイティブアプリ)などのモダンなライブラリ・フレームワークも利用しています。

発表者は、デザイン、formatterやlinterやビルドなどのフロントエンドツール設定、ネイティブアプリの設定などについて短時間で行えるほど習熟していません。
そういった状況でも一人で行なっている趣味の開発でフロントエンドが必要な場合にFlutter on the Webを用いると大きな時間をかけずに満足いく表現を行えました。

今回はその経験を通じて、似たような境遇の人にFlutter on the Webを選択肢の一つとして紹介します。

本LTではバックエンドエンジニアから見たフロントエンドとの分割における「つらみ」を「状態管理」の視点から明らかにし、軽減するためのアイディアを紹介します。

• 状態の2重管理
• なぜ2重管理になってしまうか
• 対策案

バックエンドのAPIとして、Java/Go/Ruby/PHPなどの処理を呼び、フロントエンドはUI/UXに注力するというアーキテクチャは現在よく取られている手法です。
明確な境界があることで責務は分断され、業務ロジックはバックエンドに秘匿され、多くのメリットが享受できます。

一方でステート（状態）はどうでしょうか？
ユーザーの利便性やわかりやすさのためにフロントエンド側で一時的な状態を保持し、画面を組み換え、POSTします。
フロントエンド側で更新された状態を改めてバックエンド側でチェックし、永続化することが多く、状態の保持に関しては複雑性が増してしまいます。

Nuxt では個々のコンポーネントをサーバーサイドでレンダリングすることができる Nuxt Server Components を提供しています。

このセッションでは Nuxt Server Components が解決する課題、具体的なユースケース、React Server Components や Astro Islands との違いについてお話しします。

このセッションを通じて Nuxt Server Components の機能と利点を理解し、自身のプロジェクトにどのように適用できるかを知ることができます。