Scriptc by Vercel: TypeScript-to-Native Compiler With No JavaScript Engine

Last updated: July 27, 2026

Vercel Labs released Scriptc, a TypeScript-to-native compiler that produces self-contained binaries with no embedded JavaScript runtime. The project landed on the Hacker News front page on July 26 and collected 178 points and 92 comments in its first day. The response is sharply polarized: some see a genuine engineering accomplishment, while others dismiss it as another Vercel Labs project that will be abandoned in a few months.

What Scriptc Does#

Scriptc compiles ordinary TypeScript into native executables through a pipeline: TypeScript source goes through the real tsc type checker, lowers to a typed IR, then emits C code that clang compiles into a native binary. The result is a standalone executable with no Node, no V8, and no JavaScript engine in the binary.

The README claims three tiers of support, each explicit and observable:

Compiled statically. The default mode handles what the README estimates as 99% of real TypeScript: classes with single inheritance and true dynamic dispatch, closures with JS capture semantics, generics (monomorphized), discriminated unions as tagged values driven by TypeScript's own narrowing, async/await on stackful fibers, exceptions with finally, destructuring, spread, iterators, template literals, and regular expressions.

Runs dynamically (--dynamic). An embedded QuickJS-ng engine (~620KB) executes npm dependencies' shipped JavaScript and any-typed code. Every value crossing back into static code is validated at runtime. A lying type throws a TypeError instead of corrupting memory.

Rejected. Everything else fails with a specific error code, a code frame, and a rewrite hint. Nothing is silently miscompiled.

The standard library coverage is ambitious. The static surface includes strings with UTF-16-exact semantics, arrays/Maps/Sets with JS-exact ordering, JSON with runtime-validated casts, typed arrays, Buffer, Math, and the Error hierarchy with typed catch. The Node API surface covers fs (sync and promises), path, process, child_process with piped streams, os, crypto, url/URL, zlib, timers, signal handlers, and the full server stack: net, http, https, tls (vendored mbedTLS), dgram, dns, fs.watch, readline. fetch and the WHATWG web subset run over the same native stack with no libcurl dependency.

Performance Claims#

The README publishes performance measurements against Node, Go, Rust, and Zig on Apple M-series hardware for byte-identical output workloads:

The startup and memory figures are the headline numbers. A 2.4ms startup and 1-4MB RSS make Scriptc binaries viable in contexts where Node is prohibitively heavy: serverless cold starts, container sidecars, CLI tools distributed as single binaries, and embedded environments.

Correctness Engineering#

Scriptc runs two enforcement mechanisms on every change. The first is differential testing: every program in an 800+ test corpus runs under Node and as a native binary; stdout, stderr, and exit codes must match byte-for-byte. Even number formatting is fuzz-verified against Node on a million doubles. The second is a memory-safety lane: the entire corpus re-runs under AddressSanitizer with a reference-count audit, and leaks or use-after-free are build failures.

The README documents deliberate divergences from Node (a few dozen, mostly around timing internals and error-object properties) as numbered items. Nothing diverges silently.

What HN Is Saying#

The Hacker News thread is worth reading because the skepticism is specific and the praise is measured. A few themes dominated.

Vercel Labs track record. Multiple commenters questioned whether Scriptc will receive long-term support. One wrote: "another vercel labs thing that's been slopped together, hyped up on twitter and then left to be forgotten about in a few months time." Another said: "It's a growth strategy: invest tokens, build some 'nice' project nobody wants, get some reach through publishment. Rinse and repeat." This distrust of Vercel's Labs pattern is the most common thread in the discussion. Vercel has shipped a steady stream of Labs projects -- Eve, the Agentic Infrastructure Stack, and the AI SDK among them -- and the community is watching to see which ones survive.

Comparisons to existing projects. Commenters pointed to Porffor and PerryTS/pry as similar projects working toward the same goal. One noted that Porffor's creator has been building toward native TypeScript compilation for a while and still only passes ~68% of Test262, expressing suspicion about how Vercel achieved broader coverage. Another comparison was to GraalVM Native Image and QuickJS -- both of which have existed for years but never achieved mainstream adoption for TypeScript workloads.

npm ecosystem compatibility. A recurring concern was that most npm packages only ship untyped JavaScript with type declarations, meaning you realistically still need a JavaScript engine to use them. Scriptc addresses this with the --dynamic flag and embedded QuickJS-ng, but the commenter noted: "if you're starting from scratch and know you won't be using any npm packages, you might as well use a language that compiles to native code natively."

Practical use cases questioned. Commenters asked what the realistic use case is. If you need native performance and small binaries, why not use Go, Rust, or Zig -- languages designed for that from day one? If you need the npm ecosystem, you are still tied to JavaScript semantics and a runtime. Scriptc's value proposition sits in a narrow band: TypeScript codebases that want native distribution without rewriting in another language. That band exists -- CLI tools, internal microservices, CI runners -- but it is narrower than the general-case pitch suggests.

The Claudism detection. Multiple commenters observed that the README exhibits characteristic phrasing patterns associated with Claude-generated code. One wrote: "It's difficult to ignore how the README is filled with Claudisms." This is worth noting because it speaks to a broader dynamic in the open-source ecosystem: AI-assisted code generation is becoming detectable, and the community is starting to factor authorship into trust assessments.

Why This Matters#

Scriptc is not the first attempt to compile TypeScript to native code, but it represents the most credible one from a major platform company. Vercel has the distribution channels to make something like this matter: if Scriptc ships as part of the Vercel CLI or integrates with the Edge Runtime, it could find a real home.

The deeper story here is about the fragmentation of the JavaScript runtime ecosystem. Node's dominance is being challenged from multiple directions: Bun rewrote the runtime in Zig, Deno rewrote it in Rust, and projects like Scriptc are asking whether a runtime is even necessary. If TypeScript can compile to native code directly, the entire concept of a "JavaScript runtime" becomes an implementation detail rather than a platform requirement.

This is especially relevant for AI coding agents. Claude Code, Codex, Cursor, and OpenCode all generate TypeScript by default. A path that lets that generated code ship as a single native binary -- no node_modules, no runtime install, no npx -- would change how AI-generated software is distributed.

FAQ#

What is Scriptc?#

Scriptc is a TypeScript-to-native compiler from Vercel Labs. TypeScript source goes through the real tsc type checker, lowers to a typed IR, and emits C code that clang compiles into a standalone binary with no Node, no V8, and no JavaScript engine inside it.

Can Scriptc use npm packages?#

Yes, through the --dynamic flag. It embeds a QuickJS-ng engine (about 620KB) that runs npm dependencies' shipped JavaScript and any-typed code, and every value crossing back into static code is validated at runtime. HN commenters noted this still means carrying a JavaScript engine for most real npm usage.

How fast and small are Scriptc binaries?#

The README reports about 2.4ms startup versus about 47ms for Node, binaries of 170-200KB in static mode (about 3MB with --dynamic), and 1-4MB typical memory use versus 67-116MB for Node, measured on Apple M-series hardware.

What happens to TypeScript that Scriptc cannot compile?#

It is rejected with a specific error code, a code frame, and a rewrite hint. The project's stated rule is that nothing is silently miscompiled, and deliberate divergences from Node are documented as numbered items.

How does Scriptc compare to Porffor and other native TypeScript projects?#

HN commenters pointed to Porffor and PerryTS/pry as projects with the same goal, and to GraalVM Native Image and QuickJS as older approaches that never reached mainstream TypeScript adoption. The open question in the thread is whether Vercel Labs will support Scriptc long term.

Sources#

• Scriptc GitHub repository -- README, performance figures, architecture overview. Fetched July 27, 2026.
• Hacker News discussion -- 178 points, 92 comments. Fetched July 27, 2026.
• Scriptc.dev -- Official documentation and Native FFI guide.
• QuickJS-ng -- The embedded JavaScript engine used by Scriptc's --dynamic mode.

Continue Reading#

• TypeScript 7 Goes Native: The Go Port and What It Means -- The TypeScript compiler itself is being ported to Go for a 10x performance improvement. Scriptc takes the idea further by making every TypeScript program produce native binaries.
• Bun's Rust Rewrite: What 535,000 Lines of Zig Teaches Us About Runtime Engineering -- Another project asking whether the JavaScript runtime can be rebuilt from scratch for performance. Bun and Scriptc approach the same problem from different directions.
• Everything Vercel Shipped at Ship 26 -- Vercel's platform strategy context for understanding where Scriptc fits in the broader product landscape.
• Deno Desktop: Building Native Apps Without Electron -- The native TypeScript trend extends to desktop: Deno's approach to building native apps without a browser runtime.
• Vercel AI SDK Guide -- Vercel's developer tooling strategy for the AI era, including how its SDK ecosystem connects to projects like Scriptc.
• Bun - another fast TypeScript toolchain, pricing and alternatives on one page
• Best Free Developer Tools - more tooling worth adding to a TypeScript stack