A 10x Faster TypeScript: Microsoft's Native Port in Go
Microsoft announces a native Go port of the TypeScript compiler that cuts build times by 10x, halves memory usage, and delivers an 8x faster editor load — with TypeScript 7.0 as the shipping target.
TypeScript’s value compounds with codebase size — rename with confidence, find-all-references, instant go-to-definition. But for the largest projects, those operations had become slow enough that developers were choosing between a responsive editor and a complete view of their code. That’s the problem a native port sets out to solve.
Source
By: Anders Hejlsberg, Microsoft
Published: Mar 11 2025
Type: Engineering article
Saved because this announces a structural change to TypeScript’s implementation — not a type-system improvement but a full native rewrite — with benchmark numbers and a versioning roadmap worth understanding well before TypeScript 7 ships.
Why porting the TypeScript compiler to Go is the right move
TypeScript has always had a performance ceiling. Running on Node.js, the compiler and language service carry every JavaScript runtime cost: garbage collection pauses, single-threaded execution, and the overhead that comes from building a type checker in an interpreted language. For small and medium projects this is invisible. For the VS Code codebase — 1.5 million lines — it meant 77.8 seconds to run tsc and 9.6 seconds before the first keystroke in an editor after opening the project. For AI development tooling, which depends on large semantic windows and tight latency constraints, the current implementation was structurally incompatible with what the ecosystem needed next.
The decision was a port rather than a rewrite. That distinction matters. Porting means translating the existing codebase structure into Go while preserving logic and behavior. Rewriting would mean redesigning the type checker from scratch, introducing unknown behavioral differences and a years-long compatibility gap. Porting trades implementation novelty for correctness guarantees: if the structure matches and the tests pass, the behavior matches. Go was chosen for native compilation speed, a straightforward concurrency model, and a type system structured enough to translate TypeScript’s original codebase without architectural friction.
Anders Hejlsberg leads with numbers consistent enough to call representative. Running tsc on the VS Code codebase drops from 77.8 seconds to 7.5 seconds — a 10.4x improvement. The pattern holds across project sizes: Playwright (11.1s → 1.1s, 10.1x), TypeORM (17.5s → 1.3s, 13.5x), date-fns (6.5s → 0.7s, 9.5x), tRPC at 18,000 lines (5.5s → 0.6s, 9.1x). The smallest project, rxjs at 2,100 lines, shows an 11x improvement — which suggests the overhead reduction is real even where total build time is already small.
Editor performance gets specific treatment, and it’s where most developer time lives. Loading the VS Code project in the editor goes from 9.6 seconds to 1.2 seconds: an 8x improvement in project load time. Every subsequent operation — completion lists, quick info, go-to-definition, find-all-references — is expected to see proportional gains. Memory usage also appears to be roughly half of the current implementation, though the post notes that memory optimization hasn’t been actively investigated yet, so that figure is probably a floor rather than a ceiling.
The language service is also moving to LSP — the Language Server Protocol — a standard communications interface that most modern editors already speak natively. This is flagged as a longstanding infrastructural work item. Practically, it means TypeScript’s language features stop needing custom glue code per editor. Any LSP-compliant editor gets the full service from the same implementation.
The versioning roadmap is the part most worth tracking. TypeScript 5.8 was the latest release at announcement, with 5.9 incoming. The JS codebase continues through the 6.x series, with TypeScript 6.0 introducing deprecations that align the JS implementation with the incoming native one. When the native codebase reaches sufficient parity — covering command-line typechecking, project builds, and the language service — it ships as TypeScript 7.0. Both lines will exist in parallel: TypeScript 6 for teams depending on compiler API surface or legacy configurations, TypeScript 7 for teams that can move. The team’s stated goal is to keep the two versions as closely aligned as possible so the upgrade stays low-friction.
The working Go repository was already capable of loading popular TypeScript projects — including the TypeScript compiler itself — when the announcement was made, and it was published under the same license as the existing TypeScript codebase. The capabilities that the speed unlocks are worth naming: instant project-wide error listings, more advanced refactorings, deeper code insights too expensive to compute at JS speeds, and tighter integration with AI tooling that needs semantic context with tight latency requirements. Those aren’t promises for TypeScript 7.0 specifically — they’re the design space that 10x faster compute opens up.
My take
What this signals is that TypeScript’s bottleneck had become the runtime, not the type theory. The type system has been sophisticated for years; it was the interpreter overhead and single-threaded execution that made large-project tooling feel sluggish. Porting to natively compiled Go with real concurrency is the right lever because it requires no user-visible behavioral changes. The benchmark consistency across projects of wildly different sizes — from 2,100 lines to 1.5 million — is the most credible part of the announcement. A speedup that only showed up on massive codebases would be a niche win. One that holds at every scale changes the everyday TypeScript experience for almost everyone.
The TypeScript 6.x deprecations as preparation for TypeScript 7 are worth watching closely. Cleaning up legacy flags before the native release keeps the two implementations aligned without requiring the Go port to replicate outdated behavior. The safe path is to upgrade to TypeScript 6 and fix deprecations now, before TypeScript 7 turns them into hard errors.
Where this is useful
- When evaluating TypeScript investment for a large monorepo — this sets the floor for TypeScript’s performance trajectory heading into the native era.
- When deciding between build-time and editor-only type checking — the 10x speedup makes full
tscruns on every save viable where they previously weren’t. - When tracking LSP adoption across tooling — TypeScript moving to LSP removes a category of custom editor integrations that currently need per-editor maintenance.
- Less directly applicable if your workflow involves small TypeScript codebases; the gains are real at every scale but most felt at the large end.
Apply this: Run
tscon your codebase now and record the time. That’s your TypeScript 6 baseline — the number you’ll compare against when TypeScript 7 is ready to install.
What I want to remember
Remember: Port, don’t rewrite. Translating the existing compiler structure into Go preserves behavioral consistency while gaining native performance — the hard part of a type checker is getting the semantics right, and that work was already done in the original codebase.