「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？
みなさんこんにちは。
「あの人も読んでる」、第13回目の投稿です。maguro（@yusuktan）がお届けします。
さて、10月と11月は数々の技術カンファレンスが開催されました。カンファレンスの秋ですね。僕も毎週のように何かに参加して、興味のある発表を聞いたり、休憩スペースで大学院の試験勉強をしたりしていました。カンファレンスごとにテーマが違うのはもちろん、運営陣・登壇者・参加者が一体となって作り上げる雰囲気もそれぞれ異なっており、それを直に感じられるオフラインのカンファレンスは良いなと改めて感じました。
今回はそんなカンファレンスで僕が聞いた発表の中から、JavaScriptに関するものを3つご紹介していこうと思います。
JavaScriptにおけるasync/await呼び出しのスタックトレースの困難と実装
まず1つ目は、sosukesuzukiさんによるJSConf JP 2025での発表です。
SafariやBunなどの内部で使われているJavaScriptエンジンであるJavaScriptCore。ここでasync/awaitを使用すると、例外が発生したときのスタックトレースが不完全になってしまうという問題がありました。具体例として、以下の例が紹介されています。
async function foo() {
await bar();
}
async function bar() {
await 1;
throw new Error("oops");
}
foo().catch(e => console.log(e.stack));
このコードを実行したとき、プログラマとしては以下のようなスタックトレースが得られることを期待します。つまり、エラーがthrowされた箇所 bar に至るまで、どのような関数呼び出しが連なっていたのか――この例で言うと、bar が呼び出される前に foo が呼び出されていた、という事実が出力されることを期待します。
Error: oops
at bar (test.js:6:13)
at async foo (test.js:2:16)
しかし、実際には以下のように foo の情報が欠損してしまっていました。
Error: oops
at bar (test.js:6:13)
この欠損という挙動は、JavaScriptのセマンティクスを考えれば説明ができるものの、JavaScript利用者の立場からすると不便であることには変わりありません。そこでsosukesuzukiさんは、JavaScriptCoreに対して修正を加えることで、この問題に対処しようとしました。
具体的には、JSGenerator、JSPromise、JSPromiseReactionといったJavaScriptCore内部のデータ構造を辿ることで、コールスタックに依存しない形で半ば無理矢理に呼び出し元情報を復元していく、という手順が解説されていました。
さらにややこしいことに、これだけでは「関数が呼び出された位置」の情報は復元できず、さらに追加で、async関数に対応するバイトコードから位置情報を取得するというステップを踏む必要があることも説明されました。
普段何気なく活用しているスタックトレースも、async/awaitが絡むとかなり実装が複雑になっている、ということを知りました。
また、JavaScriptCoreのような大規模なソフトウェアに対して、何か機能追加・修正したくなったとき、幾つものデータ構造が複雑に参照し合っている状態を把握し、実現に向けた道筋を解きほぐす能力が必要不可欠だと感じました。
一人で大規模OSSに立ち向かうには
さて、前節を「JavaScriptCoreのような大規模ソフトウェアにコントリビュートするのは大変だ」という感想で締めました。では当のsosukesuzukiさんはどのようにJavaScriptCoreに関わり始め、ついにはReviewerになり、さらにそれがきっかけでBunで職を得るに至ったのか。それについて語られているのが、同じくsosukesuzukiさんによるYAPC::Fukuoka 2025での発表です。ちなみにReviewerとは、もっとも強い権限を持つ人で、他人のパッチをreject/approveできる立場のことです。
僕自身も、Denoに趣味でコントリビュートし始め、継続的にやっていたらそれが仕事になり、という経緯をたどってきたこともあって、首がもげるほどうなずきながら発表を聞いていました。
特に「時間を可能な限り捻出して、可能な限り集中して使うこと」という点が強調されていましたが、これは何か新しいことに取り組む際に大なり小なり必要になってくる要素だと僕も思っています。
コンフォートゾーンを抜けて、新しいことに挑戦しようとするとき、分からないなりにもがいて、「よしできた」と思ったら実はできてなくて、さらに頑張って、なんとかちょっとのことを成し遂げる。こういう一見非効率的に思える時間の使い方をすることで、いつの間にか、それまで断片的だった知識がつながりを持ちはじめる。これが大事だと思っています。
あとは「仮説を立てる、仮説を検証するために手を動かす、後の自分に何かが残るように」という点も強く共感しました。
未知のものに立ち向かう際、全体像をざっくり把握する、個別についてもデバッガやプリントデバッグで理解していく、そしてそこで構築した「メンタルモデル」をベースに、仮説を立て、その仮説が合っているかを検証し、メンタルモデルを絶えず修正していく――今まで僕の中でもあまり言語化ができていませんでしたが、これを聞いて「自分がやっていることだ！」とすぐに思いました。
凄腕のエンジニアはこの「仮説立て→検証」のサイクルが異常に早いという印象があります。
さらに最後に、「寝よう」「自然を歩こう」といったこともおすすめされていました。これについても完全に同意で、僕の経験則だと、PCに向かってあれこれ考えて分からないときは、逆に散歩したり、スーパー銭湯で大きい風呂やサウナに入ったりすることで解決策が思いつく、ということが割とよくありました。
時間を捻出して集中的に使うことは大事だけど、適度な息抜きもしたほうがかえってうまくいく、ということですね。
余談ですが、この発表はもともと、僕が主催しているmaguro.devというイベントの第1回で発表される予定だったところ、当日sosukesuzukiさんが体調を崩してしまい登壇できなくなってしまったものでした。
そこからsosukesuzukiさんに会うたびに「お蔵入りせずにいつか発表してほしい」と言っていたので、この発表をYAPCという歴史と活気のある場で聞くことができて、とてもうれしかったです。さらに、この発表でsosukesuzukiさんはYAPC::Fukuoka 2025のベストスピーカー賞を受賞されており、勝手に誇らしげな気持ちになっていました（もちろん完全にsosukesuzukiさんの功績ですよ！）。
You Don't Need Hono
最後にHonoConf 2025のキーノートセッションとしてnakasyouさんから発表されたものをご紹介します。
まず、Honoのカンファレンスのキーノートなのに「あなたにはHonoは必要ない」というタイトルになっているのがおもしろいですが、内容もさらにおもしろいです。前半では、Honoが他のフレームワークに比べて「劣っている」点が軽快に列挙されていきました。
- スループットで見ると、結構な差でElysiaのほうが速い
- 型チェックのパフォーマンスもoRPCやtRPCにかなり負けている
- 書き心地の面で見ても、Elysiaのほうがリクエストハンドラの返り値をよしなに変換してくれたり、リクエストパラメータ・レスポンスボディのバリデーションのシンタックスもコンパクトだったりする
- フルスタックSSR、SPA、MPA/SSG、それぞれに最適化されたフレームワークが他に存在する
これらの理由で、「Honoを使う必要はないのでは？」と問いかけます。
しかしこれらの「弱み」は、実は強みでもあり、Honoを使うべき理由にもなるのだ、とnakasyouさんは言います。
HonoはRESTという「共通言語」に長けており、TypeScriptで快適な開発体験を得ながら、さまざまなクライアント（モバイル含む）から呼び出せるAPIを作ることができます。さらに、豊富なミドルウェアエコシステムにより、MCP、oRPC、tRPCなどの異なるプロトコルをサポートすることも容易です。
また、Honoの徹底したSimpleな設計思想によって、「最初はルーターだけ、あとからミドルウェアを付け足す」といったインクリメンタルな開発がしやすくなっており、小規模から大規模までを一貫した方針で対応できるという強みもあります。
トークの内容自体はもちろん、いったんHonoのことを下げてから上げる、という構成が、聴衆を惹きつけていました。Honoコントリビュータであり、周辺のエコシステムについても詳しいnakasyouさんだからこそできる、とてもおもしろい発表でした。
おわりに
今回は、秋のカンファレンスシーズンで聞いたJavaScriptに関する発表を3つご紹介しました。
sosukesuzukiさんの2つの発表からは、JavaScriptCoreという巨大なコードベースに向き合い、理解し、貢献していくための具体的な姿勢を学ぶことができました。特に「仮説を立て、検証し、メンタルモデルを修正していく」というアプローチは、未知の技術に取り組む際に普遍的に役立つ考え方だと思います。
nakasyouさんの発表は、Honoというフレームワークの強みと弱みを客観的に分析しつつ、「Simpleであること」の価値を再認識させてくれるものでした。
カンファレンスでの発表を通じて、登壇者の経験や知見を直接聞けること、そしてそれを基に交流することの価値を改めて感じた秋でした。
また次回、おすすめコンテンツを紹介していきます。お楽しみに！
maguroさんの「も読」過去記事
- 初心者と熟練者、同じ5行のコードを見た時の視界の違い（9月19日公開）
- イギリス就職奮闘記とJavaScript CLIツールスタック2025（8月25日公開）
- 生産性のパラドックス――AIで「速くなった気がする」のに実測値は19%悪化（7月29日公開）