ハクソク

世界を動かす技術を、日本語で。

過去10年の多様なJavaScriptランタイム

302日前原文(buttondown.com)

概要

  • JavaScriptランタイムの多様化と進化の背景解説
  • Edge Computingやマイクロコントローラ、ポリグロットエンジン等の用途別ランタイム紹介
  • スマートTVやモバイル、デスクトップ等、ネイティブアプリでのJavaScript活用事例
  • 各分野で求められる最適なエンジン・ランタイム選択の重要性
  • JavaScriptのエコシステム拡大と今後の発展可能性の示唆

JavaScriptランタイム多様化の潮流

  • 過去10年 でJavaScriptランタイム/エンジンが急増し、多様な用途・環境で利用拡大
  • Cloud、Edge、Smart TV、モバイル、マイクロコントローラ など、利用シーンの広がり
  • タスクやデバイス特性に最適化した 専用ランタイム の登場
  • 1つのランタイムやエンジンでは 全ての要件を満たせない 現実

Edge Computing分野

  • 2002年Akamai によるJava/.NETベースのエッジコンピューティングが先駆け
  • Node.js(2009) 登場によりJavaScriptのサーバサイド展開が本格化
  • AWS Lambda(2014)、 Lambda@Edge(2016-2017) でエッジでもJavaScript稼働
  • Cloudflare Workers(2017) がService Worker APIベースで新市場創出
  • Deno(2018)、 Deno Deploy、 Bun(2022)、 Wasmer/WinterJS(2023) 等、新興勢力続々登場
  • エンジンも V8、JavaScriptCore、SpiderMonkey、QuickJS など多様化
  • タスク・レイテンシ・リソース要件に応じ 最適なエンジン選択 が主流

マイクロコントローラ向けランタイム

  • マイクロコントローラ は極小メモリ・低消費電力・低コストが特徴
  • Node.js 等フル機能ランタイムは非現実的
  • Duktape、Espruino、mjs、JerryScript、Moddable、elk 等、超軽量エンジンが登場
    • 64kB未満のRAMで動作するものも
    • 性能とのトレードオフ有り
  • これらエンジンを基盤とした IoT.js、Microlattice.js、low.js 等のIoT向けランタイム
  • ベンチャー資本不要 で開発されるケースも多い

ポリグロットエンジンの進化

  • 他言語VMを活用し 言語間相互運用 を実現するエンジン
  • Rhino(1997) はJava実装、JVM上でJava⇔JavaScript相互呼び出し可能
  • Nashorn(2014)、Graal.js(2018) へと進化、Node.js SDK互換も実現
  • .NET向け jint(2013)、Python向け PyNarcissus、langjs、jispy、Ruby向け twostroke、Opal など多様
  • RustやGo、Zig等 新興言語向け実装 も増加
  • JavaScript自身でエンジンを実装する動き （Narcissus、Porffor等）も活発
  • 他言語からの呼び出し需要、エコシステムの広がりを象徴

ネイティブアプリ分野でのJavaScript活用

  • Web由来のGUI構築適性 により、クロスプラットフォームアプリ開発基盤として採用拡大

  • Web Viewベースアプリ としてモバイル/デスクトップ/スマートTVで普及

    • モバイル：
      • PhoneGap(2009) 登場、後にCordovaとしてオープンソース化、IonicやCapacitor等のUIツールキット
    • デスクトップ：
      • NW.js(旧node-webkit,2012-)、 Electron(2013-) が主流
      • Discord、Slack、Visual Studio Code 等、主要アプリがElectronベース
    • スマートTV：
      • OIPF、HbbTV、ATSC 3.0 等のWeb仕様
      • webOS、Tizen、Fire TV などでCordova採用
      • Roku は独自言語BrightScript、 Apple TV はTVMLKit JS（JavaScriptCoreベース）

  • 1.26億台超のネット接続TV、欧州だけで1億台超のHbbTVデバイスなど、巨大市場

JavaScriptランタイムのエコシステムと今後

  • 用途・環境ごとに最適なランタイム/エンジン を選択する潮流
  • エコシステムの拡大 と多様な実装・運用パターン
  • 今後も新たなランタイム・エンジンの登場 が予想される状況

Hackerたちの意見

この大作の記事を書くのに1年以上かかっちゃった。4,000語以上、200以上のリンク、そして無数のJavaScriptランタイムやエンジンに関するリサーチが詰まってる。ぜひ読んでみて！新しいことを学べること間違いなしだよ。

└

確かにたくさん学べたよ。ありがとう、サー、この大作に感謝:)

└

よく調べた深い記事を書くことにROIがまだあるのか、ずっと気になってた。もしその記事の洞察が本当にユニークなら、他のライターやAIに何度も再利用されちゃうし、もしかしたらもっと良いビジュアルや図を使った記事がクリックを集めることになるかも。

└

興味深い読書だった。リサーチも素晴らしいね。これからどうなると思う？

└

こんなに頑張ってくれてありがとう。こういう良い調査記事を書く人たちにはもっと評価されるべきだよね。私たちの業界の残念なところは、理論的には言語に中立なコンポーネントを、複数の言語エコシステムや縦の分野で別々に再現しちゃうことだと思う。npmとcargoが別々でなくて済めばいいのに。君が言及してるポリグロットランタイム（特にGraal）がもっと普及すればいいな。DuktapeとMicroPythonの両方があるのも残念。効率的なガベージコレクションやコンパクトなバイトコード、パッケージ依存解決に言語特有のものはないのに。

└

JS/TSの世界には比較的新しくて、両方のプラットフォームで動くモバイルアプリを作ってるんだ。それに、Denoを使ってバックエンドも構築中。この記事はすごく情報が豊富で役立ったよ。素晴らしい仕事だね、ありがとう！

└

JScript.NETみたいなものも考えた？jsc.exeはすべてのWindowsインストールに付いてくるし、JScriptはまだIISサーバーで動くよ（いくつか作ったことある）。それに、Adobe PhotoshopやAfter Effects、Premiere、Illustratorみたいなものは、古いバージョンのExtendscriptや現代のV8を使ってJavaScriptを動かせるけど、どう思う？ https://developer.adobe.com/xd/uxp/uxp/versions/ https://developer.adobe.com/photoshop/uxp/2022/ps_reference/

└

記事素晴らしいね。WasmerとWinterJSに言及してくれてありがとう。面白いことが進行中だね！

└

とても興味深い読み物だったよ。努力して共有してくれてありがとう。

└

ニュースレターにサインアップするのは初めてで、HNのコメントやあなたが書いたこと、時間がかかったことを読む前にやっちゃった。こういう深い考察は本当にありがたいけど、正直言うと、私もあなたと同じようにエッジやJSエンジンのことに夢中だったから、いくつかは知ってた。でも、ブログを通してたくさん学べたし、すごく楽しかったよ。これからも時間をかけて、休んで、素晴らしい作品を作ってね。楽しみに待ってるから！良い一日を。

└

信じられない記事だね。こんなに多くのJavaScriptランタイムがあるなんて知らなかったし、マイコン上でJavaScriptを実行できるなんて思ってもみなかったよ。

LLRTは主にコミュニティからの貢献で、AWSの一人（リチャードさん、こんにちは！）が関わってるってことを訂正したい。LLRTモジュールを使ってる企業はたくさんあるし（モジュール化にはかなり力を入れた）、rquickjsもね。私は両方のメンテナーで、自分でもいくつかモジュールを書いたよ。Rustにとってこれ以上のJSランタイムはないと思う。quickjs-ng（quickjsのフォークで、最初はquickjsの活動が停滞してたからだけど、今は両方のプロジェクトがアクティブで分岐してる）に基づいていて、主要なNode/WinterJSのAPIもたくさん含まれてる。

└

なるほど、洞察をありがとう。どう言い換えようか考えてるところ。AWSは少なくともこれを作ったり、資金提供したりしたのかな？rquickjsは記事に入れる価値がありそうだね。ポリグロットエンジンのセクションに編集したところなんだけど、今のところエンジンとランタイムが混ざってると思う。

この文章はウィキペディアのページの基礎になるべきだと思う。すごくよく書かれていて、参考文献も豊富だし。著者におめでとうと言いたい。

└

ありがとう！本当に感謝してるよ！エンジンに関する立派な記事はあるけど（https://en.wikipedia.org/wiki/List_of_JavaScript_engines）、ランタイムについては確かに記事がないね。エンジンに比べてあまり話題にされてない気がするし、分析もブラウザやNode系に集中してるから、文献に何か足したいなと思ったんだ。

QuickJSについていくつか言及があるけど、みんなベルラールのQuickJSのフォークを指してるね。これも言及する価値があると思う。まだアクティブみたいだし（最後のリリースは2025-04-26、GitHubのミラーもアクティビティがあるみたい）。

└

quickjs-ng（https://github.com/quickjs-ng/quickjs）が公式フォークとして認められたと思ってたんだけど、Bellardがいくつか貢献もしてるし、もしかしたら間違ってるかも。最新の情報（https://github.com/quickjs-ng/quickjs/discussions/258#discus...）で二つのフォークについて明確にされてるよ。

└

QuickJSについてだけど、埋め込みLuaと比べてどうなの？パフォーマンス、メモリオーバーヘッド、C API、起動時間は？

戦略の重なりがある中でも、これらのランタイムを支えるエンジンの多様性が際立ってるよね。DenoがNode.jsの伝統を引き継いでV8を使ってる一方で、BunはJavaScriptCore、WinterJSはSpiderMonkey、LLRTはQuickJS、Cloudflare Workersは特注のworkerdを使ってる。もはやバックエンドはNode.jsとV8だけの舞台じゃなくなって、タスクに最適化されたランタイムやエンジンを選ぶのが流行ってる。これが完全に正しいとは思わないけど。Cloudflareのworkerdは特注のランタイム（deno/node/bunなどと同等のレベル）だけど、V8エンジンを使ってるよ。

└

それは正しい。V8を使ってる。

└

私のミスだ、訂正してくれてありがとう！今後の読者が間違った情報を持ち帰らないように、記事を更新したよ。

このリストに入ってないいくつかのJavaScriptランタイムに関わって楽しかったよ。特にPythonMonkeyが面白い。これはSpiderMonkeyをPythonに埋め込んで、Pythonのイベントループを使って非同期処理をするんだ。もう一つ興味深いのはDCPで、これは他のJavaScriptランタイムの上で動く擬似的なJSランタイム（私たちが作ったカスタムのサンドボックスサーバーサイドランタイムも含む）で、JSやWASMベースのワークロードに対してクラウド関数のような計算を提供するんだ。この記事とは関係ないけど、PyodideはJS/WASMの中のPythonランタイムで、DCPにPyodideを組み込んで、ブラウザでPythonのワークロードを実行できるようにしたんだ。クレイジーなことだよ…。

└

ポリグロットランタイムについての私の分析は浅かったし、期待を裏切るかもしれないと思ってた、ごめん！追加してくれてありがとう！WASMランタイムについてのセクションを始めたから、Pyodideは興味深かったけど、WASMに入ると範囲が広がりすぎると思ったから控えたんだ。

欠けてた^1: マイクロソフトのJScript（1996年頃）。Internet Explorerに入ってただけじゃなくて、サーバーサイド（ASP）やスクリプティング（WSH）でも使えたんだ。それからJScript.NET（2000年頃）もあったし…。1. 最後の10年ではなく、同時期のものがいくつか言及されてる。

└

最後の10年に絞ったのは、1996年頃の情報を掘り起こすのが難しいと思ったからなんだ。その時期は、その時にアクティブな開発者だった人たちに任せた方がいいかなって。でも、Chakraについては何回か言及したよ！

└

JscriptはすべてのJS実装の中で最も悪質だった。人々がJSについて嫌っているほとんどのことが、今でも言語に残っている理由なんだ。彼らは言語から悪いデザインの部分を取り除きたかったけど、MicrosoftはJscriptをすべての問題を抱えたまま実装し終えたばかりだった。実装を変更するよりも問題のある言語を持つ方が良いと考えたから、世界はその問題に縛られてしまったし、今ではウェブ上に変更するのが難しいコードがたくさんある。

GraalVM/GraalJSにはすごく感心してるよ。ほんと「そのまま動く」し、Javaのウェブアプリに簡単に統合できた。主にJavaの中でJSを使って、handlebars.jsを動かしたり、サーバーとクライアントの両方で使うJSコードライブラリをテストしてる。

└

GraalJSについては、すごく高い評価を聞いたよ。モバイルアプリの中で意味があるかどうか気になるな。特に特定の機能を考えてるわけじゃなくて、単に興味からなんだけど、そこが自分がJavaScriptを使ってるエリアだから。Javaとのファーストクラスの相互運用性はAndroidには素晴らしいけど、iOS（C系言語）との相互運用性がどれくらい安いのかは気になるね。

この記事はブームについての良い洞察を提供してるけど、避けられないバストについては触れてないね。JS自体ではなく、異なるランタイムについてだけど。DenoとBunは、どちらもVCから支援を受けていて、互いに競争してるみたいだけど、パワー法則が支配する世界では複数の勝者が出るのは難しそう。じゃあ、他の人たちはこのエコシステムが次の10年をどう生き延びると思ってるのかな？カナリアは何だろう？それに、私たちのコードはどれくらい相互運用可能になるんだろう？

└

WinterCGは、これらの懸念に対処するためにウェブAPIの標準化を手助けしようとしてるんだ。サーバーサイドのJSを書くときの一つの戦略は、できるだけ標準APIに従うことだよ。もしランタイム特有のコードを使いたいなら、そのコードを別のモジュールに隔離すれば、特定のランタイムから移行する必要が出たときに、そのコードを特定して置き換えるのが簡単になる。結局、すべてJavaScriptだから、これらのランタイムのほとんどがオープンソースだし、たとえ放置されてもコミュニティのフォークが見られるかもしれない。ただ、選んだランタイムが完全にサポートなしでも、ほとんどのプロジェクトにとって移行が非常に緊急または難しいタスクになるとは思わないな。

└

いい考えだね！DenoやBunは確かに資金がすごいけど、Node.jsもまだまだ革新してるよ。type-strippingやrequire(esm)なんかが思い浮かぶね。大手企業がElectronに使ってる限り、Node.jsへの投資は続くと思う。たとえ投資が減ったとしても、経験上、古いツールはなかなか消えないからね。相互運用性が上がることを願ってるよ。React NativeコミュニティはNode-APIのサポートに近づいてるし、それが実現すればデスクトップとモバイル間でネイティブコードを共有できるかも。WinterCGの取り組みも順調だしね。カナリアについては、持続可能性が重要だと思う。このツールの表面積はどれくらいか、維持するのにどれだけの専門知識と努力が必要か、そして誰がその存続に投資しているのか。IntlやTemporalのような共通の実装を共有できれば、小さなプレイヤーも追いつきやすくなるし、大手が分岐しようとすればするほど（Chromeを見てるよ）、難しくなるよね。

JSの仕様とテストスイートには特別なものがあるよね。そんなに多くの異なるランタイムで同じコードを問題なく書いたり実行したりできる言語はほとんどないよ。