Vercel's Scriptc Is the Right Compiler Built the Wrong Way

Vercel Labs dropped Scriptc onto GitHub this week: a compiler that takes the TypeScript you already write — no annotations, no dialect — and produces a native executable with no Node, no V8, no JavaScript engine inside. A hello-world binary lands around 200–320KB and starts in single-digit milliseconds, per Vercel's own numbers. The repo was created on July 22. It hit the Hacker News front page four days later, where commenters sized it up at roughly 900,000 lines of code and concluded most of it was written by AI agents. Both halves of that story matter, and they point in opposite directions.

The design is the part worth stealing

Every previous attempt at ahead-of-time TypeScript has dodged the language's central problem: TypeScript's types are erased at runtime and unsound by design. any, casts, structural tricks, and declaration files that lie are all legal. AssemblyScript solved this by not compiling TypeScript at all — it's a strict, WASM-targeting dialect you port code to, with its own standard library. Microsoft's Static TypeScript did the same for microcontrollers. Meta's Static Hermes got closer, compiling typed code natively and falling back to an interpreter for the rest, but it's built around Flow and React Native's needs. And the "single binary" features in Bun, Deno, and Node's SEA don't compile anything — they zip your source together with a 60–100MB engine.

Scriptc's answer is a three-tier split that's more honest than any of these. Code that can be proven static compiles to native via a typed IR and LLVM. Code that can't — npm dependencies shipping plain JS, any-typed values — runs in an embedded quickjs-ng interpreter, but only if you opt in with --dynamic (about 620KB and a jump to ~3MB binaries). Everything else is rejected at compile time with a specific error code and a rewrite hint. Crucially, scriptc coverage app.ts tells you up front which bucket every construct falls into, and values crossing from dynamic back into static code get validated at runtime, so a lying type throws a catchable TypeError instead of corrupting memory.

That stratification — static by default, dynamic as a visible opt-in, rejection as a first-class outcome — is the correct architecture for this problem, and it's the thing I'd want every future attempt to copy. (Don't confuse any of this with TypeScript 7's tsgo, by the way: Microsoft ported the compiler to Go for a 10x faster type checker. Your output is still JavaScript. Scriptc is the other thing — native output.)

The physics haven't been beaten yet

The HN thread's sharpest critique came from JavaScriptCore veteran Filip Pizlo, posting as pizlonator, and it lands. Scriptc keeps JavaScript's f64 number semantics rather than inferring integers — and integer inference is a huge fraction of what makes optimized JS engines fast, which makes the "competitive with Go and Rust" framing hard to credit for numeric code. Worse, the dynamic-tier escape hatch is QuickJS, which is dramatically slower than V8 on compute-heavy work. That inverts the pitch for real applications: the moment your dependency graph pulls meaningful work into the dynamic tier, you're running it on an interpreter that's slower than the Node you left. Scriptc is fastest exactly where your code is already boring.

The strict static tier also means real codebases will hit rejections. Porffor — the solo-developer JS/TS AOT compiler that's been grinding at this for two years — passes roughly two-thirds of test262, the ECMAScript conformance suite, and its author is candid that the remaining third is where the pain lives. Scriptc's correctness story is 800-odd differential test programs that must match Node's stdout, stderr, and exit codes byte-for-byte, plus an AddressSanitizer lane. That's a genuinely good methodology. It's also two orders of magnitude smaller than test262, built in five days.

Which is the real issue. Vercel Labs hasn't published anything about how Scriptc was built, but a five-day-old repo of this size with README prose full of what one commenter called "Claudisms" reads as an AI-agent showcase — plausibly the point, for a company selling AI-era infrastructure. Compilers are precisely the domain where "it passes my tests" and "it's correct" diverge most violently. Nine hundred thousand lines that no human has read is not a foundation; it's a liability with good benchmarks.

What to actually do with it

If you ship CLI tools in TypeScript, this is worth an afternoon. npm install -g scriptc, then run scriptc coverage on your smallest dependency-free tool and see what the static tier accepts. The comparison to beat is bun build --compile: Bun gives you a ~100MB binary that runs everything; Scriptc claims ~200KB and ~2.4ms startup for what it accepts. For internal CLIs, install scripts, and sidecar binaries — places where you'd otherwise reach for Go purely to avoid shipping a runtime — that's a real trade worth testing. macOS arm64 is the primary target today, with Linux and Windows via cross-compilation.

What you should not do is put it anywhere near production, and Vercel's own framing agrees — this is a Labs experiment, not a product. It's also unmistakably strategic: Vercel built ncc, built and then archived pkg, and has an obvious commercial interest in TypeScript that cold-starts in 2ms and 4MB of RSS instead of 47ms and 100MB. If Scriptc's ideas survive contact with reality, expect them to resurface in Vercel's compute platform long before the compiler itself stabilizes.

My read: the three-tier design is a genuine contribution, the implementation is an unreviewed AI artifact, and those are separable. Porffor proved a careful human needs years for this problem; Scriptc is a bet that agents plus differential testing can shortcut that. The coverage report will tell you within an hour whether your code lives in the fast tier. Whether the compiler underneath deserves your trust is a question its test suite is nowhere near big enough to answer yet.