Table of Contents
- Introduction
- Putting the 10x Claim Into Perspective
- How Did We Get Here?
- A Port, Not a Simple Translation
- Where Does the Performance Come From?
- Memory Efficiency and Larger Projects
- The Benchmarks
- The JavaScript API Trade Off
- Is It Still TypeScript?
- Large Companies Helped Test TypeScript 7
- Should You Upgrade?
- Final Thoughts
Introduction
At the end of March 2025, I published this article:
At the time, Microsoft's decision to port the TypeScript compiler to Go sparked quite a bit of discussion and controversy. Many people questioned whether moving such a critical piece of the ecosystem away from TypeScript was the right choice.
And boy, did Microsoft deliver what it promised: an order-of-magnitude performance improvement on some of the world's largest TypeScript codebases.
The results are here, and the benchmarks speak for themselves.
Putting the 10x Claim Into Perspective
The phrase "10x faster" describes the scale of the improvement Microsoft has demonstrated. It does not guarantee that every codebase will become exactly ten times faster.
The results depend on the size of the project, the work being performed, and the available hardware. Some projects might see a 5x improvement, while others could reach 8x, 10x, 12x, or potentially even more.
No, this doesn't make every TypeScript developer a 10x developer, But it does mean that compiling a TypeScript project, loading it in an editor, and receiving diagnostics could become dramatically faster after moving to the native toolchain. The word "dramatically" isn't an exaggeration at all in this context.
But hold on, there are still some important caveats. So before you open your editor and start upgrading an enterprise application to TypeScript 7, read this article all the way to the end.
How Did We Get Here?
When I first covered this initiative in 2025, Microsoft had just announced Project Corsa, an effort to port the TypeScript compiler and tooling from TypeScript to native code written in Go.
The announcement immediately triggered the controversy and hot takes:
- Why not Rust?
- Why not C#?
- Is Microsoft abandoning its own technologies? (Yeah, this one is particularly popular among Microsoft haters...)
The real explanation was much less dramatic. This was a pragmatic engineering decision focused on performance, compatibility, and maintainability.
This Was an Extensive Evaluation
The TypeScript team did not select Go after a superficial comparison. It evaluated several languages, built prototypes using different data representations, investigated hybrid architectures, and studied native TypeScript tools such as swc, oxc, and esbuild.
One possible approach was to move only performance-critical components to a native language while leaving the core type-checking algorithms in JavaScript. Ultimately, the team concluded that a complete native port would provide greater benefits.
That does not make Go the universally best language for compiler development. Several languages could have been excellent choices for a ground-up rewrite. Go performed best against the specific requirements of this project.
The Priority Was Compatibility
The most important requirement was not raw performance. It was compatibility.
Microsoft expects the existing and native implementations to coexist for some time. During that period, fixes and features may need to move between both codebases. A language that permits a similar program structure makes that work considerably easier.
A language requiring the team to rethink ownership, mutation, polymorphism, laziness, or fundamental data structures might produce an elegant new compiler, but it would no longer be a straightforward port. Idiomatic Go happens to resemble the function-and-data-oriented style already used throughout the TypeScript compiler.
Why Not Rust?
Rust could have been a strong option for a new compiler designed from the ground up. That, however, was not the team's objective.
The existing compiler relies heavily on automatic memory management and cyclic data structures. Rust's ownership model would have required the team to redesign those structures and rethink significant parts of the implementation. In Anders Hejlsberg's words, rewriting the compiler in Rust might have been possible, but faithfully porting it was not considered practical.
Why Not C#?
C# was also evaluated. This is important because C# is Microsoft's primary language, and Anders Hejlsberg himself is its original designer.
Hejlsberg described C# as a possible contender, but its higher-level, object-oriented model did not align as closely with the existing compiler. The TypeScript codebase follows a more procedural style built around functions and data structures. In fact, its core compiler does not use classes at all.
He also noted that C# did not have a native-code generation story as mature as the alternatives the team was considering. Go, by comparison, had more than a decade of native deployment across all major platforms and closely matched the compiler's existing programming style.
Microsoft did not choose Go because it had stopped trusting C#. It chose the tool that best matched this particular engineering problem.
Why Go Fit the Existing Compiler
Go provides garbage collection, supports cyclic and pointer-heavy data structures, offers control over memory layout and allocation, and enables shared-memory concurrency.
It is also a procedural language built primarily around functions and data structures. Go does not have traditional classes or inheritance, but it supports interfaces, first-class functions, closures, and other patterns used extensively throughout the JavaScript implementation.
TypeScript also performs an unusually large amount of graph processing, including upward and downward traversal through trees of polymorphic nodes. Go supports these patterns while allowing the native implementation to remain recognizably similar to its JavaScript counterpart.
A Port, Not a Simple Translation
Calling this work a simple translation would be misleading.
The team developed tooling to convert some TypeScript syntax into Go, but important structures, including abstract syntax tree nodes, symbols, types, and control-flow data, still required substantial engineering.
Compatibility remains the priority. The native compiler's behavior and output are continuously compared with the existing implementation through approximately 100,000 tests. The goal is to preserve TypeScript's semantics, diagnostics, and years of carefully developed optimizations rather than reinventing the language.
Where Does the Performance Come From?
The widely advertised 10x improvement comes from two major sources: native execution and parallel processing.
Native Execution
Native code removes much of JavaScript's startup, JIT-compilation, allocation, and runtime overhead.
In one demonstration, compiling roughly 250,000 lines took around seven seconds with the existing compiler. The single-threaded native implementation completed the same work in approximately two seconds.
Parallel Processing
Go then allows operations such as parsing, binding, emitting, and parts of type checking to run concurrently. After parallelization was enabled, that same 250,000-line compilation completed in less than one second.
On the much larger Visual Studio Code codebase, approximately 1.5 million lines, the compilation time dropped from more than a minute to around six seconds.
Anders Hejlsberg described the overall gain as roughly half native-code efficiency and half parallelism, although the exact balance naturally depends on the project and available hardware.
Memory Efficiency and Larger Projects
Memory management was another decisive factor in choosing Go.
Go gives the team control over the layout of objects, fields, and allocations without forcing every part of the compiler to manage memory manually. Although Go uses garbage collection, its usual disadvantages are less relevant to TypeScript's workload.
Batch compilations can allocate what they need and terminate before garbage collection becomes a major concern. In long-running processes, structures such as abstract syntax trees often survive for the lifetime of the program, and the compiler has enough domain knowledge to identify sensible moments for collection.
Go's UTF-8 strings, allocation-free substring operations, compact data layouts, and object-pooling techniques further reduce memory pressure. These improvements matter because out-of-memory failures have historically been one of the compiler team's most common categories of reported problems.
The result is not merely a faster compiler. It is a tool capable of processing projects that previously approached or exceeded the practical memory limits of the JavaScript implementation.
The Benchmarks
Microsoft published the following full-build benchmarks in the official TypeScript 7 announcement. Both versions were tested on the same machine, with TypeScript 7 using its default configuration of four type-checker workers.
| Codebase | TypeScript 6 | TypeScript 7 | Speedup |
|---|---|---|---|
| VS Code | 125.7s | 10.6s | 11.9x |
| Sentry | 139.8s | 15.7s | 8.9x |
| Bluesky | 24.3s | 2.8s | 8.7x |
| Playwright | 12.8s | 1.47s | 8.7x |
| tldraw | 11.2s | 1.46s | 7.7x |
The largest relative improvement in this group comes from VS Code, where compilation drops from 125.7 seconds to 10.6 seconds, an 11.9x speedup. Sentry sees the greatest absolute reduction, saving more than two minutes on a single run.
These are not synthetic projects created to make the new compiler look good. They are large, mature codebases containing the complex type relationships, project structures, and dependency graphs that put real pressure on TypeScript.
The results should still be interpreted carefully. They measure TypeScript tooling performance under a particular benchmark environment, they do not mean that the JavaScript produced by TypeScript 7 will execute 10x faster. Results will also vary depending on project configuration, hardware, available CPU cores, and how much of a build pipeline is spent outside the TypeScript compiler.
Memory Usage
| Codebase | TypeScript 6 | TypeScript 7 | Memory Delta |
|---|---|---|---|
| VS Code | 5.2GB | 4.2GB | -18% |
| Sentry | 4.9GB | 4.6GB | -6% |
| Bluesky | 1.8GB | 1.3GB | -26% |
| Playwright | 1.0GB | 0.9GB | -11% |
| tldraw | 0.6GB | 0.5GB | -15% |
The memory improvements are less dramatic than the compilation-time gains, but they are still significant. Bluesky uses 26% less memory, while VS Code drops from 5.2GB to 4.2GB. On developer machines and CI agents running several jobs simultaneously, saving hundreds of megabytes, or even a full gigabyte, can make an important difference.
The variation between projects is also expected. Parallel execution can require additional working memory, while Go's compact data layouts, UTF-8 strings, allocation strategy, and object pooling reduce it. The final result depends on the shape of each codebase and the amount of concurrency being used.
Overall, the improvement is outstanding. I am especially looking forward to using VS Code with the native TypeScript language service. Faster startup, navigation, diagnostics, and type checking should make large projects feel considerably more responsive.
The JavaScript API Trade Off
One area where Go presents a genuine trade-off is JavaScript interoperability.
The existing TypeScript API allows consumers to access and sometimes modify a large amount of compiler state directly inside the same process. That flexibility has also constrained the team's ability to change internal representations and introduce new optimizations.
The native implementation cannot expose Go objects to JavaScript in the same way. For that reason, TypeScript 7.0 does not ship with a compiler API. Microsoft expects TypeScript 7.1 to introduce a new and deliberately designed API rather than reproducing unrestricted access to the old compiler's internal objects.
Applications that depend heavily on the TypeScript compiler API or undocumented internals will need to adapt. Until the new API is available, Microsoft provides the @typescript/typescript6 compatibility package so tools can use the TypeScript 6 API alongside the TypeScript 7 compiler.
Is It Still TypeScript?
Yes. The programming language is still TypeScript, and you will continue writing the same code as before. What runs in the background is completely different, but there is nothing particularly strange or outrageous about that.
As of August 2026, TypeScript 7.0 is stable and available through the standard typescript package. This is still a port rather than a new programming language: developers continue writing the same TypeScript while the machinery behind compilation, diagnostics, and editor tooling has changed.
The F1 Analogy
If you are an F1 nerd like me, you might know that McLaren used Ford-Cosworth engines for much of the period between 1968 and 1983. That partnership helped McLaren win its first Constructors' Championship in 1974, along with Drivers' Championships in 1974 and 1976.
The car was still a McLaren. Its chassis, aerodynamics, controls, strategy, and overall identity belonged to the McLaren team. The engine, the main component that turned all of that engineering into motion, came from Ford because it was the right tool for the job. Not that McLaren couldn't build engines, but Ford's engines were exponentially better for F1 racing.
TypeScript 7 follows a similar idea. The language, syntax, type system, and developer experience remain TypeScript. The engine running underneath them is being replaced because the native Go implementation is significantly better suited to the workload.
This is not a language war, corporate rivalry, or evidence that Microsoft is ditching C# for Go. It is simply an engineering team choosing the right tool for a specific job.
Large Companies Helped Test TypeScript 7
Microsoft did not rely only on its internal test suite. According to the official TypeScript 7 announcement, the team worked with companies including Bloomberg, Canva, Figma, Google, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, and VoidZero. Internal Microsoft teams such as Loop, Office, Power BI, Teams, and Xbox also tested the compiler against their codebases.
This testing exposed TypeScript 7 to complex monorepos, custom build pipelines, unusual module-resolution patterns, and workloads that are difficult to reproduce with isolated test cases.
The results went beyond controlled benchmarks. Slack reduced type-checking time in CI from approximately 7.5 minutes to 1.25 minutes and reported a 40% reduction in merge-queue time. Canva reduced the time required to display the first editor error from around 58 seconds to 4.8 seconds.
That kind of feedback matters because performance is only useful when the compiler remains stable and compatible under real production workloads.
Should You Upgrade?
The short answer is: yes, but treat it as a major-version migration rather than a drop-in performance patch.
TypeScript 7 is now available through the standard typescript package:
npm install --save-dev typescript@7
npx tsc
The --save-dev flag, which can also be written as -D, records TypeScript 7 as a development dependency. Running npx tsc then uses the version installed locally in the project instead of relying on a global installation.
Core features such as parsing, type checking, JavaScript emission, declaration emission, watch mode, incremental compilation, project references, and the language server are production-ready. However, the move to a native implementation still introduces compatibility considerations. TypeScript 7.0 does not ship with a compiler API, adopts TypeScript 6.0's new defaults and hard deprecations, and includes intentional differences in some JSDoc and JavaScript-specific behaviors.
Projects that use TypeScript mainly through tsc will probably have the easiest migration path. Projects that directly import the TypeScript compiler API, depend on undocumented internals, use custom language-service plugins, or rely heavily on legacy JavaScript and JSDoc behavior will need more careful testing or may need to run TypeScript 6 alongside TypeScript 7 temporarily.
A sensible evaluation process is to:
- Run the existing TypeScript 6 build and record its diagnostics, output, execution time, and peak memory usage.
- Upgrade the project to TypeScript 7, run
npx tsc, and compare the results. - Test watch mode, incremental builds, project references, and declaration generation separately.
- Enable TypeScript 7 support in your editor and test navigation, diagnostics, completions, and refactoring workflows.
- Keep the TypeScript 6 compatibility package available for tools that still require the old compiler API.
TypeScript 7 is clearly the future of the ecosystem, but a faster compiler is only valuable when it remains compatible with the workflows built around it. Upgrade deliberately, test the requirements of your actual codebase, and keep compatibility tooling where necessary, not simply because the headline says "10x faster."
Final Thoughts
When Microsoft announced Project Corsa, the 10x performance target sounded extremely ambitious. TypeScript 7 has now turned that promise into measurable results: faster builds, lower memory usage, and a more responsive development experience.
The broader lesson is simple. Technologies are tools, not identities, and good engineering means choosing the right one for the job. TypeScript became faster by no longer being written in TypeScript, and there is nothing wrong with that, quite the contrary.
Enjoyed this deep dive? Let's stay connected!
I share more software engineering insights, projects, and experiments across these platforms:
Top comments (0)