scriptc: Vercel Labs Compiles TypeScript to Native Binaries — No Node, No V8

A GitHub repo with 439 stars and five contributors landed on Hacker News on July 26, 2026, with a claim specific enough to be checked: a recursive fib(30) function, compiled to a native binary, starting in about 2 milliseconds and weighing in around 178KB. No Node.js. No V8. No JavaScript engine anywhere in the binary — unless you explicitly ask for one.

The project is scriptc, out of Vercel Labs. The pitch is "zero-runtime TypeScript": compile ordinary .ts files straight to native machine code via LLVM, skip the interpreter entirely, and only fall back to an embedded JS engine for the parts of your code that genuinely can't be statically analyzed. It's a real, working compiler with concrete benchmarks. It's also — per the Hacker News thread that followed it — very plausibly the output of AI coding agents working at a pace that makes at least one expert reviewer call the whole architecture "idiotic." Both things are true at once, and that tension is the actual story.

This sits at the intersection of two things explainx.ai tracks closely: frontier developer tooling coming out of companies like Vercel, and what happens to code review, trust, and hype cycles when a project moves at agent speed instead of human speed — a theme also present in Mitchell Hashimoto's AI psychosis warning and the Bun Zig-to-Rust rewrite.

TL;DR — what people are asking about scriptc

What scriptc actually claims to do

The core idea in the README is that most TypeScript is more statically analyzable than developers assume. Run scriptc coverage app.ts against your codebase and it reports what percentage of statements compile to native code versus what blocks static compilation — with specific, numbered error codes (SC1090, SC2020, and others) naming the exact blocker, like "functions with optional parameters as values" or Promise.reject edge cases.

Three tiers, not a black box

scriptc is explicit about what happens to code it encounters, which is a notable departure from most "just works" compiler marketing:

1. Compiled statically — the default. Straight to native code via LLVM.
2. Runs dynamically (--dynamic flag) — embeds quickjs-ng, a roughly 620KB JS engine, to execute anything that can't be statically compiled: shipped npm JS, any-typed code. Runtime type validation sits at the boundary, so a type that lies throws a catchable TypeError instead of corrupting memory.
3. Rejected — anything else fails to compile with a specific error code and a rewrite hint. Nothing gets silently miscompiled.

That third tier is the detail worth sitting with. A lot of "AI-assisted" or "fast" compiler projects quietly degrade correctness under pressure; scriptc's design explicitly refuses to guess.

Static language and stdlib coverage

The claimed static coverage is broad for a project this young: classes with single inheritance and devirtualized dynamic dispatch, closures with JS capture semantics, monomorphized generics, discriminated unions as tagged values, async/await on stackful fibers with JS-exact scheduling, exceptions and finally, destructuring, spread, optional/default/rest parameters, getters/setters, iterators, template literals, and regex running on the same ECMAScript-exact bytecode interpreter QuickJS itself uses.

Standard library coverage includes UTF-16-exact strings, JS-exact-ordering arrays/Maps/Sets, JSON with runtime-validated casts, Math, typed arrays/Buffer, and typed Error hierarchies. On the Node API surface: fs (sync and promises), path, process, child_process, os, crypto, url/URL, zlib, timers, signal handlers on a dependency-free event loop, plus a full server stack — net, http, https, tls (vendored mbedTLS), dgram, dns, fs.watch, readline. The README's specific claim: "real proxy servers compile." There's also fetch and a WHATWG web subset (streams, Headers, AbortSignal) running over native net/TLS, with no libcurl dependency.

Escape hatches for the edges

Three mechanisms cover cases the static/dynamic split doesn't handle cleanly:

• comptime() — runs TypeScript at build time in an isolated VM and bakes the result into the binary as a literal.
• Native FFI (--ffi) — binds signature-only TypeScript declarations directly to the C ABI, no wrapper layer.
• Checked casts — JSON.parse(...) as Config inserts runtime validation that throws a catchable error naming the exact offending path, rather than trusting the type assertion blindly.

The numbers, and who's checking them

The README's performance claims, benchmarked on Apple M-series hardware with byte-identical output verified against Node, Go, Rust, and Zig:

Vercel Labs backs this with a real correctness suite on paper: 800+ differential tests comparing native binary output byte-for-byte against Node across stdout, stderr, and exit codes; JS-exact number formatting fuzz-verified against a million doubles; live client-driver tests for the server stack; an AddressSanitizer plus refcount-audit memory-safety lane on every change; and a documented, numbered list of deliberate divergences from Node behavior (mostly timing internals and error-object properties).

That's a genuinely serious testing posture for a project at v0.0.17. It's also exactly the kind of infrastructure an AI agent fleet is good at generating quickly — which is part of why the HN thread reacted the way it did.

What people are actually arguing about on Hacker News

The top comment, from a user going by sheept, undercuts the "zero-runtime" framing directly: most of the npm ecosystem ships plain, untyped JavaScript with only .d.ts files describing the types. That means realistically most production TypeScript projects — anything with a real node_modules — will lean on the --dynamic fallback constantly, not occasionally. The comment contrasted this with AssemblyScript, an existing option for developers already willing to write dependency-free code by convention. If your codebase is mostly greenfield and dependency-light, scriptc's static path is real. If it has the dependency graph of a typical production app, you're mostly running QuickJS anyway — which reframes "zero-runtime" as a best-case, not a default case.

The speed suspicion

A commenter using the handle acmnrs pointed at Porffor — a similar from-scratch TypeScript/JavaScript-to-native compiler project by creator CanadaHonk that has been running for a long time and, by the commenter's account, still only passes around 68% of the Test262 conformance suite despite sustained effort. The comparison raised an obvious question: how did scriptc apparently cover this much static language surface, plus a server stack, plus 800+ differential tests, this fast?

Commenter simonw offered the likely answer: the repo's contributor graph reportedly shows roughly 918,000 lines of code landing in a single week — a volume that reads far more like AI-agent-assisted development than hand-written compiler internals, and one that lines up with Vercel's own public focus on AI tooling. Simonw also submitted a small PR to the repo himself, fixing a wording issue in the README — removing the phrase "honestly priced," which was merged quickly. Another commenter separately noted the README had already been cleaned up once, and described it as "filled with Claudisms" — writing patterns that read as characteristically AI-generated.

None of this is confirmed by Vercel as an official statement about their workflow. It's circumstantial, but the circumstantial case is specific and checkable against the actual repo history, which is more substantive than a vibe.

The technical takedown

The sharpest comment came from a user going by pizlonator, who described their own background as making dynamic languages fast professionally. They called the architecture "idiotic" for three concrete reasons:

1. Using QuickJS at all in something marketed on performance — calling it "hilariously slow" as a fallback engine for a project whose whole pitch is speed.
2. Floats for all numbers, deferring integer-type inference and optimization — which they described as "half the problem of fast JS" left unaddressed.
3. Rejecting under-annotated or dynamic code without acknowledging how common loosely-typed patterns actually are in real npm packages — the same gap sheept's comment raised from a different angle.

Pizlonator said they planned to independently benchmark scriptc, and contrasted it favorably against Porffor's more careful, already-benchmarked tradeoffs — a project that has moved slower but reportedly been more honest about what it does and doesn't handle. They also described the project as reeking of "weapons grade AI psychosis" — a pointed, informal jab implying scrictc might be over-hyped AI-agent output without the engineering rigor its numbers imply. It's the same phrase Mitchell Hashimoto used in May 2026 to describe companies that can no longer have a rational conversation about their own AI-generated code — now applied, semi-jokingly, to a specific open-source repo.

The overall HN reaction was mixed rather than dismissive: genuinely impressed by the concrete, checkable numbers on binary size and startup time, but skeptical of both the speed of development and whether the architecture choices — QuickJS as the fallback, float-only numbers, strict rejection of dynamic patterns — hold up once someone actually runs an adversarial benchmark. As of this writing, no independent benchmark of scriptc exists. Pizlonator's promised one hasn't landed yet.

Why this matters beyond one repo

scriptc is a useful stress test for a question that's going to keep coming up as AI coding agents get faster: when a small team (or a small team plus a large agent fleet) ships hundreds of thousands of lines of systems-level code in a week, complete with a serious differential-testing harness, how should a skeptical reader evaluate it?

The instinct to distrust suspiciously fast progress is reasonable — it's the same instinct behind the scrutiny AI-generated code review debates keep circling back to. But "moved fast" and "built badly" aren't the same claim, and conflating them is its own kind of laziness. scriptc's testing infrastructure (800+ differential tests, fuzz-verified number formatting, an AddressSanitizer lane) is exactly the kind of scaffolding that makes fast, agent-assisted iteration defensible rather than reckless — assuming it's real and actually gating merges, which is unverifiable from a README alone. Compare this to the discipline documented in Bun's Zig-to-Rust rewrite, where adversarial review and a million-assertion conformance suite were the actual guardrails, not the marketing copy.

At the same time, pizlonator's specific technical objections — QuickJS as a performance fallback, float-only number representation, under-tested edge-case coverage relative to a slower but more battle-tested project like Porffor — are the kind of criticism that doesn't go away just because a repo has a compelling demo. Vercel Labs is a credible source technically, but credibility doesn't substitute for an independent benchmark that hasn't been run yet.

Honest limitations, as of July 27, 2026

• Platform support is narrow. macOS arm64 is the primary supported target; Linux and Windows build via cross-compilation with their own differential test lanes, which is a different maturity bar than "fully supported."
• Requires clang (comes with Xcode Command Line Tools on macOS) — not a pure npm install.
• npm dependency support only exists in --dynamic mode. Packages resolve via Node's own resolution algorithm, typecheck against their shipped .d.ts, and get embedded into the binary at build time — binaries never read node_modules at runtime, which is a real architectural win, but it still means shipping the QuickJS engine for most real projects.
• Only five contributors, v0.0.17. This is very early — a 439-star repo, not a production-hardened tool.
• No independent benchmark exists yet. Every number in the README comes from the project's own test harness. That harness looks serious, but "the project graded its own homework" is a fair caveat until someone outside Vercel Labs reruns the comparisons.

Related reading

• Should developers stop reviewing AI-generated code?
• Bun's Zig-to-Rust AI rewrite — Fireship and the primary postmortem
• Mitchell Hashimoto warns of AI psychosis in software companies
• Vercel eve: the open-source agent framework for production AI agents
• What is Vercel? How to deploy your app in minutes
• Matt Pocock on TypeScript skills and progressive disclosure
• The WebAssembly complete guide
• Codex vs Claude Code: an AI agent comparison

Repo stats (stars, forks, contributor count, release version), performance numbers, and the Hacker News discussion referenced here reflect the state of the scriptc repository and thread as of July 26-27, 2026. Vercel Labs' own benchmarks are cited as claimed, not independently verified — no third-party benchmark of scriptc existed at the time of writing. Verify current numbers before citing them as current fact.