TypeScript 7 Just Got 10x Faster

The biggest TypeScript release in a decade

Anders Hejlsberg, technical fellow at Microsoft, has announced TypeScript 7: a native-code port of the compiler and the entire tool set, rewritten in Go. The project started as an experiment about two years ago, turned into a commitment, and has now shipped as what Hejlsberg calls by far the biggest TypeScript release in a decade.

The number attached to it is 10× faster tooling. That is worth stating precisely: this is a speedup to the compiler and the language service, not to the JavaScript your code emits. Your app does not get faster. Your feedback loop does.

Why the compiler had to leave JavaScript

TypeScript is fourteen years old and has been self-hosted from early on, written in itself. That was a genuine advantage at the start, since the team used the tool every day and felt its rough edges directly. It also meant the compiler shipped as a JavaScript application.

JavaScript was optimized for building UI in a browser, not for compute-intensive workloads like a type checker. The bill came due at scale. The most commonly reported issue on the TypeScript repo is performance and, when it isn't performance, it's out of memory.

That matters because the community got very large. TypeScript now averages just under a billion npm downloads a month, and less than a year ago it became the number one language on GitHub. A community that size writes very large projects. One of TypeScript's sister projects, Visual Studio Code, is 1.3 million lines across nearly 8,000 files and takes real time to type check.

What 10× actually looks like

Hejlsberg demoed both compilers side by side on the same machine, on the full VS Code codebase:

• TypeScript 6: about 50 seconds.

• TypeScript 7, default settings: about 6.5 seconds, roughly 7.5×.

• TypeScript 7, with 12 type checkers on a 16-core machine: about 4.5 seconds, roughly 12×.

Memory use in that last run was about the same as the old compiler needed to do the job ten times slower.

"Often projects brag about a 30% speed improvement, but 10x is truly a game-changer."

The concurrency dividend

Up to half the gain comes from being native code. More than half comes from shared-memory concurrency, which is the part that was simply unavailable before.

Every phase now runs in parallel. Parsing, binding, and emitting process files side by side. Type checking spins up four type checkers by default, each taking a quarter of the files, and you can raise that: the 12-checker run above deliberately spent three quarters of the machine's cores on type checking. Hejlsberg's favorite screenshot is a 32-core, 128 GB build machine compiling a 15-million-line codebase with every core saturated. Under the old compiler that graph is one green bar and 31 idle CPUs.

This is the free-lunch-is-over argument made concrete. Moore's law stopped handing out faster cores years ago; it hands out more of them. Tools that can't use them are leaving most of the machine on the table.

The port is a port, deliberately

TypeScript 7 is the same code, the same structure, the same algorithms and semantics as TypeScript 6, moved to a different language. The team puts behavioral parity at 99.99%. That is a compatibility decision, not a modesty one: you should expect builds to behave exactly as they did, minus a few small details. It has also been battle tested through a year of public native previews with industry partners feeding issues back.

The language service is the quieter win

Faster CLI builds are nice. The language service is arguably what you actually live in, and in TypeScript 7 it moves to the Language Server Protocol.

Day to day that's invisible, but it makes the service far easier to integrate with editors beyond VS Code, and increasingly AI tooling uses LSP to semantically validate the code it generates. The practical effect is that operations feel instant. Find-all-references returns immediately; red squigglies appear as you type. Restarting the server entirely, which kills the process, reparses all 8,000 files, and re-reports errors, takes under two seconds. The old service needs 10 to 12 seconds on the same project just to become responsive.

The one reason to stay on 6

If your codebase depends on the TypeScript compiler APIs, stay on TypeScript 6 for now. That includes tools built on top of them: Vue, Astro, Svelte, and Volar. This is exactly why the two versions are designed to coexist. Today you install TypeScript 6 by default and add TypeScript 7 as an extension; eventually TypeScript 7 becomes the default.

The team is working with those partners on a new native API, callable cross-process, and it ships in 7.1.

Why it matters

Nobody switches languages on a fourteen-year-old, billion-download-a-month project casually. The interesting part isn't Go, it's the admission that a self-hosted compiler had hit a ceiling that no amount of tuning inside JavaScript could raise, and that the remaining headroom was in cores nobody was using.

If you're not blocked on the compiler APIs, the upgrade is close to free and the payoff is the least glamorous, most valuable thing in engineering: a feedback loop that stops making you wait.