VercelのScriptcは、NodeやV8を使わずにTypeScriptをネイティブバイナリにコンパイルする

Why it matters

Scriptc gives TypeScript developers a credible path toward tiny native CLIs and services, while exposing exactly where JavaScript's dynamic behavior still requires a runtime.

Vercel, founded and led by Guillermo Rauch, は Scriptc を公表した。これは通常の TypeScript をネイティブ実行ファイルに変換するオープンソースのコンパイラで、既定の静的経路で生成されるバイナリに Node.js、V8、あるいは他の JavaScript エンジンをバンドルしない。Apache-2.0 ライセンスのこのプロジェクトは 7 月 27 日にバージョン 0.0.17 に到達しており、過去 4 日間の開発バーストで切られた複数のリリースのうちの一つだ。 (github.com)

リリース履歴には Chris Tate が活発な Scriptc コミッターとして現れているが、提供されたソースは彼がプロジェクトを創設した、あるいは正式に指揮していることを示すものではない。Tate のコミットは最近の Scriptc 活動全体に見られ、ネイティブの外部関数呼び出し、Windows クロスコンパイル、Node 互換性テスト、静的にコンパイルできない npm パッケージを扱うルールに関する作業が含まれている。 (github.com)

Scriptc は、Vercel が現在の名前になる以前から Rauch が追求してきた賭けを拡張するものだ。彼は MongoDB 向けのオブジェクトモデリングライブラリ Mongoose を作成し、普通の開発者にかつて大手テック企業だけが持っていたインフラを提供することを中心に Vercel を構築した。Vercel は当初 ZEIT としてデプロイの簡素化に注力し、その後フレームワーク、ビルドシステム、AI ツール群、マネージドコンピュートへと拡大した。Scriptc はその命題をデプロイの下流、つまり実行ファイルそのものへと押し下げる：TypeScript 開発者は言語を維持しつつ、従来それに伴ってきたランタイムの大部分を削ぎ落とせるべきだ、ということだ。 (vercel.com)

動的振る舞いを明示化するコンパイラ

Scriptc の中心的な設計選択は 3 層の実行モデルだ。サポートされる TypeScript はネイティブコードにコンパイルされる。npm パッケージから配布される JavaScript に依存するコードや any 型の値に依存するコードは、開発者が明示的に --dynamic を有効にした場合に埋め込みの QuickJS エンジンを経由して実行できる。サポートされない構成は番号付きの診断でコンパイルに失敗し、多くの場合は書き換えの提案が示される。 (scriptc.dev)

その但し書きは重要だ。Scriptc が「JavaScript エンジンを含まないバイナリを生成する」とする見出しの主張は、その静的層に適用される。--dynamic を使ったビルドはエンジンを埋め込むことになり、Scriptc の資料は動的モードのバイナリを約 3 MB としており、静的のより小さな範囲とは区別している。コンパイラには、どのステートメントが静的にコンパイルされるか、どれが動的実行を要するか、どれがビルドを遮るかを報告する coverage コマンドが含まれている。

この「静的でなければ拒否する」姿勢は、従来の JavaScript パッケージングツールよりもはっきりした境界を Scriptc に与えている。 Bun のスタンドアロン実行可能ファイル機能 はインポートされたファイルとパッケージとともに Bun ランタイムをバンドルする。 Deno compile はアプリケーションを denort に埋め込み、不要な機能を削った Deno ランタイムを用いる。 Node の single executable applications は準備されたアプリケーションのブロブを Node バイナリに注入する。これらのシステムはランタイムを持ち運ぶことで互換性を優先している。Scriptc は、サポートされる各構成がネイティブコードになり得ることを証明し、それ以外は開発者が QuickJS を選択しない限り拒否することを試みている。 (docs.deno.com)

Porffor は技術的な比較としてより近い。これも JavaScript と TypeScript を事前コンパイルして WebAssembly またはネイティブバイナリに変換し、フルランタイムをパッケージングしない。Scriptc は、通常の TypeScript、公式の TypeScript チェッカー、およびファイルアクセス、ネットワーキング、HTTP、TLS、子プロセス、バッファを含む選択された Node API 周りで明確な互換性の約束をしている。プロジェクトはその表面をコマンドラインプログラムや小規模サービスに適したものとして提示している。 (porffor.dev)

ベンチマークは依然として Scriptc 側の主張である

Scriptc は 800 を超える差分テストを実行していると述べており、各コーパスプログラムを Node 上とネイティブバイナリとして実行して標準出力、エラー、終了コードを比較する。リポジトリはまたメモリエラーやリークを検出することを意図した AddressSanitizer テストレーンについても説明している。これらの安全策はデモベンチマークよりも強固だが、依然として Scriptc のメンテナが設計し報告しているテストである。 (github.com)

性能値は注意して読まれるべきだ。Scriptc の資料は静的バイナリを約 170 KB〜200 KB、起動時間を約 2〜4 ミリ秒、典型的なメモリ使用量を 1 MB〜4 MB、動的モードのバイナリを約 3 MB と説明している。これらはメンテナ側の数値であり、提示されたページからは独立したベンチマークとして扱うのに十分な手法は示されていない。 (github.com)

Scriptc のタイミングは、TypeScript 市場内でのネイティブツールへの広範な動きと合致する。Microsoft は 7 月 8 日に TypeScript 7.0 をネイティブの Go ポートとしてリリースし、フルビルドで 8x〜12x の高速化を報告した。Microsoft の取り組みはコンパイラと言語サービスの高速化を促進しつつ、JavaScript を TypeScript の通常の出力として残している。Scriptc は次の一歩を踏み出し、アプリケーションそのものをネイティブにしようとしている。 (devblogs.microsoft.com)

Vercel はさらに下位スタックへと進出する

Vercel は即時の商用モデルを強制することなくその実験に資金を投じることができる。2025 年 9 月、Vercel はポストマネー評価 93 億ドルで 3 億ドルの Series F を調達し、Accel と GIC が共同でリードした。Scriptc は Apache-2.0 ライセンスの Vercel Labs リポジトリとして公開されている。 (vercel.com)

この方向性は、フロントエンドのデプロイからソフトウェアの作成と実行を取り巻くインフラへと拡大してきた Vercel の拡張とも一致している。Scriptc はスタックの反対側からアプローチし、Vercel の製品や顧客基盤で既に一般的な言語から、小さくポータブルな実行ファイルを生成する手段を開発者に提供している。

プロジェクトにとって最も困難な任務は、引いた境界を維持することだろう。JavaScript は動的な振る舞い、npm 互換性、ランタイムのリフレクションから多くの有用性を得ている。サポートされない機能の一つ一つが、Scriptc のネイティブ化を拡張する圧力を生むか、より多くのコードを QuickJS 経由で実行させる圧力を生み、小さなバイナリという主張を弱めることになる。コンパイラの拒否コードとカバレッジレポートはそのトレードオフを可視化する。開発者がこれらの制約を受け入れるかどうかが、Scriptc が TypeScript の CLI やサービス向けの実用的なツールになるか、それともどれだけの JavaScript をコンパイルして排除できるかという野心的なデモンストレーションに留まるかを決定するだろう。