TypeScript’s Native Compiler: 10× Faster Web Builds

TypeScript has become the backbone of modern web development, but its power has always come with a cost: slow builds and sluggish editor startup on large projects. As codebases cross the million-line mark and monorepos span dozens of apps, waiting tens of seconds for type checks or a language service to warm up has become a serious productivity tax.

Microsoft’s answer is a native compiler, internally codenamed Project “Corsa”, which promises around 10× faster web builds without changing how TypeScript looks or behaves. Instead of a radical language redesign, the team is porting the existing compiler and tools from TypeScript/JavaScript to Go, targeting a feature-complete release as TypeScript 7. If the early benchmarks hold, the combination of native type-checking and modern bundlers could change what developers expect from their feedback loop.

What is TypeScript’s Native Compiler and Why Now?

The native TypeScript compiler is not a new language or a new type system, it is a reimplementation of the current compiler in Go. Today’s TypeScript toolchain is self-hosted: the compiler, language service, and related tools are written in TypeScript/JavaScript and run on Node.js. Project Corsa takes that implementation and systematically ports it to Go, exposing mostly the same CLI surface area and configuration options under a new binary, often referred to as tsgo in previews.

Microsoft’s TypeScript team is clear that this is a port, not a clean-sheet rewrite. They explicitly call out Hyrum’s Law: over a decade, countless projects have come to rely on obscure edge cases, subtle behavior, and even historical bugs in the TypeScript compiler. A greenfield implementation that merely “matches the spec” would break far too many real-world builds. The native project instead aims for behavioral parity so that existing codebases can migrate without surprises.

The motivation for moving off the JS-based compiler is largely about performance and scalability. Node is excellent for developer tooling, but a highly concurrent, optimized native implementation can do more work per second and dramatically reduce memory over. With modern web apps pushing the limits of type systems, heavy generics, complex JSX trees, large monorepos, the team saw a need for a fundamentally faster foundation that could power both everyday type checks and more advanced static analysis.

10× Faster Type Checking: The Benchmarks That Matter

Microsoft’s own benchmarks on real-world TypeScript codebases illustrate just how dramatic the native compiler’s speed-up can be. Measuring the time to run tsc on large projects, the Go-based implementation shows around an order-of-magnitude improvement versus today’s JS compiler. On the Visual Studio Code repository, roughly 1.5 million lines of TypeScript, build times dropped from 77.8 seconds to 7.5 seconds, a 10.4× speed-up for a full type check.

The effect is consistent across a variety of popular open source projects. Playwright, at around 356,000 lines of code, goes from 11.1 seconds to 1.1 seconds (10.1×). TypeORM’s compile time falls from 17.5 seconds to 1.3 seconds (13.5×). Even smaller libraries see similar gains: date-fns from 6.5 seconds to 0.7 seconds (9.5×), tRPC from 5.5 seconds to 0.6 seconds (9.1×), and RxJS from 1.1 seconds to 0.1 seconds (11×). These numbers are cold builds, exactly the kind of type-check you trigger in CI or on a fresh clone of a repository.

Those line figures translate directly into faster web builds on real teams. Continuous integration pipelines that previously spent a full minute on TypeScript type-checks can often complete in under ten seconds. Local pre-commit hooks become far less intrusive, and “run tsc --noEmit before pushing” starts to sound like a reasonable default rather than an aspirational guideline. For large React or Node monorepos that treat TypeScript as a gatekeeper in every pipeline, shaving tens of seconds off each run compounds into hours saved per week.

Faster Editors and Richer Tooling for Web Developers

Beyond raw CLI performance, one of Microsoft’s key goals with the native compiler is to “drastically improve editor startup.” The same engine that powers the command-line type checker also underpins the language service in editors like VS Code. When that engine becomes dramatically faster and more memory-efficient, projects load more quickly, autocomplete and error reporting feel snappier, and the overall editing experience becomes less constrained by project size.

Anders Hejlsberg, TypeScript’s lead architect, describes the native port as enabling “instant, comprehensive error listings across an entire project” and “more advanced refactorings” that are currently too expensive to compute. With an order-of-magnitude reduction in analysis time, the language service can afford to run deeper checks, suggest smarter fixes, and respond to more complex queries without freezing the editor. That is especially relevant in JSX-heavy front-end apps where small edits can ripple through large component trees.

The TypeScript team also calls out memory reductions as a design goal. Native Go code with tightly controlled data structures and concurrency models can manage large symbol graphs and ASTs more efficiently than a Node-based runtime. For developers, this can mean fewer out-of-memory errors on massive solutions, smoother multitasking with other tools, and the possibility of running more analysis passes in the background without bogging down the machine. In combination, these improvements unlock a new ceiling for how big a TypeScript web codebase can feel “comfortable” inside an editor.

How to Try TypeScript Native Today

While the native compiler is not yet the default, Microsoft has already made previews broadly available so teams can experiment and provide feedback. On the CLI side, you can install the Go-based compiler as an npm package under the name @typescript/native-preview. This package exposes a tsgo-style binary designed to closely mirror the existing tsc interface and flag set, making it relatively easy to drop into an existing project’s scripts or CI pipeline for testing.

For editor integration, there is a dedicated VS Code extension called “TypeScript (Native Preview)”. Installing this extension wires the native language service into VS Code alongside or in place of the standard JavaScript-based service. You can then open familiar projects and directly compare project-load times, responsiveness of IntelliSense, and the speed at which errors and diagnostics appear as you type.

It is important to understand that the preview is still incomplete. According to Microsoft and community coverage, current limitations include missing declaration file emit, partial support for --build and project references, and incomplete support for some downlevel emit targets. Incremental builds are also still being fleshed out, and the team has not yet published formal benchmarks for incremental scenarios. As a result, the preview is best used today for experimentation, performance evaluation, and feedback, not as the sole compiler for critical production pipelines.

Limitations, Timelines, and the Path to TypeScript 7

Project Corsa follows a phased roadmap that extends into 2026. Microsoft’s announcements in early and mid-2025 outlined a plan: preview CLI type-checking in 2025, move toward feature-complete project builds and a full language service by the end of the year, and ultimately ship the native compiler as part of TypeScript 7 once parity and stability are achieved. Community reporting points to early 2026 as the target window for that stable TypeScript 7 release.

Until parity is reached, the existing JavaScript-based compiler will continue as the TypeScript 6.x line. This ensures that teams have a stable, fully featured toolchain while the native version matures. For many organizations, the migration path will likely be gradual: first running tsgo in parallel with tsc for type-check-only jobs, then adopting the native language service in editors, and only later flipping core build systems to rely on the new compiler when project references, declaration emit, and incremental modes are production-ready.

Some of the most important missing features today revolve around incremental behavior. InfoQ and other sources note that, while cold builds show spectacular gains, Microsoft has not yet published detailed numbers for incremental rebuild performance. Since many front-end workflows rely on rapid incremental feedback, especially in watch modes or during hot module replacement, the developer experience story is not complete until those incremental scenarios are implemented and benchmarked. The coming releases will likely focus heavily on closing those gaps.

Why Go, and Not Rust or C++?

One of the more debated design choices in the community is Microsoft’s decision to port TypeScript to Go rather than Rust, C, or C++. At first glance, Rust’s performance and safety guarantees or C++’s maturity for compilers might seem like natural fits. However, the TypeScript team evaluated several options and ultimately favored Go for a mix of performance, concurrency, tooling, and development velocity.

Go offers a strong concurrency model, good baseline performance, and a relatively simple language that enables a large team to move quickly. For a project like TypeScript, which evolves rapidly and underpins an enormous ecosystem, iteration speed and maintainability are just as critical as raw throughput. Go’s tooling ecosystem, fast builds, built-in formatting and tooling, straightforward cross-compilation, also lowers friction in daily development and distribution.

The team’s goal is “near-system-level efficiency without sacrificing developer velocity.” Go hits that sweet spot: it is significantly closer to the metal than a JavaScript runtime, but without the complex ownership and lifetime semantics of Rust or the sharp edges of C and C++. That makes it easier for a broad set of contributors to work on the compiler, while still extracting substantial performance gains over the existing self-hosted implementation.

Compatibility, Migration, and Hyrum’s Law

Any change to a language’s core compiler raises understandable concerns about compatibility. The TypeScript team has been explicit that preserving existing behavior is non-negotiable. By framing Corsa as a port, not a rewrite, they set the expectation that the new compiler should behave the same as today’s tsc for all supported configurations, including quirky edge cases and historical decisions that the community now depends on.

In practice, this commitment shows up in several ways. The JS-based compiler lives on as the 6.x line while 7.x stabilizes. The new CLI is designed as a near drop-in replacement, mirroring the existing flag surface so build scripts and tooling integrations do not require rewrites. The team also cites Hyrum’s Law to justify painstaking efforts to match even undocumented behavior: with millions of users, any observable behavior, intended or not, has probably become a de facto contract for someone’s build somewhere.

At the same time, the native compiler exposes new integration options. Beyond CLI parity, the project is adding APIs for language server protocols, a native Node module, and a synchronization layer (such as libsyncrpc) to enable faster and richer language tooling. These additions are designed so that existing configs and syntax remain intact while new capabilities, like more advanced refactorings or deeper project-wide analysis, come online for editors, IDEs, and external tools.

End-to-End Faster Web Builds: TypeScript + Native Bundlers

The native TypeScript compiler does not exist in isolation; it arrives in an ecosystem that is already pushing hard toward native-speed build tools. Modern bundlers and dev servers written in Rust and Go are challenging older JavaScript-based pipelines, often delivering significant improvements in both cold builds and hot-reload responsiveness. Community projects like the Rust-based bundler “Kona” report being notably faster than even esbuild on large React/TypeScript projects.

When you pair a 10× faster type checker with a native bundler, the end-to-end build story for web apps changes. A typical pipeline, type-check with tsc, transpile, bundle, and run tests, has historically seen TypeScript as one of its costliest stages. With the native compiler, that stage may shrink to a small fraction of total build time. Combined with Rust- or Go-based bundlers that also boast accelerated rebuilds and hot module replacement, entire feedback loops, from a commit pushed to CI, to a local storybook refresh, can compress dramatically.

This has real organizational implications. Faster builds reduce CI timeouts and infrastructure costs, making it more feasible to run stricter checks on each change. Cross-project refactors that once seemed too risky because they would stall pipelines can become routine. For large JavaScript/TypeScript monorepos, where dozens of teams share a single dependency graph, shaving tens of seconds from each gated run can add up to meaningful productivity gains and smoother collaboration.

The emergence of a native TypeScript compiler is more than an engineering curiosity, it is a reset of expectations for how fast type safety can be. With order-of-magnitude improvements in CLI compile times and editor startup, Project Corsa promises to turn the TypeScript compiler from a bottleneck into an enabler. When your type-check finishes in a second instead of ten, you can afford to run more checks, ship more ambitious refactors, and lean harder on tooling to keep sprawling web codebases healthy.

There is still work a: incremental builds, full project references, and complete emit paths must reach parity before TypeScript 7 can become the default everywhere. But even in preview, the direction is clear. As the Go-native compiler matures and pairs with fast native bundlers, the web ecosystem is moving toward a world where rich static analysis, large-scale TypeScript adoption, and rapid feedback loops coexist comfortably, no longer forcing teams to choose between safety and speed.