10x faster with TypeScript's Project Corsa

Microsoft is embarking on a bold new journey to reshape the TypeScript ecosystem. By porting the native type checker from its current JavaScript implementation to Go, the TypeScript team is addressing long-standing performance challenges (especially in large codebases). For developers, this means much faster builds, improved editor responsiveness, and a significantly better development experience.
Table of Contents
- What is Project Corsa?
- Why Go?
- Performance by the Numbers
- The Roadmap
- What This Means for Frontend Developers
- Final Thoughts
What is Project Corsa?
Project Corsa is Microsoft’s internal initiative to rearchitect TypeScript’s type checker for better efficiency and performance. The project originated as a response to growing frustrations from developers working with massive TypeScript codebases, where type checking can become a bottleneck.
The current TypeScript compiler is built in JavaScript (running on Node.js), which, while convenient for adoption, struggles with:
- Slow performance in large projects due to single-threaded execution.
- High memory consumption, making complex builds inefficient.
- Editor lag in Visual Studio Code and other IDEs when dealing with real-time type checking.
To solve this, Project Corsa is introducing a native implementation in Go that will supercharge TypeScript development.
Why Go?
Switching the implementation language from JavaScript to Go brings several advantages:
- Built-in Concurrency: Go’s lightweight goroutines allow the type checker to leverage multiple cores, reducing overall processing time.
- Efficient Memory Management: Go’s garbage collection and control over data structure layouts lead to lower memory overhead.
- Smooth Porting: With a coding style that mirrors many JavaScript patterns, Go offers a relatively straightforward path for a line-by-line port of the existing compiler without a complete rewrite.
For more details, check out the Microsoft Developer Blogs and explore the microsoft/typescript-go GitHub repository.
Performance by the Numbers
Early benchmarks reveal impressive improvements across several well-known projects. The table below compares the current performance with the new Go-based implementation:
Codebase | LOC | Current Time (s) | Native Time (s) | Speedup |
---|---|---|---|---|
VS Code | 1,505,000 | 77.8 | 7.5 | 10.4× |
Playwright | 356,000 | 11.1 | 1.1 | 10.1× |
TypeORM | 270,000 | 17.5 | 1.3 | 13.5× |
date-fns | 104,000 | 6.5 | 0.7 | 9.5× |
tRPC (server + client) | 18,000 | 5.5 | 0.6 | 9.1× |
rxjs (observable) | 2,100 | 1.1 | 0.1 | 11.0× |
Source: Microsoft Developer Blogs, Neowin
The Roadmap
Microsoft plans to unveil a preview of the new Go-based TypeScript compiler by mid‑2025, with a fully featured language service (integrated into editors like Visual Studio Code) expected by the end of the year. In the meantime, the current JavaScript-based version will continue to evolve as part of the 6.x series, ensuring smooth transitions for existing projects.
What This Means for Frontend Developers
As a frontend engineer, I know firsthand the frustration of waiting for type errors to surface (most frequently in large projects). Faster type checking translates into:
- Instant Feedback: Immediate error diagnostics help maintain a fluid, uninterrupted coding experience.
- Rapid Iteration: With build times slashed, tweaking UI components and experimenting with new ideas becomes a breeze.
- Improved Productivity: Less time spent waiting means more time focusing on creating compelling, high-quality interfaces.
This upgrade is not merely a technical improvement, but a significant boost to our daily workflow, allowing us to spend more time solving problems and less time watching progress bars.
Final Thoughts
The decision to port TypeScript’s type checker to Go is a transformative move that promises to redefine our development experience. I’m excited about the prospect of faster, more responsive tooling that keeps pace with our creative process. This change is about empowering developers to iterate quickly, experiment, and build better applications with less friction. I can’t wait to see how these improvements will make our everyday coding more efficient and enjoyable.
Sources: