Vercel Labs has shipped scriptc, an experimental compiler that promises to let developers distribute ordinary TypeScript programs as standalone native binaries with no Node.js runtime, no V8 engine, and no JavaScript runtime embedded in the final artifact. The tool, released under the Apache 2.0 license, has pulled roughly 4,900 stars on its repository since it appeared on 22 July 2026, generating a wave of both enthusiasm and skepticism across the developer community.
How scriptc Actually Works
At its core, scriptc takes the familiar TypeScript compiler pipeline for parsing and type checking, then lowers the program to a typed intermediate representation before emitting downstream artifacts. Those artifacts include readable C source code, LLVM IR, assembly, object files, native executables, and WebAssembly binaries compatible with WASI Preview 1. The project is installed globally via npm install -g scriptc and requires Node.js 24 or newer.
Every construct a TypeScript program uses lands in one of three tiers. Most code is compiled statically by default. When a dependency or typed feature requires it, the --dynamic flag kicks in and runs the code inside an embedded quickjs-ng engine of roughly 620KB. Anything that cannot be handled by either path is rejected at compile time with an SC error code and a suggestion for rewriting. The result is a trade-off graph rather than a clean compilation model, and navigating it is where much of the controversy lies.
The Startup Numbers Are Real, the Throughput Numbers Are Not
Benchmarking scriptc 0.0.16 against Bun 1.3.12 and Node 24.18.0 produced a striking startup advantage. Median CLI startup landed at 1.78 milliseconds, compared to 21.29ms for Bun and 61.78ms for Node. A framework-free node:http server used just 1.9MiB of idle memory. These figures matter for serverless functions, CLI tools, and edge deployments where cold start time and memory footprint directly translate to cost and user experience.
The picture changes with real workloads. A simple Hono web server required the --dynamic flag, pushing 62 percent of the server logic into the embedded QuickJS engine. Throughput dropped to 18,400 requests per second, well below Bun's 70,500. One developer who tested byte-array operations found scriptc running roughly 7.5 times slower than Node 24, even after asking Claude to apply scriptc-specific optimizations. The trade, as the developer noted, was a 12x faster startup, 72x less memory usage, and a single 370KB executable with no runtime dependencies.
What Developers Actually Like and Dislike
The enthusiasm is not unfounded. Simon Willison, a widely followed developer and journalist, observed that coding agents are generating enormous volumes of code and that having a path to small, fast binaries without writing C or Rust "seems like a valuable capability." That framing captures the core appeal: scriptc lowers the friction between a TypeScript prototype and a distributable binary in a way that Go, Rust, or C never have.
The criticism is equally pointed. Developer Filip Pizlo argued that using floating-point numbers for all arithmetic and deferring integer inference avoids "half the problem of fast JavaScript," and that relying on QuickJS is a structural weakness because real programs will inevitably hit the dynamic tier. Another developer reported that running code coverage through scriptc produced hundreds of errors across every local project tested, calling the tool effectively unusable for anything beyond a from-scratch project with no third-party dependencies.
The question of why bother was also raised bluntly. If the practical ceiling is a scratch project with no external libraries, developers can already reach native binaries with Go, Rust, Zig, C, Nim, Kotlin Native, and a half dozen other languages designed from the ground up for compilation. Scriptc's value proposition, under this reading, is limited to a niche where the TypeScript ecosystem and the convenience of a single-file binary outweigh the performance penalty.
The Longevity Question and a Reminder from Vercel's Past
A recurring concern in the discussion threads is whether scriptc will still exist in six months. Commenters pointed to Vercel's earlier experiment, zerolang, which stopped receiving commits weeks after launch. Remo Jansen attempted to push the tool further than intended by trying to compile the TypeScript 6 compiler itself. The attempt failed with an internal compiler error, but the partial results were telling: a 3.6 millisecond cold start compared to Node's 48.9 milliseconds, though compute-bound performance was significantly slower.
Where the Tool Is Actually Headed
Despite the mixed reception, scriptc is not without design intention. It targets macOS, Linux, Windows, and WASI Preview 1. Its differential test suite compares stdout, stderr, and exit codes byte for byte against Node, which is an unusually rigorous standard for an experimental compiler. The documented divergences, available at scriptc.dev, cover memory management through reference counting rather than garbage collection, UTF-8 string storage, declaration-order Object.keys behavior, and a modified process.argv[0]. The --npm-static flag allows named packages to be compiled out of the dynamic island, which may gradually shrink the category of code that hits the QuickJS fallback.
Scriptc occupies an interesting position in the toolchain landscape. It is not trying to replace Rust or Go for systems programming. It is trying to make TypeScript distribution frictionless in contexts where shipping a Node.js runtime would be impractical. Whether that niche is large enough to sustain the project, and whether the technical compromises around dynamic code and integer performance can be narrowed, will determine if it becomes a practical tool or another experiment that faded. For now, the startup numbers and the memory footprint give it a genuine argument, even as the throughput gap reminds everyone that compiling TypeScript to a tiny binary is not the same as compiling it to a fast one.