Vercel's ScriptC Compiles TypeScript Straight to Native Code

Vercel Labs has published scriptc, an Apache-2.0-licensed compiler that turns TypeScript and JavaScript into native binaries instead of running them through a JavaScript engine, and outside testing this month found it starting a simple server roughly 35 times faster than Node.js 24.

The project, hosted at github.com/vercel-labs/scriptc, uses the TypeScript compiler itself for parsing and type checking, then generates a typed intermediate representation that can be turned into C, LLVM IR, native assembly, an object file, a standalone executable, or a WebAssembly module. Code that scriptc can prove the types of at compile time gets compiled statically. Code that depends on dynamic behavior, or on the any type, either gets rejected at compile time with a rewrite hint or, if the developer passes a --dynamic flag, falls back to running inside an embedded copy of the QuickJS engine bundled into the binary.

What Vercel's own numbers claimed in July

German trade outlet Heise covered scriptc on July 31, when the project was newer, reporting figures Vercel supplied itself: startup time falling from 47 milliseconds on Node.js to 2.4 milliseconds, peak memory use dropping from 116 megabytes to 4, and a static binary landing around 200 kilobytes against roughly 2 megabytes for an equivalent program written in Go. Those are Vercel's own numbers, not independently measured, and Heise reported them as such.

Vercel's July benchmark	Node.js	scriptc
Startup time	47 ms	2.4 ms
Peak memory	116 MB	4 MB
Static binary size	—	~200 KB

What an independent test found in September

By Sept. 25, InfoQ writer Daniel Curtis had run his own cold-start comparison of a basic node:http server: scriptc started in 1.78 milliseconds against 21.29 for Bun and 61.78 for Node.js 24, with idle memory for the scriptc version measured at 1.9 mebibytes and the compiled executable itself at 370 kilobytes.

1. scriptc1.78 ms
2. Bun21.29 ms
3. Node.js 2461.78 ms

Source: InfoQ, accessed 2026-09-27

That same test cut the other way once real work entered the picture. Running the Hono web framework's benchmark suite through scriptc's --dynamic path, Curtis measured 18,400 requests per second against 70,500 for Bun, and a separate byte-array benchmark ran roughly 7.5 times slower on scriptc than on Node 24, even though it still started 12 times faster and used 72 times less memory.

Where the QuickJS fallback pulls it back down

The gap traces back to the same --dynamic flag that makes scriptc usable with ordinary TypeScript in the first place. Any code scriptc cannot fully type at compile time runs through an embedded build of QuickJS, a roughly 620-kilobyte JavaScript engine, rather than through scriptc's native path. On Hacker News, Filip Pizlo, a longtime contributor to WebKit's JavaScriptCore engine, argued the design "skips half the problem of fast JS" because real-world TypeScript leans on any often enough that programs keep falling back into that slower island rather than staying in the fast, statically compiled one.

A separate outside attempt described in the same InfoQ report illustrates the same limit from a different angle. Developer Remo Jansen tried compiling the TypeScript 6 compiler itself with scriptc, measured a 3.6-millisecond cold start against 48.9 milliseconds for the same program on Node, and then watched a heavier computation inside it take 2.33 seconds, a case where the interpreter fallback outweighed the startup win. His attempt to compile the full TypeScript compiler failed outright with an internal compiler error, which Vercel has not addressed publicly.

Who is building it, and why some doubt it sticks

GitHub credits Chris Tate, who lists Vercel as his employer, with 719 of the scriptc repository's commits, by far the largest share of any contributor, alongside smaller contributions from Vercel engineer Jimmy Miller. The repository, created July 22, has drawn 5,272 stars and carries 54 open issues as of Sept. 27, and Vercel has marked it version 0.0.x without a date for a stable release. Node.js 24 or newer is required to run the compiler itself, meaning building software that avoids Node still starts with installing it.

Some of the skepticism visible in scriptc's GitHub issues and the InfoQ comment section points to Vercel's own history rather than the code: community members have cited zerolang, an earlier Vercel-associated language project that was abandoned, as a reason to wait before rewriting production code around scriptc. Vercel has not said whether scriptc will receive long-term support or remain a labs experiment, and the project's own documentation still lists gaps in Node API coverage for functions built on fs, path, crypto, http, https, net, dns, timers and fetch that Vercel says it is working to close.

What happens next depends on whether Vercel treats the 7.5-times slowdown on dynamic code as a bug to fix or a permanent trade-off of the design. Until scriptc reaches a stable release, the two internal links below and this piece are safer reading than a rewrite: Dreamnum's Univer SDK took its own open-source project from a similar early state to a 1.0 release this September, and Vectorize's Hindsight went through the same public scrutiny scriptc is facing now before its usage numbers caught up with its GitHub stars.