Vercel launches scriptc, a compiler that turns TypeScript into native binaries without a JS engine

Vercel Labs released scriptc, an experimental compiler under the Apache 2.0 license that takes plain TypeScript and generates small native executables, with no Node.js, no V8, and no JavaScript engine embedded in the final binary. The repository was created on July 22, 2026, and has already gathered about 4,900 stars on GitHub, according to InfoQ.

How it works: three destinations for each line of code

scriptc reuses TypeScript's official compiler to handle parsing and type checking, then reduces the program to a typed intermediate representation (IR) that can become readable C code, LLVM IR, assembly, object files, native executables, or WebAssembly via WASI Preview 1.

Each piece of code falls into one of three paths: it is statically compiled by default; it runs dynamically inside an embedded quickjs-ng engine (about 620KB) when the --dynamic flag is used, which is mandatory for npm packages and any code that isn't fully typed; or it is rejected at compile time, with an SC error code and a rewrite suggestion. In practice, this means projects that depend heavily on npm libraries or dynamic types (any) end up pushed into QuickJS, which is exactly the engine scriptc tries to avoid.

The project requires Node.js 24 or higher for installation (npm install -g scriptc), and the limitations page documents deliberate divergences from Node: strings are stored in UTF-8, memory is managed through reference counting instead of a garbage collector, Object.keys respects declaration order, and process.argv[0] returns "scriptc" instead of the Node executable path. There is also an experimental flag, --npm-static, that tries to compile named packages out of this dynamic "island."

The numbers: fast startup, but not all upside

A benchmark cited by InfoQ compared scriptc 0.0.16 with Bun 1.3.12 and Node 24.18.0. Median CLI startup time came in at 1.78ms for scriptc, versus 21.29ms for Bun and 61.78ms for Node. Idle memory for a framework-less node:http server compiled with scriptc was 1.9MiB.

The problem shows up once a real library enters the picture: running the Hono framework, which requires --dynamic, sent 62% of the server into QuickJS, dropping throughput to 18,400 requests per second, versus 70,500 for Bun in the same test.

On Hacker News, a developer reported a similar scenario running a byte-array benchmark: scriptc was about 7.5 times slower than Node 24, even after AI-assisted optimization attempts. On the other hand, the executable started 12 times faster (1.5ms versus 18.6ms), used 72 times less memory (2.5MiB versus 181MiB), and shipped as a single 370KB file with no runtime dependencies, according to the comment reproduced by InfoQ.

The community didn't hold back on criticism

Filip Pizlo, known for his work on Apple's JavaScriptCore engine, argued that using float for all numbers and deferring integer inference "skips half the problem of making JS fast," and that relying on QuickJS is a poor choice for a performance-focused project, since the any type is common enough that real programs keep falling into that dynamic island.

Simon Willison, on the other hand, highlighted a more positive angle: coding agents contributed 918,000 lines of code to the project in a single week, and he considers building small, fast binaries without writing C or Rust "a valuable capability."

A third developer tested the compiler against real local projects and didn't hide his frustration: coverage produced hundreds of errors in each of them. In his assessment, reproduced by InfoQ, you can write a project from scratch without third-party libraries and compile it to a binary, "but then why not use Rust, Go, Zig, D, C, V, Ada, C++, Nim, Swift, Kotlin Native, Haskell... literally anything designed to be compiled, and compiled well?"

The risk of becoming just another abandoned project

A recurring concern in the comments is scriptc's longevity. The inevitable comparison is with zerolang, another Vercel project that stopped receiving commits just a few weeks after launch, according to reports cited by InfoQ.

Remo Jansen attempted a more ambitious stress test: compiling the TypeScript 6 compiler itself with scriptc. The attempt failed with an internal compiler error. Before it crashed, he measured a cold start of 3.6ms against Node's 48.9ms, but computation time came in at 2.33 seconds, much slower than the traditional runtime.

scriptc currently compiles for macOS, Linux, Windows, and WASI Preview 1, and is validated through differential tests that compare stdout, stderr, and exit codes byte-for-byte against Node. The project itself explicitly describes itself as experimental, and the documentation is at scriptc.dev.

What this means for developers in Brazil

For those working with edge computing and serverless functions, cold start is money and latency: providers charge for execution time, and users on slower connections feel every millisecond of startup. A binary that boots in 1.78ms instead of 61.78ms is an attractive proposition for edge functions running outside major data centers, a common scenario in Brazilian regions poorly served by CDN PoPs.

But the benchmarks' own caveat is the central point: as soon as a project depends on an npm package, much of the performance gain disappears inside the embedded QuickJS. That limits scriptc, for now, to fairly specific niches: internal CLIs, automation scripts, and command-line tools built from scratch without heavy dependencies, where shipping a single executable of a few hundred kilobytes is more practical than asking the team to install Node.js. For APIs and services using frameworks like Hono, Express, or anything with third-party dependencies, the startup gain comes with a throughput drop that may not be worth it.

Given zerolang's history, caution is also warranted before putting scriptc into production: it's a two-month-old project, still at version 0.0.x, with no guarantee of long-term maintenance from Vercel. For teams evaluating native compilation tools today, Rust, Go, and Zig remain the options with a mature ecosystem and without that uncertainty.