JSConf JP 2024 に参加しました！
はじめに
2024/11/23 に開催された JSConf JP 2024 に参加しました。
今回が初参加です。
気付いたらチケットが売り切れており、 waiting list に登録して購入できました 🙌
また、各セッションはライブ配信されており、当日現地参加できなかった方も視聴できるようです。ありがたいです。
最大4トラック進行されていました。セッション数が多く、ボリューミーなカンファレンスでした。
聴いたセッション
LT: Promise.try: シンプルで強力な同期/非同期統合の未来 - 実装の深層とPromiseの進化
Primise.try にまつわる話でした。
「Promise.try は Promise 不要の then のようなもの」とのこと。
そもそも需要があるのか？という点が疑問視されたため、導入が遅れたようです。
Promise の動向を知らなかったので、大変参考になりました。
LT: JavaScriptを支えるエコシステム（漫才）
タイトル通り、漫才しながら 各技術スタックそれぞれの特徴（あるある）を話す、軽快なセッションでした。楽しく聴かせていただきました！
LT: Storybook との上手な向き合い方を考える
Storybook の導入は簡単になってきましたが、恩恵を受ける目的を明確にして導入しようという話でした。
私も個人的には Storybook によるテストは時期尚早と感じており、共感することも多いセッションでした。
LT: あなたの知らない Function.prototype.toString() の世界
「メソッドの内容を文字列で取得できるAPI」についての解説セッションです。
Object.prototype.toString() ではなく Function.prototype.toString() があるとは知りませんでした。
直近、自分が使うシーンは思い浮かばなかったのですが、自分の意識の外のAPIに触れる機会になり、ありがたいです。
React への依存を最小にするフロントエンドの設計
React というより、vanilla js 以外のすべてのフレームワークやライブラリへの依存を最小にする、という意識で取り組んでいるというセッションでした。
長寿プロダクトにおいて、特定のフレームワークやライブラリへの依存は、変化への追従コストになるというお話は、実体験を伴っており説得力がありました。
ライブラリなどの選定理由や意思決定、設計についても具体的に触れられており、大変参考になりました。
React CompilerとFine Grained Reactivityと宣言的UIのこれから
「仮想DOM を使う宣言的UI」、「仮想DOM を使わない宣言的UI」、それぞれの方向性についての解説セッションでした。
「仮想DOM を使う宣言的UI」としては、React Compiler がキャッシュによる仮想DOM のレンダリングコストを軽減しようとしており、
「仮想DOM を使わない宣言的UI」は Svelte 5 や Vue Vapor が Signals (単一の値を持ち、その値が変化すると通知できる) を利用して ネイティブDOM を返却する Fine Grained Reactivity を導入していくようです。
レンダリングコストの面からライブラリの方向性をまとめた内容で、大変参考になりました。
Vapor Revolution: Unleashing Vue evolution and Potential with Vapor Mode
実は PLAID さんのイベント にて、登壇者である kazupon さんから
「Vapor で vue.js と svelte と react のコンポーネントが同居できるようになる話をします」
といった前情報が出ており、個人的に本セッションを非常に楽しみにしていました。
Vapor について、内部でどのような処理を経ているのかが丁寧に説明され、
Vapor が採用した IR (Intermediate Representation) アーキテクチャによって Vue.js 以外のフレームワークのコンポーネントテンプレートに対しても変換処理を代替できるのでは、という可能性を検証している、というお話でした。
検証中のプロジェクトはすでに OSS として公開されているようです。
セッション中のデモで、vue.js, svelte, react のコンポーネントが 1画面に同居しているのを見るのは やはりワクワクしました。
vue.js にまつわるライブラリは vue.js 自身のみに門を狭めることもなく、汎用的に利用できる道を模索する姿勢で、つくづく頭が下がります。
これからの Vapor も楽しみです。
幸せの形はどれも似ているが、不幸なプロジェクトはそれぞれの形がある
フロントエンドにおいて、Web サイトの計測の重要性と、解決アプローチの順序などのノウハウを共有するセッションでした。
あまり本格的に Web サイトの計測に取り掛かったことがなく、どういう考え方で計測していくのかというところからイメージが掴みやすく、大変ありがたいです。
業務でも意識して「推測ではなく計測」するようにします。
リアルアセットとWebのシームレスな活用のためのパスキー
「ログインに時間がかかって電車に乗り遅れてしまうユーザを救いたい」と、ログインにかかる時間を短縮するためにパスキーを導入したという話です。
さまざまな IT リテラシーのユーザを抱える中、まだ一般的に浸透していないパスキーを導入して、当初の課題を解決するために、あらゆる方面から対策を重ねていく姿勢が素晴らしかったです。
JavaScriptのモジュール解決の相互運用性
CJS, ESM (= Native ESM, Fake ESM, Sloppy ESM) におけるパス解決の挙動や、どのライブラリがどれに当てはまるのか等を詳細に調査したセッションです。
（なお、Sloppy ESM は登壇者の方が便宜上命名した分類、というお話だったと思うので注意が必要です。）
tsconfig.json に設定する paths で、よく利用されている @ が実は非推奨であることが一番衝撃でした。 # がいいらしいです。とはいえ文化が根強いので、いきなり変更するのは難しそうですね…。
Modular Monolith Monorepo
monorepo をただ単に「1リポジトリに複数アプリをまとめる」とするのではなく、"同居するからこそ" の利点を追求した設計にしているというセッションでした。
多くの意思決定の実例、仕組みとして導入していることの共有など、 monorepo として管理していく上で参考になる情報がたくさん込められていました。
発表中で、あらゆる意思決定のプロセスを残したものとして Design Docs の紹介がありましたが、機能や設計だけではなくライブラリ選定も含めていたようで、 ADR (Architecture Decision Records) とは区別して扱っていなさそうでした。細かく意思決定を分類するより、そちらのほうがスピード感のあるプロセスが取れるのかもしれません。
また、バージョン管理ライブラリとして pnpm を採用されているようだったのですが、もし別の言語を利用することになって pnpm catalogs で管理できなくなったら、そのときは monorepo を分割する選択をするのでしょうか？ 機会があればお話伺ってみたいです。
大変興味深い内容でした。
JavaScriptのイテレータとイテラブルの概要と課題、未来
イテレータとは、イテラブルとは、JavaScript でどのように実装されているものなのかを深掘りして解説するセッションです。
イテレータを自分で実装できるという視点がまったくなく、イテレータについての解像度がかなり上がりました。視聴者の視野を広げさせる素晴らしい内容でした。
イテレータチャンス、見逃さないようにしたいです。
おわりに
JavaScript にまつわるたくさんの事例に触れ、刺激にあふれたカンファレンスでした。
初参加ながら、非常に楽しく過ごさせていただきました！
心残りは、セッションに集中しすぎてスポンサーブースをぜんぜん回れなかったことです…。時間配分難しいですね。
たくさんのセッションがあり、現地で聞くのを諦めたセッションも多かったのですが、かなりの方々が登壇資料を公開してくださっているので、これから読んでいきます。ありがたいです。
こうして様々な知見に触れることができたのも、運営に携わった方々、登壇者の方々のおかげです。本当にありがとうございました！！
Discussion