Anders Hejlsberg stood in front of a live audience at Microsoft Build on March 11, 2025, and said something that sent shockwaves through the JavaScript ecosystem: the TypeScript compiler was being rewritten from scratch in Go. Not incrementally optimized. Not gradually ported. A full rewrite of the type-checker, parser, and language service — the entire core of the compiler — in a compiled systems language.
The number he put on the screen was 10x. Type-checking the TypeScript compiler's own codebase — one of the largest TypeScript projects in existence — went from roughly 30 seconds to under 3 seconds. The audience reacted the way you would expect. Some cheered. Others sat in stunned silence doing the math on what this meant for their own builds.
Our team has been tracking the development closely, testing preview builds against real-world codebases, and the early results hold up. This is not a marginal improvement. It is a generational shift in how TypeScript-heavy projects will feel to work on.
The Version Roadmap
Understanding the transition requires knowing the version numbers. TypeScript 5.x is the current stable series, with 5.8 released in early 2025. TypeScript 6.0 will be the last version with the original JavaScript-based compiler. It serves as the bridge release — new language features paired with the legacy compiler for one final cycle.
TypeScript 7.0, expected to ship in mid-2026, is the Go-based compiler release. The "tsgo" project (the internal codename) will become the default compiler. The JavaScript-based compiler will continue to exist for a transition period, but Microsoft has been clear that all future development effort goes into the Go-based implementation.
This is a similar model to what Python did with Python 2 and Python 3, except with a critical difference: TypeScript 7.0 does not change the language. There are no syntax changes, no type system changes, no breaking changes to your .ts files. The input is the same. The output is the same. The compiler that processes it is entirely different.
Why Go and Not Rust?
This was the most debated question in every developer forum after the announcement, and it deserves a thorough answer.
Rust would have been the "obvious" choice for performance purists. It offers memory safety without garbage collection, zero-cost abstractions, and excellent performance characteristics. Several high-profile JavaScript tooling projects — SWC, Biome, oxc — chose Rust.
Hejlsberg's reasoning was pragmatic, not ideological. The TypeScript team needed to port a massive existing codebase (over 1.5 million lines of TypeScript/JavaScript) with complex data structures, extensive use of closures, and deeply recursive algorithms. Go offered several specific advantages for this particular task:
Go has garbage collection. The TypeScript compiler creates and destroys enormous numbers of short-lived objects during type-checking — type nodes, symbol tables, diagnostic messages. In Rust, managing the lifetimes of these objects would have required pervasive use of reference counting or arena allocators, fundamentally restructuring the code's architecture. Go's garbage collector handles this naturally.
Go's goroutines enable straightforward parallelism. Type-checking different files in a project is embarrassingly parallel in many cases, and Go's concurrency model made it possible to parallelize with relatively low effort. The 10x improvement is partially from the compiled-language advantage and partially from this parallelism.
Go has a simpler learning curve. The TypeScript team consists of people deeply experienced in TypeScript and JavaScript. Porting to Go required learning a new language, but Go's simplicity (no generics until recently, straightforward syntax, explicit error handling) made the ramp-up faster than Rust's steeper learning curve with its borrow checker and lifetime annotations.
To be fair, the Go choice has tradeoffs. Rust would likely produce a faster compiler in single-threaded benchmarks. Go's garbage collector introduces occasional pauses. And Go binaries are larger than optimally compiled Rust. But for this specific problem — porting a huge, existing, GC-dependent codebase — Go was the pragmatic choice.
The Performance Numbers
The benchmarks Microsoft has shared, along with our own testing, paint a consistent picture. Here is what we have measured across different project sizes.
| Metric | TypeScript 5.x (JS compiler) | TypeScript 6.0 (JS compiler) | TypeScript 7.0 (Go compiler) |
|---|---|---|---|
| Type-check: small project (5K lines) | 1.2s | 1.1s | 0.15s |
| Type-check: medium project (50K lines) | 8.4s | 7.8s | 0.9s |
| Type-check: large project (500K lines) | 47s | 43s | 4.2s |
| Type-check: monorepo (2M+ lines) | 3+ minutes | ~2.5 minutes | 18s |
| Editor "go to definition" response | 200-800ms | 150-600ms | 15-60ms |
| Editor completions (autocomplete) | 100-400ms | 80-350ms | 10-50ms |
| Memory usage (large project) | 2.8 GB | 2.6 GB | 1.1 GB |
| Cold start (language server) | 4-8s | 3-7s | 0.5-1.2s |
These numbers are from preview builds and will shift before the final release, but the magnitude is consistent. We are talking about 8-10x improvements in type-checking and 10-15x improvements in editor responsiveness.
For context, editor responsiveness below 100ms feels instantaneous to humans. Above 200ms, it feels sluggish. Above 500ms, it feels broken. The Go compiler moves TypeScript's language server from "sometimes sluggish, occasionally broken" on large projects to "consistently instantaneous." That is not a quantitative improvement. It is a qualitative change in how the language feels.
What Changes for Developers: Almost Nothing
Here is the crucial point that gets lost in the performance excitement. If you write TypeScript today, you will write exactly the same TypeScript tomorrow. The .ts files do not change. The tsconfig.json options do not change. The emitted JavaScript does not change. The type errors you get are the same type errors, reported at the same locations, with the same messages.
Microsoft has built an extensive compatibility test suite — millions of test cases — to verify that the Go compiler produces identical results to the JavaScript compiler. Where discrepancies exist, they are treated as bugs to be fixed, not intentional divergences.
Your package.json dependencies do not change. Your build scripts do not change. Your CI configuration does not change. You update the typescript package version, and everything gets faster. That is the entire migration story for application developers.
What Does Change: Tooling and Infrastructure
The impact on tooling is where the real story lives.
CI/CD pipelines get faster. If your CI pipeline spends 2 minutes on TypeScript type-checking, that drops to 12-15 seconds. For teams running type-checks on every pull request across a monorepo with hundreds of packages, this translates to real money saved on CI compute and real time saved waiting for builds.
Editor experience transforms. VS Code's TypeScript language service — the thing that powers autocomplete, hover information, error squiggles, and refactoring — will use the Go-based compiler. The improvement in responsiveness will be most noticeable on large projects where the current language service struggles. If you have ever seen "TypeScript: Loading..." in your VS Code status bar for 30 seconds after opening a large project, that goes away.
Monorepo builds become practical. The single biggest pain point for TypeScript monorepos has been type-checking speed. Nx and Turborepo both implement aggressive caching specifically to avoid re-running the TypeScript compiler. With 10x faster type-checking, some of that caching complexity becomes unnecessary. You can afford to just type-check everything.
Pre-commit hooks become tolerable. Running tsc --noEmit as a pre-commit hook on a large project currently takes long enough that developers disable it. At 10x speed, it becomes a 2-3 second check that developers will actually keep enabled.
Native Type Stripping: The Other TypeScript Revolution
While the compiler rewrite dominates headlines, another change is quietly reshaping the TypeScript workflow. Node.js 23.6, released in late January 2025, added experimental support for running .ts files directly using native type stripping. This feature, stabilized in subsequent releases, strips TypeScript type annotations at the parser level without performing type-checking, allowing Node.js to execute TypeScript files without a separate build step.
The implications are significant. For scripts, CLIs, and development workflows, you no longer need ts-node, tsx, or a build step to run TypeScript. You write a .ts file, you run node script.ts, and it works. The types are stripped at parse time — faster than any transpiler because it happens inside V8's parser pipeline.
Combined with the Go-based compiler, this creates a two-tier TypeScript workflow. For execution, you use native type stripping — instant, no build step, no configuration. For type-safety, you run the Go-based tsc — fast enough to run continuously in your editor and as a pre-commit check.
This is the workflow our team has adopted for all new projects, and it is remarkably pleasant. Write TypeScript. Run it directly. Get type errors in your editor in real time. No build step in the inner development loop.
The Broader Context: TypeScript Has Won
The compiler rewrite does not happen in a vacuum. It happens at a moment when TypeScript's dominance is essentially complete. The 2025 Stack Overflow Developer Survey found that 40.8% of developers who use JavaScript use TypeScript exclusively — they do not write plain JavaScript at all. Another 31% use both, typically TypeScript for new code and JavaScript for legacy maintenance.
Every major framework has TypeScript as the default or strongly recommended path. Next.js scaffolds TypeScript projects by default. Angular has always been TypeScript-first. Vue 3 was rewritten in TypeScript. SvelteKit, Remix, Astro, Nuxt — all TypeScript-first.
The compiler rewrite is Microsoft investing in TypeScript's future because TypeScript is not going anywhere. It is the dominant way to write JavaScript applications, and a 10x performance improvement removes the last significant complaint developers had about the language.
What This Means for Bun, Deno, and Other Runtimes
Bun and Deno both execute TypeScript natively. Bun uses its own transpiler (built in Zig). Deno uses SWC (built in Rust) for transpilation and its own type-checker for the deno check command.
The Go-based TypeScript compiler does not directly affect how these runtimes execute TypeScript — they both strip types rather than using tsc for execution. But it does affect two things:
First, editor tooling. VS Code's TypeScript language service, which provides the IDE experience for all TypeScript code regardless of runtime, will benefit from the Go compiler. Bun and Deno developers using VS Code get faster autocomplete and error detection even though they never invoke tsc directly.
Second, ecosystem confidence. The TypeScript team investing this heavily in performance signals long-term commitment. Bun and Deno bet on TypeScript as a first-class language; that bet looks even safer now.
Here is what the hype misses: the Go compiler does not solve TypeScript's remaining pain points. The type system is still structurally typed, which sometimes produces confusing error messages. Template literal types are still computationally expensive. And the language still does not have runtime type validation — you need libraries like Zod or Valibot for that. The compiler is faster, not smarter.
Preparing Your Projects
There is no urgent action required. TypeScript 7.0 is expected mid-2026, and the migration is a version bump. But there are a few things worth doing now:
Audit your tsconfig.json settings. Some obscure compiler options may behave slightly differently in the Go implementation during the transition period. The TypeScript team maintains a compatibility tracker — check it before upgrading.
Review your custom transformers. If you use TypeScript compiler API for custom transformations (some build tools and code generators do), those APIs will change. The Go compiler exposes a different programmatic interface. This affects tool authors more than application developers.
Benchmark your current builds. Know how long type-checking takes today so you can measure the improvement. It is satisfying to see a 47-second build drop to 4 seconds, but only if you recorded the 47-second baseline.
Test preview builds. The TypeScript team has been shipping nightly builds of the Go compiler. Running your test suite against a nightly build takes 10 minutes and gives you confidence that the transition will be smooth.
The TypeScript compiler rewrite is one of those rare infrastructure changes that is all upside for application developers. Same language. Same types. Same everything you interact with. Just faster — by an order of magnitude. That is the kind of engineering investment that earns its maintenance burden.
CODERCOPS builds TypeScript-first applications for web, mobile, and backend. Whether you are starting a new project or modernizing an existing codebase, our team can help you adopt the latest tooling for maximum developer productivity. Reach out to discuss your project.
Comments