By ByteBot
Microsoft announced major progress on TypeScript 7 on December 2, revealing a native compiler rewrite in Go that delivers 8-10x faster build times. The VSCode codebase (1.5 million lines) now compiles in 8.74 seconds instead of 89—a 10.2x speedup. This announcement comes at a strategic moment: TypeScript just became GitHub’s #1 language in August 2025, overtaking Python with 2.6 million monthly contributors. Microsoft is fixing TypeScript’s biggest complaint—slow compilation on large codebases—exactly when it matters most.
You can test TypeScript 7 today via @typescript/native-preview on npm, with stable release targeting early 2026.
The Performance Revolution: 10x Isn’t Marketing Hype
TypeScript 7’s native compiler (tsgo) achieves 8-10x faster compilation across real-world projects. Microsoft’s official benchmarks show dramatic improvements:
| Project | TypeScript 6.0 | TypeScript 7.0 | Speedup |
|---|---|---|---|
| VSCode | 89.11s | 8.74s | 10.2x |
| Sentry | 133.08s | 16.25s | 8.19x |
| TypeORM | 15.80s | 1.06s | 9.88x |
| Playwright | 9.30s | 1.24s | 7.51x |
These aren’t cherry-picked examples—they’re major open-source projects with millions of lines of TypeScript code. The performance gain comes from three architectural changes: native compilation to machine code (no JavaScript VM overhead), Go’s shared-memory parallelism enabling concurrent type-checking across files, and a rearchitected language service optimized for throughput.
For large monorepos and enterprise codebases, this cuts CI/CD build times from hours to minutes. Developers working on million-line projects get instant feedback instead of waiting through coffee breaks. The difference between a 90-second build and a 9-second build isn’t incremental—it fundamentally changes your workflow.
Why Go? Following esbuild’s Proven Pattern
Microsoft chose Go over Rust, C#, or staying with JavaScript/TypeScript for pragmatic reasons. The TypeScript compiler is functional (functions + data structures), matching Go’s style better than C#’s object-oriented approach. Go provides garbage collection, which the TypeScript compiler relies on heavily—Rust’s manual memory management would require significant rearchitecting. Most importantly, esbuild already proved this pattern works: the Go-based bundler achieves 10-100x speedups for JavaScript bundling.
The decision prioritized speed to market over theoretical perfection. As the TypeScript team explained on GitHub: “This was not a green field—it’s a port of an existing codebase with 100 man-years of investment.” Go’s goroutines enable parallel type-checking, garbage collection avoids memory management complexity, and the language’s syntax aligns with TypeScript’s existing architecture.
The community reacted with mixed sentiment on Hacker News (192 points, 117 comments). Some developers questioned why not Rust for maximum performance or C# as Microsoft’s own language. Others pointed to esbuild’s success as validation. The answer: Microsoft chose pragmatism over purity, betting on Go’s proven track record for developer tooling.
What Works Now (and What Doesn’t)
TypeScript 7’s type-checking is “very nearly complete” with “extremely high compatibility,” and Microsoft says it’s “safe” to use for build validation today. Editor features work: auto-imports, find-references, rename, hover tooltips. Incremental builds and project references are fully functional.
However, critical gaps remain. The JavaScript emit pipeline is incomplete, decorators aren’t supported yet, and the minimum target is es2021 (no ES5 downleveling). The compiler uses the LSP protocol instead of TSServer, breaking custom integrations that haven’t migrated.
Here’s the practical status:
- Working: Full type-checking (production-ready), editor integration (VS Code extension available), incremental builds & project references, watch mode
- Not Ready: JavaScript emit (incomplete—use tsc 6.0 for compilation), decorators (not supported yet), ES5 target (es2021 minimum), TSServer protocol (migrated to LSP)
This is beta software masquerading as production-ready. Use TypeScript 7 for CI validation and type-checking right now, but keep tsc 6.0 for actual compilation. Decorator-heavy codebases (Angular, NestJS) need to wait for stable release. You’ll run two compilers until TypeScript 7.0 lands: tsgo for validation speed, tsc for complete feature support.
Timeline and How to Test Today
Microsoft targets early 2026 for two releases: TypeScript 6.0 (bridge release with deprecations) and TypeScript 7.0 (stable native compiler). TypeScript 6.0 introduces breaking changes to align with 7.0: strict mode defaults to enabled, target defaults to latest ECMAScript, and ES5 support is removed entirely.
Testing the preview is straightforward:
# Install TypeScript 7 preview
npm install -D @typescript/native-preview
# Drop-in replacement for tsc
tsgo src/**/*.ts
# Type-check only (recommended for now)
tsgo --noEmit
# Project references & incremental builds
tsgo --buildThe VS Code extension “TypeScript Native Preview” updates daily with the latest compiler changes. This lets you switch between compilers without changing code.
The migration path is three phases: test now with the preview, prepare in early 2026 when TypeScript 6.0 lands with deprecations, and migrate mid-2026 when TypeScript 7.0 hits stable. Early testing helps catch breaking changes before they reach production. The @typescript/native-preview package receives daily updates—pin versions if using in CI to avoid surprise breakages.
Ecosystem Impact: Short-Term Pain for Long-Term Gain
The performance gains come with ecosystem disruption. Tools built on the TSServer protocol need to migrate to LSP. Custom integrations may break. Linters, formatters, and bundlers require updates for full compatibility.
The Hacker News discussion reveals the divide. Some developers embrace the speedup: “TS is the only mainstream language that lets you express pretty much everything in the typesystem.” Others worry about migration fatigue: “I’m not looking forward to yet another round of refactoring for all of the linters, formatters, bundlers.”
A few skeptics question TypeScript’s long-term future entirely, comparing it to Dart’s runtime type safety and hot reload capabilities. But with 2.6 million GitHub contributors and 77.9% year-over-year growth in AI-tagged projects, TypeScript isn’t going anywhere.
The TypeScript team chose to rip off the band-aid with a clean break rather than maintain dual protocols forever. For most developers, this trade-off is worth it. For teams with heavy tooling customization, the migration will sting—but the alternative is years of slow builds while competitors move faster.
Key Takeaways
Microsoft’s TypeScript 7 delivers on the promise of dramatic performance improvements, with real benchmarks showing 8-10x faster compilation times. The Go rewrite follows the proven esbuild pattern and targets stable release in early 2026.
Start testing now via @typescript/native-preview for CI validation, but wait for TypeScript 7.0 stable before switching production builds. The ecosystem needs time to migrate to LSP, and decorator support isn’t ready yet. TypeScript 6.0 will land first as a bridge release, introducing deprecations to smooth the transition.
The short-term disruption is real—tooling updates, breaking changes, and ecosystem churn. But the long-term payoff is clear: instant feedback for developers, faster CI/CD pipelines, and a compiler architecture built for the next decade of TypeScript growth.
