InfoQ 中文 · 10/8/2026, 13:52:05
Vercel Labs Releases scriptc: Native TS Compiler Boosts Startup Speed but Lags in Runtime
Vercel Labs released scriptc, an experimental TypeScript compiler that generates native binaries without JavaScript engine dependencies. By combining static compilation with dynamic QuickJS execution, it achieves a median startup time of 1.78ms and minimal memory footprint. However, performance drops significantly when handling complex frameworks like Hono due to heavy reliance on the dynamic interpreter. The project is currently early-stage, best suited for cold-start-sensitive Serverless or CLI scenarios with simpler logic.
SOURCE COVERAGEOriginal coverage
scriptc is an experimental TypeScript compiler from Vercel Labs that generates native binaries without JS engine dependencies, supporting multi-backend output and hybrid execution strategies.
It supports three processing mechanisms: static compilation, dynamic QuickJS execution (--dynamic), and compile-time rejection. Startup latency is just 1.78ms (median), with idle HTTP service memory usage as low as 1.9MiB. Frameworks like Hono require fallback to dynamic execution due to type impurity, resulting in significant performance degradation.
Suitable for frontend engineers, TypeScript toolchain developers, and edge computing/Serverless infrastructure engineers.

Vercel Labs has released scriptc. This is an experimental compiler licensed under Apache 2.0 that converts standard TypeScript into small native executables. The generated binaries do not include Node, V8, or any JavaScript engine.
The repository was created on July 22, 2026, and has already garnered approximately 4,900 Stars. scriptc uses the real TypeScript compiler for parsing and type checking, converting programs into a typed intermediate representation. It can then generate readable C code, LLVM IR, assembly code, object files, native executables, or WebAssembly via WASI Preview 1.
Every syntax construct is categorized into one of three tiers: default static compilation; dynamic execution by an embedded ~620KB quickjs-ng engine when the --dynamic flag is passed for npm packages and any typed code; or rejection at compile time, returning an SC error code and rewrite suggestions.
A benchmark comparing scriptc 0.0.16 with Bun 1.3.12 and Node 24.18.0 shows that the median startup time for the scriptc CLI is 1.78 milliseconds, compared to 21.29 milliseconds for Bun and 61.78 milliseconds for Node. A node:http server using no frameworks occupies only 1.9MiB of memory when idle. The same test suite found that Hono must enable --dynamic, causing 62% of the server's code to fall into QuickJS, reducing throughput to 18,400 requests per second, whereas Bun achieves 70,500 requests per second.
On Hacker News, a developer reported that their tests showed scriptc running approximately 7.5 times slower than Node 24:
Looking at the byte array results, which represent the best-case scenario, scriptc is still about 7.5x slower than Node 24, even though Claude attempted some optimizations specific to scriptc. However, its executable starts up 12x faster (1.5ms vs 18.6ms), uses 72x less memory (2.5MiB vs 181MiB), and ultimately produces a single executable file of just 370KB with zero runtime dependencies.
Filip Pizlo argued that representing all numbers as floats and deferring integer type inference effectively skips "half of the problem of making JavaScript fast." He also pointed out that relying on QuickJS is inappropriate for a performance-oriented project, because any is common enough that actual program code will constantly fall into this dynamic execution island.
Simon Willison noted that coding agents committed 918,000 lines of code in just one week. He added that building small, fast binaries without writing C or Rust "seems like a valuable capability."
A developer found that running compatibility coverage checks on every local project resulted in hundreds of errors:
Despite the criticism, I felt it should at least be tested, so I tried it on all my local projects. Every project's coverage check produced hundreds of errors, rendering it practically useless. I understand that I could write a project from scratch without any third-party libraries and compile it into a binary; but if that's the case, why wouldn't I just use Rust, Go, Zig, D, or any other language designed for this?
Another recurring concern is the long-term maintainability of the project. Commenters noted Vercel’s zerolang, which saw no new code commits just weeks after its release. Remo Jansen attempted to compile the TypeScript 6 compiler itself, but ultimately failed due to internal compiler errors. However, he measured scriptc’s cold start time at 3.6 milliseconds compared to Node’s 48.9 milliseconds; yet for computational tasks, scriptc was significantly slower, taking 2.33 seconds.
The compiler requires Node.js 24 or higher and can be installed via npm install -g scriptc. The limitations page documents several intentional behavioral differences worth reading before use: strings are stored in UTF-8 format; memory management uses reference counting instead of garbage collection; Object.keys returns keys in declaration order; and the value of process.argv[0] is "scriptc". The npm dependencies guide explains how dependencies are handled, including the experimental --npm-static flag, which moves specified packages out of the dynamic execution island and statically compiles them.
scriptc supports macOS, Linux, Windows, and WASI Preview 1, ensuring consistent behavior through differential testing: tests compare its stdout, stderr, and exit codes byte-for-byte against Node. The project remains explicitly marked as experimental, with documentation available at scriptc.dev.
Original article: https://www.infoq.com/news/2026/09/vercel-scriptc-node/