ディスカッション・質疑応答
各Runtimeが向いているユースケースは？
佐藤（ahomu）氏：話のなかではNode.jsが成熟しているというフレーズが来るんだなと思いました。それはいつか来るのでしょうか（笑）？
古川氏：はじめた頃は、APIが壊れているイメージでしたが、今はV22くらいなので、確かにそう思います。
Runtimeが向いているユースケースとはいえ、どれもサーバサイドのアプリだとは思います。私は基本Next.jsを使っていてNode.jsがしていること自体はシンプルなので、「Runtimeはコレ」と言う感じになっています。サーバサイドのユースケースやフロントエンドのツールとして使うことがあると思うので、そこを基本として考えていただいて、プラスDenoやBunを使いたいときにはどうなるのかという話になると思います。
Denoに関しては、公式のオーガニゼーションでFreshやdeployもしてくれているのでそこはマルチページアプリケーションのフレームワークのFreshでもDenoにおんぶにだっこで色々やってもらいたいと思ったときには、ありだと思います。
JSRでnpmに愛想をつかしている、疲れている人がもう一度新しいことに挑戦する意味でもDenoはありだと思っています。
Bunは先ほども申し上げた通り独自路線なのです。ただ、Bunはパフォーマンスが早いので私は一時的なものにだけに使う利用法を一番しています。
Node.jsの互換があるらしく、npmインストールよりも10倍くらい早いと書いてあるので、そんなに早いのなら使ってみようかなと思いBunインストールだけに使ってみたりもしています。
もっとたくさん使っている人に聞いてみてもいいかもしれませんね。動くは動くと思うので、人によってBunとうまく向き合っていけると思います。ただ、自分自身がNode.jsを使うことが多いのでなんともです。
佐藤（ahomu）氏：今コメントでBunはパッケージマネージャーで使っている人が多いと来ていましたが、古川さん的には実感としてどうでしょうか？
古川氏：多いでしょうか？
yam、npm、pnpm、Bunという順番であると思います。Node.jsのサーベイを見たときにいちばん使われているパッケージマネーはnpmで、6～7割と圧倒的に多いんです。次の2割くらいがpnpmらしいです。yamの採用率はぐっと減り1％から5％くらいになり、それよりも下がBunです。
ただ、早いというニーズもあるので、そこは確かにと思っています。
佐藤（ahomu）氏：Bun自体はパッケージマネージャーが主ではないので、絶対数は他のパッケージマネージャーと比べたら劣りますが、Bunを使うときのエントリーポイントとしてパッケージマネージャーとしての用途も優しいラインとして存在している感じでしょうか。
古川氏：使ってみるだけ使ってみようとしたときにBunをnpmで入れることはできますね。
佐藤（ahomu）氏：ありがとうございます。
Node.jsの存在があった上で、今の各Runtimeは競合関係になりますか？それとも共存となりますか？
古川氏：明確に競合視していると思います。Node.jsに関しては分かりませんが、DenoはNode.js、Bunを競合視していると思います。
いい意味でエコシステム的に駆逐しようと思っているほどの話ではなく、お互いがライバル関係として高め合うという意味で競合している部分はあると思います。
Bunがパフォーマンスを早くするとなれば、Denoもパフォーマンスを改善しようとしていますし、DenoやBunが出てきたおかげでNode.jsにstrip-typesが入ったことも考えられないことでした。いい意味でライバル関係として競合しながらしのぎを削っていると思います。
ただ、Denoの野心が高く、Node.js、Deno、Bunでは今はNode.jsのシェア率が高いですが、いつかDenoがどこかで逆転してやるぜと思っていると思います。
佐藤（ahomu）氏：商業的なラインに乗るかどうかは別にして、開発者の心意気のロックな部分が見えますね。
古川氏：すごくいいと思います。
佐藤（ahomu）氏：では次です。
各Runtimeに互換性のあるライブラリを作る(orカスタマイズする)ことは可能ですか？
佐藤（ahomu）氏：途中でWinter CGのお話もありまして、基礎的なAPIセットを共有することによって互換性をということでしたが、現実的にそのようなライブラリを作ることがどのくらい可能なのかのコメントをお願いします。
古川氏：チャットに書かれてしまいましたが、Winter CGがあり、共通互換のあるAPIだけを使ってフレームワークを作ろうとするとHonoだと思います。
Honoに関しては共通互換のあるAPIのみでどのプラットフォームでも動くように作られています。多少方言の差はあると思いますが、その差も吸収してくれるようになっていると思うので、可能にはなってきていると思います。
細かいことをやろうとすると、まだ保てていない部分はたくさんあると思います。「細かいところで何を？」と言われると困りますが、最小限セットはあってもプロセスを立ち上げて何かをするなど、本当に細かいニーズに全て対応しようとすると徐々に独自のAPIを書く必要が出てくると思います。
そこまでいくと、Winter CG側の最小限APIの中に入っていないと思います。
そういうことが発生した場合はいったん互換性をあきらめるしかないかもしれません。
互換性を保って書くしばりをするならば、Honoを使って書けば可能だと思います。
佐藤（ahomu）氏：コメントでも 表現の差はアダプターでと言う話もありますね。
実際に凝った機能やWinter CGでサポートしていない領域の機能を各Runtimeで実現しようとすると、アダプター的な層がおそらく実装の層として分厚くなっていきそうですね。
今話題のEdge Runtimeとはなんですか？
佐藤（ahomu）氏：BarthelのEdge Runtimeの話よりは、JavaScriptのRuntimeとは何ですかと聞いているのかと思います。
古川氏：いわゆるEdge Runtimeと言われると、CDN上で動くためのJavaScriptのRuntime環境を指していると思います。
Cloudflareが主に実装しているworkerdなどもそうです。
実際はNode.jsで機能を一部縮退したものだと思いますが、Barthel のEdge Runtimeもそういうもので作られていると思います。
CDNは少しサーバとしては特殊です。普通は仮想化した上でCPUやメモリ、ファイルへのアクセスを自由にできますが、CDNでやるときは制約が強いです。そもそも一つのプロセスでCPUをそこまで占有してはいけません。CDNの基本はコンピューティングリソースとしてはそこまで大きくはありませんが、それを横にたくさん並べることで早く動く考え方になっています。CPUの占有時間やJavaScriptのファイルサイズの大きさなどは細かく決まっているはずなので、CDN上で動かすための軽量なRuntimeを作っている人が多くいるということです。
先ほどのCloudflare の例で言えば、workerdはそれを使って動かそうとしています。そのworkerdもWinter CGの中に入っているので、Winter CGの共通セットの中で書いておけばEdge Runtimeにも持っていける感じです。
自分のサーバ上で動かしているものをどこかのタイミングで、CDN上で動かして、そちらの方のパフォーマンスが早かったりコストが安かったりするメリットがあるならば、そちらに動かすことがEdge Runtimeとして盛んになっていると思います。
佐藤（ahomu）氏：実際Edge上で動く制約条件……今上げていただいた実行時間やファイルサイズなどいろいろある印象がありますが、近年Edgeっぽいソリューションの中でNext.jsが動くなど大きいライブラリを動かしている話をちらほら聞いたような気がします。
この辺の変化はありますか？
古川氏：どうでしょう。@yusukebeさんがCloudflareの方なので聞いてみてもいいかもしれません。
チャット欄の人に聞くのも変な話ですね。
Cloudflare Workersでも大きなNext.jsは動くんですね。
ファイルのサイズの制限なども徐々に大きくなっているのでしょうね。扱える割合も広げていると思います。ある程度までは動くと思いますが、ファイルのサイズは決まっていると思います。ファイルのサイズを削るのは皆さん好きなので、流れの中でやってくれるかもしれませんね。
佐藤（ahomu）氏：そこら辺はEdge Runtime上での何かしらの技術的なブレイクスルーの話になってくるのかもしれませんね。JS Runtimeに話を戻したときに、Edge系のJS Runtimeの特長や内部構造の共通項や、Node.js、Deno、Bunとの違いはありますか？
古川氏：先ほどふれたものが一番強い違いです。扱えるリソースが全然違ってNode.js、Deno、Bunはクライアントアプリケーション上で動かします。昔Electronなど流行ったと思いますが、基本的にそういうものとして使うことができるように考えられています。
サーバサイドだけ動かすことを目指しているわけではなく、クライアントのアプリケーションとして動かすことがノーマルなJS Runtimeでは可能です。
ただ、CDN上のEdge Runtimeはそうではなく、リソースの制限を設けて、扱えるリソースを小さくして軽量にする目的があると思います。GCをどのように動かすのかも違うと思います。
Node.jsもそうですが、GCは動くと一回止まってしまうので、CPUの制限も考えると基本動かさないようにするなどしていく必要があると思います。
佐藤（ahomu）氏：ありがとうございます。
JavaScriptだけ、Runtimeが乱立しているイメージですがどういった背景はありますか？
佐藤（ahomu）氏：まず、乱立しているの？と言う話もあると思いますが。
古川氏：確かに多いとは思います。先ほど申し上げた通り、言語の仕様と言語のエンジンが独立してくれているので、そこをつないで自分の好きなRuntimeを作ることはそこまで難しくないところが良かったところだと思っています。
Runtimeを自分で作る人たちも中にはいますが、Runtimeも作り、言語エンジンも全部作るような人はすごすぎると思います。
たまにそのような酔狂な人はいますが、基本Runtimeと言語を理解するエンジンの部分は分割できています。エンジンはライブラリとしてRuntimeが使っているので、一番難しいJSはそこに任せることができます。
Runtimeをどう表現していくかは、Node.jsである程度切り開かれています。このようなものを作れば、みんなが使ってくれるという道筋はできてきていると思います。
乱立しているイメージと言われるとどうでしょう？
Denoが出てきた後即座にBunが出てきたので、1～2年の間に新しいものが次々に出てきたイメージとなり、乱立していると言われるのかもしれませんね。
Pythonも言語使用とRuntimeは分かれています。Python でPython を書いた「pypy」もあるのでJSでJSを書いたものが出てきても不思議ではないですし、また出てきたら面白くなるのかもしれませんね。
いずれにせよ、乱立しているのかはともかくとして、背景はあると思います。
機能性を充実させれば難しくないです。
佐藤（ahomu）氏：ありがとうございます。
各Runtimeの開発体制などを知りたいです。
佐藤（ahomu）氏：先ほどのお話いただいた中にほぼ含まれてはいましたので、追加があればお願いします。
古川氏：先ほど私が知らなかった情報をチャットで知りました。
Bunのマネタイズとして「Bun deploy」がそろそろ出来そうだそうです。Discordなどで盛んに議論されているのですが、Discordまで入って追うとなるとだいぶ追わないといけないのであまり追えていません。
生の体制のところは深く追うことができると思います。私は表面的に見えるGitHubの部分や対外的にリリースのあるブログで調べています。
開発体制をもっと深く知りたければそちらを追ってみるといいかもしれません。
公式の情報では今回まとめたことがだいたい全てです。
佐藤（ahomu）氏：Node.jsこそ違いますが、DenoもBunもBarthelなどOSSを続けるため、ビジネス的な収益が別口で得られる体制込みで座組を作ることが開発体制として広まってきているのでしょうか？
古川氏：Node.jsも、J.S.Foundationから寄付金をもらったりもしていますが、一人のエンジニアを雇えるほどの充実したお金をもらえるかとなると、なかなか寄付金だけでは難しいですよね。
佐藤（ahomu）氏：ありがとうございます。
それでは事前に用意したテーマが終わりましたので、この後は質疑応答となります。
Q：Common JS周りも毎回よく分からなくないのですが、Runtimeとのかかわりで、どういう立ち位置だと理解すればいいのでしょうか？
古川氏：Common JSもRuntimeが提供しているAPIです。JSの仕様側でESモジュールのようなインポートエクスポートの周りのシンタックスが決まった2015年以前からあるものに関して、モジュールを取ってくる仕組みはRuntime側で提供されています。
今回エンジン側で提供されるようになったので、それとのかかわりをどうするかと言う話で、ESMとCGSは相互運用を求められる形になりました。
立ち位置的にはRuntimeのAPIです。だからこそ先がなさそうなのでESMにしたい人が多いのではないでしょうか？
Q：Node.jsのコミッター目線でNode.jsに足りない（他のRuntimeにはあって）と思う要素は何かありますか？
古川氏：機能面で足りないと思うことは無くなってきています。それよりは相互運用のような運用性を高めていってほしいです。
いろいろ機能追加されるタイミングで「これはいるかな？」と思うこともありますが、Bunのようなクレイジーなアイデアではないです。
人に依存するかもしれませんが、Bunはやりたいと思わないようなことをやってくるので、すごいと思います。
佐藤（ahomu）氏：DenoのセキュリティモデルをNode.jsの利用者のような観点でほしいと思うことはありますか？
古川氏：欲しいと思う瞬間はあまりありません。サプライチェーンアタックの問題で急にネットワークアタックを食らったらどうなるのかという問題はホットな話ではありますが、運用がかなり難しいと思います。
実行する人はネットワークやファイルにアクセスすることを分かっているので、ネットワークやファイルへのアクセスは許可してしまうと思います。運用上それが許可されていなかったために、障害へ発展することを嫌がる人のほうが多いと思っています。
そもそもOSというセキュリティ機構があり、OSがどのようなパーミッション管理をするか、きちんと決まっているのにさらにプログラミング言語やアプリケーションのレイヤーでさらにもう一つ細かいセキュリティを入れる、そこまでやる必要があるのかと思ったりします。
インフラ側で制御できるのではと思ってしまいます。
でもサプライチェーンアタックの話だと、サーバだけではなく、クライアントで実行している開発環境も対象なのでそのときに制御しないと言われたらその通りです。
なので難しいです。いい感じにしておいてほしいといつも思います。
Q：RustはOSネイティブなバイナリで動くという意味では「Runtimeは無い」というのは間違ってないですよね
古川氏：OSネイティブなOSを仮想化している層が無いということです。OSを仮想化するRuntimeがあるので、それが無いという意味では間違ってはいないです。
別にそれをRuntimeと呼ぶかどうかがどうかと言う話にはなりますが、間違ってはいないです。
Q：互換性が気になる。皆、Node.jsが基準なんだろうか？
古川氏：Node.jsが基準というか、npmの資産が欲しいのだと思います。
Node.jsのAPIが使えると言ってもみんな「npm〇〇」が使えないという話になると思うんです。そこが問題なのだと思っています。
なので皆、Node.jsを基準に考えているのだと思います。それでいいのかという思いはあります。
Node.jsを基準にすると、Node.jsの牙城を崩すのが難しくなってしまいますよね。
新しいAPIを追加するのもNode.jsが基準になりますし、私はDenoが今をぶっ壊して新しい世界を作ってくれるのかなと期待していました。
佐藤（ahomu）氏：ぶっ壊して願望がチラ見えしていますね笑。
古川氏：ぶっ壊してほしいという願望はあまりないですね笑。ただ、ぶっ壊して「あーDenoをもっとやっておけばよかった」と思わせてほしいなと少し思っただけです。
自分が選択しているNode.jsが安牌という基準や概念を覆せるんだったらということです。
Q：Bunが他のJavaScriptRuntimeと比較して高速である理由は何でしょうか？具体的な技術的工夫などあるのでしょうか？
古川氏：いろいろなものをネイティブで書き直したりしています。ストリームの内容をネイティブで書き直したりしています。パフォーマンスが大正義なので少しでもパフォーマンスが遅れると、すぐに改善する体制になっています。他はセキュリティを考えるとそこまでドラスティックなことはできませんが、ドラスティックなことをできる余地がたくさんあるBunが一歩、二歩リードしている感があります。
ジェラードさんの圧倒的な能力の差です。技術的な工夫はあまりないと思います。
JSのエンジンは違うところもありますが、そこだけでそこまで変わらないと思います。
どちらかと言えばネイティブAPIを結構やっているからだと思います。
Q：Bunの尖り方にすさまじく興味がでました。今後の開発のロードマップなど分かっていることがあれば教えてください
古川氏：Bunロードマップが出ていて、その中に今後やることの一覧が出ています。しかもそれに結構チェックが付いています。
今、私が言ったことがほとんどだと思います。
パフォーマンス改善、Web APIへの追従、Node.js APIとの互換性改善がメインで書いてありました。
ただ、Windowsでうまく動かなかったものを動くようにしたのは2022年～2024年への大きなアップデートでしていたので、開発環境の多様化に対応していきたいんだと思っています。
Bunのロードマップで検索すると出てくると思います。
Q：あるライブラリがNode.jsだけしか動かかないかどうかは、他環境で動かさない限り分からないものでしょうか？
古川氏：分からないです。細かいところの互換性がないので、このAPIが使えると言っても第三引数に渡したときだけ変に動くこともあるんです。その辺の微妙なところが残っていると思うので、究極を言えば動かさない限りは分からないと思います。
佐藤（ahomu）氏：以上で質疑応答が終了となりました。古川さんありがとうございました！
