Vercel Labs' ScriptC trades sustained TypeScript throughput for millisecond startups

`scriptc build` passes the source to the official TypeScript compiler for parsing and type checking, lowers the checked program to a typed IR, and then emits C, LLVM IR, assembly, object files or WebAssembly for WASI Preview 1 ^[3]. Each stage can be dumped with `--emit` ^[3]. A fully static build still links a small runtime pack for memory management and core primitives ^[4]. The binary has no Node, no V8 and no JIT ^[4]. A `node:http` server compiles to an event loop that calls native socket primitives directly ^[5].

In the benchmark InfoQ reported, scriptc 0.0.16 started a CLI about 12 times faster than Bun 1.3.12 and about 35 times faster than Node 24.18.0 ^[10]. A framework-free `node:http` server idled at 1.9MiB ^[8]. For those numbers to transfer to another workload, two things have to be true: the program has to compile without `--dynamic`, and most of its run time has to be startup.

One developer on Hacker News tested the second condition. A byte-array workload ran about 7.5 times slower than Node 24, while the 370KB executable started in 1.5ms against 18.6ms and used 2.5MiB against 181MiB ^[12]. The dev.to write-up puts typical single-binary bundles at 40MB to 90MB, because they carry V8 and the Node runtime ^[1]. On the developer's figures, the binary saves 17.1ms at startup and spends 6.5 extra milliseconds for every millisecond Node spends working. It comes out ahead only when the Node version does under about 2.6ms of work per run ^[13]. That assumes the slowdown applies evenly to everything after startup ^[13]. Remo Jansen's attempt to compile the TypeScript 6 compiler failed at an internal compiler error. He measured a 3.6ms cold start against Node's 48.9ms and a much slower 2.33s on compute, according to InfoQ ^[15].

Filip Pizlo said treating every number as a float and deferring integer inference skips "half the problem of fast JS" ^[14]. He also argued that `any` is common enough that real programs will keep falling into the QuickJS fallback ^[14]. `scriptc coverage app.ts` is the check to run first. It reports what share of the AST compiles statically and gives a diagnostic code for each dynamic site ^[16]. One developer ran it on every local project and wrote: "For every single of them the coverage generates hundreds of errors and so it is basically useless." ^[17] An experimental `--npm-static` flag compiles named packages out of the fallback ^[20].

The testing discipline deserves credit. scriptc targets macOS, Linux, Windows and WASI Preview 1, and differential tests compare stdout, stderr and exit codes byte for byte against Node ^[19]. Because the compiler emits readable C, anyone doubting a performance claim can read the code it actually produced ^[3].

Simon Willison said building small, fast binaries without writing C or Rust "seems like a valuable capability" ^[23]. I agree, for a narrow case. In my view the first candidate is an internal CLI with no npm dependencies and a clean coverage report. Where an edge target needs it, that CLI can be cross-compiled to wasm32-wasi with Zig as the linker driver ^[25]. The compiler driver itself needs Node.js 24 or newer ^[24], so the build machine keeps the runtime the binary leaves out.