A Rewrite That Actually Delivers
Microsoft has shipped TypeScript 7, the general availability release of a native compiler port written in Go, and the headline numbers are the kind that rarely survive contact with reality yet appear to here. The team reports full-build speedups typically between 8 and 12 times over TypeScript 6. The flagship benchmark is compiling Visual Studio Code itself, all 2.3 million lines of it: what took TypeScript 6 roughly 125 seconds now finishes in 10.6 seconds, an 11.9x improvement. Other large projects show similar gains, with Sentry at 8.9x and Playwright at 8.7x, alongside memory reductions ranging from 6 to 26 percent across tested codebases.
Rewrites that promise an order-of-magnitude improvement are usually a warning sign, not a milestone, because they so often ship late, break compatibility, and underdeliver. TypeScript 7 is notable for doing what it said it would. The team describes the effort as a faithful native port, deliberately preserving the structure and logic of the original codebase so that results stay consistent and compatible between the two compilers rather than diverging into a subtly different language. That discipline is why the speed gains arrive without a corresponding wave of behavioral surprises, and it is the part of this release that other maintainers contemplating a rewrite should study most carefully.
Why Go, and Why It Was Worth It
The choice of Go was not arbitrary. The original TypeScript compiler was written in TypeScript itself, which meant it ran on JavaScript and inherited that runtime's single-threaded execution model and garbage-collected overhead. Type checking a large project is exactly the kind of workload that benefits from native code and true parallelism, and JavaScript could offer neither. Go provides native speed, real shared-memory multithreading, and a mature concurrency model, and TypeScript 7 exploits all three. Parsing, type-checking, and emitting can now run in parallel, and steps like parsing and emitting, which are largely independent across files, scale naturally as codebases grow.
The release surfaces this concurrency to developers through new controls. A checkers flag, defaulting to four, sets the number of type-checking workers, while a builders flag governs project references, and a singleThreaded option remains for debugging or constrained environments. The file-watching system was rebuilt on Parcel's watcher, ported from C++ to Go. These are the kinds of low-level engineering choices that never make a keynote slide but determine whether the promised speedups hold up in messy real-world repositories. The result is a compiler whose performance improves as your codebase gets larger, which inverts the usual and painful relationship between project size and build time.
What the Speed Actually Changes
It is tempting to treat an 11x build speedup as a quantitative improvement, but at this magnitude it becomes qualitative. A type check that took two minutes and now takes ten seconds is not merely faster; it changes what developers do. Feedback that was slow enough to prompt a context switch, a glance at a phone, a lost train of thought, is now fast enough to stay inside the flow of writing code. Real-world numbers back this up. Slack reports eliminating 40 percent of merge queue time and cutting type-checking from 7.5 minutes to 1.25 minutes, while the language server shows 80 percent fewer failing commands and 60 percent fewer crashes than under TypeScript 6.
For engineering leaders, the compounding effects are where the value lives. Faster local checks mean tighter iteration for every developer, every day. Faster continuous integration means shorter merge queues, which means more changes shipped per unit of time and less expensive compute burned waiting. A more responsive language server means fewer of the small editor stalls that erode focus across a working day. None of these individually justifies a migration, but together, multiplied across a large engineering organization and a year of work, they represent a meaningful reclamation of both developer time and infrastructure cost. This is the rare tooling upgrade whose benefits are easy to quantify and hard to dismiss.
The Migration Is Not Free
TypeScript 7 is not a drop-in swap, and Microsoft has been candid about that. The default configuration has changed, with strict mode now on by default, modules set to esnext, and types defaulting to an empty array. Deprecated TypeScript 6 features that previously produced warnings now cause hard errors, including ES5 targeting, downlevel iteration, and classic module resolution. For teams on modern, strict configurations, the transition may be nearly painless. For those carrying older settings or legacy patterns, it will require real work to clear the new errors before the compiler will cooperate.
There is a more consequential limitation for tooling authors. TypeScript 7.0 ships without a programmatic API; that arrives in 7.1. In the meantime, workflows that depend on the compiler API, notably Vue, MDX, Astro, Svelte, and Angular template tooling, cannot yet move to TypeScript 7. Microsoft has provided a compatibility package that lets version 7 run side by side with version 6, which is the pragmatic bridge, but it means many teams will run both compilers for a period rather than cutting over cleanly. Anyone planning a migration should map their dependency on framework-specific tooling first, because for a meaningful slice of the ecosystem, the honest answer today is not yet.
A Template for Modernizing Critical Tools
Beyond the immediate benefits, TypeScript 7 is an instructive case in how to modernize infrastructure that millions of developers depend on. The team did not chase a from-scratch reimagining that would have fractured compatibility and stranded the ecosystem. It performed a disciplined native port, holding the language's behavior fixed while replacing the engine underneath, and it staged the rollout through release candidates and a compatibility package so that the community could adopt on its own timeline. That is how you replace a load-bearing tool without breaking the buildings that rest on it.
The broader signal is that the industry is increasingly willing to reach for systems languages to solve the performance ceilings of tools originally written in dynamic ones. We have seen this pattern across the developer tooling landscape, and TypeScript, given its ubiquity, is the most prominent example yet. For engineering organizations, the practical guidance is straightforward. Pilot TypeScript 7 on a representative service, measure the actual build and CI gains against your own codebase, audit your dependence on the not-yet-supported framework tooling, and plan the migration deliberately. The upside is genuine and measurable, but the path to it rewards teams that treat it as a project rather than a version bump.
