Vercel Built a TypeScript Compiler That Doesn't Need JavaScript

TypeScript has been the default for web development for a decade. But no matter how carefully you type your code, the last step is always the same: every type gets stripped, the output is plain JavaScript, and it runs on an engine like V8. Vercel’s new Scriptc skips that step entirely, compiling TypeScript directly into a native executable with no JavaScript engine underneath.

Worth noting up front: this hasn’t caught fire in developer communities yet. There’s no sprawling Hacker News thread, no Reddit pile-on. That’s a signal about maturity, not merit — this is an early-stage project. So rather than reading the room, let’s read the architecture.

TypeScript Was Never Really a Language

That sounds harsh, but it’s technically accurate. TypeScript’s official position is that it’s a superset of JavaScript, and its compiler does exactly two things: check types, then delete them. The industry term is type erasure.

Nothing guarantees that a variable you declared as number actually holds a number at runtime. If an external API hands you a string, a string is what sits there. Types are annotations for you and your editor. At execution time, they don’t exist.

That design paid off enormously. It let TypeScript inherit the entire JavaScript ecosystem on day one. The price of using millions of npm packages unchanged was giving up any claim to being an independent language.

What Scriptc Actually Changes

The idea is simple: stop throwing type information away, and start compiling with it.

If the compiler knows for certain that a number is a 64-bit float, there’s no reason to check at runtime whether it’s a number or an object. If it knows an object’s property layout ahead of time, it can reach into memory at a fixed offset instead of doing a hash lookup. All the information V8 painstakingly reconstructs at runtime — through JIT compilation, hidden classes, inline caches — an ahead-of-time compiler already has at build time.

The output isn’t a JavaScript file. It’s a binary. No Node.js, no V8, it just runs.

The Real Target Is Cold Starts

The fact that Vercel built this is the tell. Vercel is a serverless platform company, and serverless has one chronic disease: cold starts.

A request arrives. Spin up a container. Boot the Node.js runtime. Parse the JavaScript bundle. Wait for the JIT to warm up. That sequence burns hundreds of milliseconds, and the less traffic a function sees, the more often it pays the full bill.

A native binary deletes the entire staircase. No runtime boot, no parse, no JIT warmup. It’s precisely why serverless functions written in Go or Rust feel instant. Memory footprint drops too, and since serverless billing is usually memory × duration, that’s a direct line-item cut.

Vercel’s reasoning writes itself: our customers already write TypeScript. Instead of convincing them to learn Rust, extract Rust-grade execution characteristics from the code they’ve already got.

But What About npm

This is the wall.

JavaScript is full of features that are fundamentally hostile to static compilation: eval, dynamic import(), runtime prototype mutation, Proxy, with. Every one of them assumes you cannot know what code will run until it runs. An AOT compiler demands the exact opposite.

And a meaningful chunk of npm leans on precisely these features — ORMs, dependency injection frameworks, half the bundler plugin ecosystem. Which is why projects in this space almost always end up supporting a subset of TypeScript rather than the whole thing. AssemblyScript, which compiles TS-like syntax to WebAssembly, went that route. So did Static TypeScript, the embedded-targeted compiler behind Microsoft’s MakeCode.

That’s the dilemma in one line. Narrow the supported surface and existing code breaks. Widen it and the performance advantage evaporates. Where Scriptc draws that line will decide whether it’s a product or a demo.

The Direction Is Unmistakable

Scriptc alone is an experiment. Scriptc in context is a pattern.

Microsoft rewrote the TypeScript compiler itself in Go in 2025 and shipped builds roughly 10x faster. The frontend toolchain has been migrating to Rust (SWC, Turbopack, Oxc) and Go (esbuild) for years. Bun and Deno are stripping Node.js overhead out of the runtime layer.

The common thread: the era of writing JavaScript tooling in JavaScript is ending. Scriptc pushes that same logic one layer deeper, into language execution itself.

Browsers, of course, still run JavaScript and nothing else. This kind of work matters on servers, at the edge, and in CLI tools. Nobody is compiling your React app to a native binary.

The Takeaway

Is TypeScript becoming a real language? The honest answer is about half. The specification is not going to fork away from JavaScript. What’s plausible instead is a multi-backend future, where the same TypeScript source compiles to browser JS in one target and a native server binary in another — roughly how C compiles to both x86 and ARM.

It’s early. Until there are real benchmarks and a published compatibility surface for npm, judgment should wait. But the trade is already clear enough to think about: keep the TypeScript syntax you know, give up some of the libraries you rely on. Would you take that deal?