私たちの開発体験を高めるものとして、ソースマップは必要不可欠ともいえる存在です。しかし、ソースマップをじっくり眺めたことがある方は少ないと思います。
かく言う私も、「元のコードへの参照を保持してくれるJSONのやつ」という程度の認識でした。しかし改めて中身を見てみると、"mappings"というフィールドには「AAOI;AAPJ,SAASA,kBAAkB...」といった4~6文字程度のアルファベット列がたくさん詰め込まれいています。
これはVLQというアルゴリズムによって生成される文字列なのですが、今回のセッションではこのロジックなどを中心に、ソースマップがどのように生成され、元のコードへの参照をどのように保持しているか説明します。
私が所属しているカミナシでは、AIによるラベル検査機能をリリースしました.
これは端末のカメラで撮影したラベル画像から異常を判断するもので、従来はフロントエンドで撮影した画像をGPU搭載サーバへ送り推論結果を返していました。しかし通信待ち時間や運用コストの問題があります。
そこで今回は、フロントエンドならではの問題を克服し、C++で実装した推論処理を呼び出すWasmを採用。Wasmのバイナリを約9MBまで圧縮し、SIMD最適化やLazy Loadingを駆使しブラウザ上で約200msの高速推論を実現しました。また、Wasm開発時・リリース時に陥りがちな問題や、押さえておきたいメモリ管理やキャッシュ制御、エラーハンドリングのポイントも交えてご紹介します。
実際にこれらに関する一部のことは記事で紹介しています。
https://tinyurl.com/3rwtwa3m
ハイパーメディア駆動アプリケーション(HDA)アーキテクチャは、従来のマルチページアプリケーション(MPA)の単純さと柔軟性に、シングルページアプリケーション(SPA)の操作体験を取り入れる設計アプローチです。本セッションの前半では、HDAの設計思想に基づく実践例として、htmxを用いたWebアプリケーションの画面遷移や状態更新の設計手法を具体的に紹介します。後半では、局所的な動的振る舞いが求められる場面において、Islandアーキテクチャを取り入れて補完する方法とその設計上の工夫について考察します。
「useEffectってなんかわからんけど使わない方がいいらしい」
ReactのuseEffectって便利ですよね。
ですが本来の用途とは異なる使い方をされることが多く、公式ドキュメントにも「そのエフェクトは不要かも」という項目が作られるほどです。
しかし非推奨ではなく本来使われるべき用途があります。
正しい使い方とは何か?AIにコードを書かせるとuseEffectを多用する部分も見られ、正しく使っているか見極める必要性が増してきました。
本セッションでは、useEffectの役割を使用例を交えながら説明します。
なぜ非推奨と言われるような風潮になっているのか、現代のライブラリ事情も合わせて解説します。
useEffectの使い方を見極められるようになれば幸いです。
フロントエンド開発においてよく使われるようになったTypeScriptはJavaScriptに型の構文を追加した言語ですが、そのままではブラウザで直接動かすことはできず、実際に動かすにはトランスパイルやバンドルを経て最適化を行う必要があります。
発表では、TypeScriptのコードがどのようなプロセスを経てブラウザで動作するのかを図解しながら、5分で誰でも理解できる発表を目指します。
「とりあえずTypeScriptを書いて(AIに書いてもらって)画面に描画されているからOK」の段階を卒業し、ビルドプロセスを理解することは開発効率向上、トラブルシューティング精度向上、パフォーマンス配慮、さらにAIネイティブの若手育成など、TypeScriptを自由自在に用いることができるフロントエンドエンジニアとして成長するために、様々な効果が期待されます。
研究の世界が抱えているフロントエンド課題について発表します。
皆さんは普段とあまり接点がない領域かもしれませんが、新しい視点として興味を持ってもらえたり、この分野に挑戦してみたいと思うきっかけになればと思います。
学術論文は、複雑な数式を含むことや研究者自身による執筆・整形・公開が特徴の、現在主にPDF形式で配布されるの存在です。しかし、PDFは見た目を忠実に再現する一方で、文章構造や意味の保持が困難
です。近年、アクセシビリティ向上等のためにウェブ版の論文も増えていますが、多くの課題を抱えています。出版社によるウェブ版の残念な事例と優れた事例の両方を取り上げます。最後に、先進的な取り組みとして、arXiv.orgの論文をHTML化する「ar5iv」プロジェクトと、PDFの意味構造を豊かにするLaTeXの「Tagged PDF」プロジェクトを紹介し、この分野の未来と可能性について話します。
Matter.jsは、Webブラウザで手軽に物理演算を扱える比較的軽量なライブラリです。例えば、以下のような表現が可能です。
・オブジェクトが重力や衝突で自然に動く表現
・ユーザー操作に反応して弾む・転がるインタラクション
・配置や衝突判定を伴うインタラクティブな演出
・物理法則に基づいたアニメーションによる動的UI
一方で、描画や更新の扱い方によってパフォーマンス面での課題が生じやすくなります。
本発表では、配信画面デザインサービスにおける事例をもとに、Reactと組み合わせた遊び心満点の物理エフェクトの実現方法を紹介します。
エンジン共有や再計算の抑制といった設計上の工夫から得られた、物理演算をWeb表現に活かすための実践知を共有します。
あなたのWebサイトも、手頃に「ぷにゃっ」と動かしてみませんか。
普段の開発を行っていると、mdnのCSSリファレンスを端から読むことってそんなに多くはないと思います。
ですが改めて読んでみると、「知らなかったけどこれは便利だな!」というものから「このプロパティいつ使うん?」とつい思ってしまう様なマイナーなものまで、様々なプロパティと出会うことができます。
今回の発表では、mdnのCSSリファレンスを全て読んで見つけたマイナーなプロパティを紹介しながら、何とか業務内でも用いることが出来そうな用途を可能な限り捻り出して紹介します。
「自分でmdnを通読するのはめんどくさいけど、何か面白いものがあるなら知りたい!」という贅沢な方々に向けて、すぐに業務に役立つ訳ではないけれど知っておくといつかどこかで使えるかもしれない知識をお届けします。
「overflow: auto を指定したのに横スクロールできない」「長いコンテンツが親要素を突き抜けてしまう」そんな経験はありませんか?
私自身、横スクロールが効かない問題に直面した際、原因は親要素に設定された flex-direction: row でした。
実は、こうした構造的なレイアウト崩れは、FlexboxではなくGridを使うことでスマートに解決できるケースが少なくありません。
本LTでは、実際に遭遇した問題を通じてFlexboxの仕組みを解説しつつ、Gridレイアウトがより適切な選択肢となる理由をお伝えします。
min-width: auto の罠、不要なdivの増加、非セマンティックなHTML構造といった問題が、Gridでどのようにスマートに解決されるかを実例を交えて紹介します。
「とりあえずFlex」から一歩進み、意図に応じたレイアウト手法を選べる開発者を目指しましょう。
「あ、このアニメーション気持ちいい!」 - そんな体験には再現性があります。
本セッションでは
をデモ中心で解説します。
フロントエンド初級者でも「セッション後すぐに試せる」具体的 Tips を持ち帰れる内容です。
モノリス化が進んだプロダクトの中で、「ユーザー影響の少ない画面から段階的にフロントエンドを切り出していこう」
そんな構想から始まった、バックエンド・フロントエンドの分離プロジェクト。
Next.js を使い、OpenAPIで型生成を行い、アーキテクチャパターンを学び…将来的にプロダクト全体への展開も視野に入れていましたが、
結果的に今は「撤退」を選ぶことになりました。
本セッションでは、どんな構想を立て、なぜ実行に移し、そしてどこで限界を感じたのかをリアルに共有します。
同じようにフロントの切り出しを検討しているチームにとって、立ち止まって考えるきっかけになれば幸いです。
package by featureは、機能や関心ごとにディレクトリを切るディレクトリ構成です。
/hooksや/contextsといった技術ごとにディレクトリを切るpackage by layerはひとつの機能が分散して配置されるのに対して、package by featureはひとつの機能が一箇所にまとまっているのが特徴です。
しかし、実際にどのようにfeatureを切っていくのかについて取り上げている情報は、まだ少ないように感じます。
一方で、コンポーネントのDomain(関心)に特化した分類には、コンポーネントを関心・状況・基礎の3つの軸で分類することで体系的に管理できるBCD Designという手法があります。
そこで、本セッションではBCD DesignにおけるDomainの概念を応用し、featureをどのように切り出していくのかについて具体例を交えて紹介します。
デザインシステムは、思想や原則といった「ルール」、再利用可能なUIコンポーネントである「実装」、それらの利用方法を示す「ドキュメント」の3要素で構成されます。
特に「ドキュメント」は、デザイナーとエンジニアとをつなぐ共通言語として極めて重要な役割を担います。
ドキュメントが参照しやすく、運用しやすいかたちになっていないデザインシステムは、その機能を発揮できないまま腐っていくことでしょう。
このトークではそんなデザインシステムの根幹をなすドキュメントサイトの技術選定について話します。
ドキュメントサイトに必要な要件を整理し、それらを満たすための最適な技術は何なのかについて考えます。
加えてドキュメントサイトのユーザビリティや生成AI活用のために注意したいポイントなどについても解説します。
私が2021年に公開して、現在もシェアが続いている「俺流レスポンシブコーディング」は、当時現役だったIEのためにほぼメディアクエリに依存した実装の紹介となっていました。
しかし、IEがサポート終了した現在では、grid, min(), max(), clamp(), コンテナクエリといったレスポンシブコーディングにおける「ゲームチェンジャー」的な機能が広く利用でき、メディアクエリへの依存度を大きく下げることが可能となりました。
このトークでは、これらのモダンなCSS機能を駆使し、「メディアクエリは適した場面でのみ使用する」ことを目指す、Intrinsicなレスポンシブコーディングの手法を紹介します。
また、progress(), スタイルクエリ, if(), Anchor Positioningなど、将来のレスポンシブコーディングをさらに進化させる機能についても予習として解説します。
「HTMLって単なるマークアップ言語?JavaScriptがないと動的なUIは作れない?」そんな固定観念は、もう捨ててください!
実はHTMLはここ数年で革命的な進化を遂げ、かつてないほど表現力豊かで強力な言語になっています!これまでJavaScriptの実装が必須だったポップアップやモーダル、複雑なインタラクション、パフォーマンス最適化など、多くのことがHTMLだけで、宣言的かつシンプルに実現できるようになりました。
本トークでは、そんなモダンHTMLの持つ真の力を凝縮してお届けします。
「Conditional Types、Infer、Recursive Types...」TypeScriptの複雑な型を学んでも、仕事で活用する機会はあまりありません。
しかし、これらの型は、私たちが日常的に使っているライブラリの内部で重要な役割を果たしています。
ライブラリ側で複雑な型定義が行われているからこそ、私たちは柔軟かつ型安全にライブラリを利用できます。
本セッションでは、TanStack Routerの実際のコードを理解することで、複雑な型定義がどのように使われているかを解説します。
フロントエンドステート管理の大きな潮流に細粒度リアクティブステート管理 (fine-grained reactivitiy) が挙げられます。Solid.js や Svelte, Angular, Vue, Preact など様々なフレームワークで採用されている考え方で、Signals として TC39 で標準化の議論もはじまっています。
本セッションでは、React を題材にフロントエンドステート管理の歴史を紐解きながら、各時代が解決した課題と限界を振り返りつつ、なぜ細粒度リアクティブという考え方が必要になったのか、また、新しく見えてきたスコープ管理という設計課題を考えていきたいと思います。
その上で、Jotai / Bunshi を導入した実プロダクトでの事例をもとに、細粒度リアクティブステート管理における実践的なスコープ設計の解決策を紹介します。
皆さんはフロントエンドテストを書いていますか?
バックエンドテストがあるのに、フロントエンドは手つかず。そんな現場は珍しくありません。
私たちのプロダクトも、テストがあったものの重要な部分はカバーされていない状態からスタートしました。
「何を、どこまでテストすべきか」 が曖昧なままでは、導入は前進しません。
そこで私たちはクリティカルユーザージャーニーに絞った「必要十分」なテスト戦略を策定し、
限られた工数で最小の投資から最大の品質向上を実現し、壊れにくいテスト基盤を構築しました。
本セッションでは、
これらを具体的なコード例とともに紹介し、堅牢なフロントエンドテスト基盤を構築する方法を共有します。