Vercel Labs published scriptc on July 27, 2026 — a TypeScript-to-native compiler that builds self-contained binaries with no Node.js, no V8, and no JavaScript engine of any kind embedded. A simple TypeScript CLI compiles to a 178KB executable that starts in 2.4ms. Compare that to Node’s Single Executable App, which bundles the entire runtime into 60–100MB and takes ~35ms to boot. The project landed on Hacker News with 221 points and 109 comments within hours of release.
How scriptc Compiles TypeScript to Native Binaries
scriptc operates on a three-tier model. In Tier 1 — the default static path — TypeScript runs through the real tsc compiler for type-checking, then into a typed intermediate representation, then to C, then through LLVM or clang to native machine code. No special syntax, no dialect, no annotations: the same TypeScript you already run on Node. Tier 2 kicks in when code can’t compile statically — specifically npm dependencies and any-typed code — by embedding QuickJS-ng, a compact JS engine at roughly 620KB, via the --dynamic flag. Tier 3 is rejection: unsupported constructs fail with specific error codes and rewrite suggestions rather than silently degrading.
The result is differentially tested. scriptc guarantees that stdout, stderr, and exit codes match Node.js output byte-for-byte for compiled code. Supported Node stdlib includes fs, path, net, http, crypto, fetch, and child processes — enough for the vast majority of CLI tools and server-side scripts. The scriptc GitHub repository is Apache 2.0 licensed with 1.2k stars as of launch day.
// hello.ts — standard TypeScript, no modifications needed
import { readFileSync } from "fs";
const file = process.argv[2];
const content = readFileSync(file, "utf8");
console.log(`Lines: ${content.split("\n").length}`);
Build: scriptc build hello.ts -o hello. Output: a 178KB binary with no Node.js required on the target machine.
The Numbers That Make scriptc Worth Watching
For CLI tools, startup time is the primary user-experience metric — every millisecond of lag makes a tool feel sluggish. scriptc’s 2.4ms startup is roughly 20x faster than Node’s 47ms and significantly faster than Bun’s ~10ms compiled mode. Binary size matters equally for containers and serverless functions, where image pull time and cold-start latency scale directly with binary weight. Node SEA ships 60–100MB. Bun’s compiled output runs ~50MB. scriptc static binaries land at 170–200KB — roughly 400x smaller than Node SEA.
Memory tells the same story: Node.js consumes 67–116MB RSS for a running process; scriptc binaries use 1–4MB. In a containerized environment running dozens of scripts, that difference compounds fast. For more on the TypeScript compilation picture, see TypeScript 7 Is Two Weeks Old. Here’s What’s Actually Breaking.
The 80% Problem You Should Know Before Installing scriptc
Here’s the limitation nobody in the announcement thread wants to lead with: approximately 80% of real TypeScript repositories use any types. Code that leans on any — plus code that imports npm dependencies with their own bundled JavaScript — can’t compile through the static Tier 1 path. It falls back to QuickJS. QuickJS is a capable engine, but it is not fast native code. One HN commenter with language performance expertise called it “hilariously slow.” The performance advantages largely evaporate on the dynamic path.
scriptc ships a coverage command precisely for this reason. Run scriptc coverage yourfile.ts before committing to migration — it reports what percentage of your code compiles statically versus requires the QuickJS fallback. For codebases written with strict TypeScript and minimal npm chains, the static ratio will be high. For everything else, manage expectations accordingly. The scriptc documentation covers the full list of compilation blockers and rewrite patterns.
About That Codebase
The HN community noticed something unusual: the repository appeared with what looks like a single very large commit — reportedly 800,000 lines — raising suspicion of an AI-generated codebase. The maintainers have openly acknowledged “Claudisms” in the documentation (artifacts typical of Claude-generated text) and are actively accepting pull requests to address them. PRs are already being merged. One commenter with compiler implementation experience went further: “This project reeks of weapons grade AI psychosis,” citing float-based number representation instead of native integers and the choice to defer integer optimization.
This matters in a practical sense. In 2026, AI-generated codebases are a real concern for teams evaluating long-term maintainability. Whether scriptc’s implementation holds up under production use is a genuine open question. The idea is sound. Community response is engaged. Whether the engineering underneath is solid enough to trust in production is something only time — and more PRs — will determine.
Key Takeaways
- scriptc compiles TypeScript to native binaries with no JS engine — 178KB, 2.4ms startup, 1–4MB memory, versus 60–100MB and 35ms for Node SEA
- It uses real
tscfor type checking and requires no changes to your existing TypeScript code — no new syntax, no dialect - The 80% caveat is real: code using
anytypes or heavy npm dependencies falls back to QuickJS, not native execution — runscriptc coveragefirst - Best fit today: well-typed TypeScript CLI tools and Docker scripts with minimal npm dependency chains
- The AI-generated codebase question is unresolved; production adoption warrants caution — but the community is actively contributing fixes
