There is a line in the GitHub Octoverse 2025 report that deserves more attention than it got.
"The most significant language shift in more than a decade."
That is not the assessment of a tech blog making a bold claim. It is GitHub's own characterisation of what happened to their platform in August 2025, when TypeScript overtook Python to become the most-used programming language on GitHub by monthly contributor count. 2,636,006 contributors in a single month. A 66.6% year-over-year surge. More than a million new contributors added in one year.
GitHub has been tracking language usage for years. They had never called anything the most significant shift in more than a decade before.
And then, in the same month TypeScript reached that milestone, Microsoft quietly announced that it was going to rewrite the TypeScript compiler — the engine that powers all of this — in Go.
How TypeScript Won When Nobody Was Looking
The story of TypeScript's rise has a shape that most technology adoption stories don't: it happened through accumulation rather than displacement.
TypeScript launched in 2012 and spent years as what its advocates called "the thing serious teams use." In 2017, 12% of developers used it. In 2022, 34%. In 2025, 48.8% according to the Stack Overflow Developer Survey, with 78% of enterprise teams using it as their primary language. 78% of all software job postings now require it. 40% of JavaScript developers write exclusively in TypeScript.
The mechanism was framework defaults. Angular shipped TypeScript-first in 2016. Vue 3 was rewritten entirely in TypeScript. Next.js scaffolds TypeScript projects by default. SvelteKit, Astro, NestJS, Qwik, Remix — every major JavaScript framework that matters in 2026 ships TypeScript as the default and treats JavaScript as the opt-out. When the path of least resistance changed, the adoption numbers followed.
The AI era accelerated it further. GitHub's Octoverse report found that typed languages directly benefit AI-assisted development: type systems reduce ambiguity and catch LLM errors before production, and a 2025 academic study found 94% of LLM-generated compilation errors were type-check failures. When you are generating code with Copilot or Cursor, TypeScript's type system catches AI mistakes before they reach production in a way that plain JavaScript cannot. The AI coding boom and the TypeScript boom are, in meaningful ways, the same boom.
The Problem That Success Created
Here is the thing about building a compiler that 50 million developers download every week and use in production codebases at Google, Microsoft, Shopify, and every major bank: you cannot break it.
TypeScript's compiler — tsc — was written in TypeScript. For thirteen years, this was a virtue. The team could use their own language, benefit from its type safety, and the compiler served as a proof-of-concept for TypeScript's capabilities. Anders Hejlsberg, the lead architect, described this as one of the language's best features.
It was also, increasingly, its biggest constraint.
Large TypeScript projects take minutes to compile. Watch mode helps. Incremental compilation helps. But the JavaScript runtime that tsc runs on is fundamentally limited in ways that matter at the scale TypeScript now operates. Microsoft's principal product manager Daniel Rosenwasser acknowledged that the JavaScript platform "has consistently brought some challenges, in particular around performance and scalability."
The consequence is visible in developer feedback loops. Patreon spent seven years migrating 11,000 files and over a million lines of code from JavaScript to TypeScript, completing the migration in early 2026. When their migration finished, they had a TypeScript codebase that took considerably longer to compile than their old JavaScript one did. That trade-off is worth it for most teams. It is also a real friction point for teams whose codebases are large and whose engineers run type checks dozens of times a day.
TypeScript 6.0, announced March 20, 2026, delivers genuine improvements — incremental compilation is 40-60% faster, and peak memory consumption drops approximately 25% for large codebases. These are meaningful gains. They are also improvements to an architecture that Microsoft has decided needs to be fundamentally replaced.
Project Corsa: The Compiler Rewrite Nobody Expected
In early 2025, Microsoft announced Project Corsa: a complete rewrite of the TypeScript compiler and language service in Go.
The benchmarks were striking. The VS Code codebase compiles in 7.5 seconds with the Go-based compiler versus 77.8 seconds with the current one. Playwright dropped from 11.1 seconds to 1.1 seconds. Ten times faster is the headline target. The early results suggest that number is achievable.
The choice of Go is interesting. Microsoft could have chosen Rust, which would have aligned with the memory safety narrative and the broader movement of JavaScript tooling toward Rust. They chose Go instead — a language optimised for fast compilation, straightforward concurrency, and developer ergonomics over raw performance. The implication is that the bottleneck they're solving is not memory safety. It is the speed at which the compiler can do parallel type checking across large codebases. Go's concurrency model makes that tractable in a way that a single-threaded JavaScript runtime does not.
TypeScript 6.0 is the last release based on the existing TypeScript/JavaScript codebase. TypeScript 7.0, targeting mid-2026, will use the Go-based compiler and bring planned breaking changes: strict-by-default, ES5 target dropped, AMD/UMD/SystemJS removed, classic Node module resolution removed.
This is a significant architectural break. Not a gradual evolution. A full rewrite, shipped as a major version, with breaking changes. For a language that 50 million developers download weekly and whose ecosystem has been built around specific assumptions about how the compiler behaves, this is a real transition — and not a trivial one to manage.
What the Transition Actually Requires
The gap between "TypeScript 7.0 will be 10x faster" and "my team has migrated to TypeScript 7.0 and is 10x faster" is a gap that every engineering team using TypeScript will navigate on their own timeline.
The breaking changes in TypeScript 7.0 are not random. They clean up technical debt that has accumulated over a decade — legacy module resolution modes, targets that predate ES2015, module formats that modern environments no longer need. For codebases that haven't accumulated that technical debt, migration will be straightforward. For codebases that have, it will require work.
The more interesting dimension is what the Go-based compiler means for the Rust-based tooling ecosystem that has been building in parallel. Biome, Oxc, Rolldown — these projects were built partly to address the speed problems that TypeScript's JavaScript-based architecture created. A native TypeScript compiler that compiles at 10x speed changes the value proposition of some of those tools, though not all of them. Biome's value is not only speed — it's a unified formatter and linter in a single tool. That use case survives a faster TypeScript compiler. A standalone Rust-based TypeScript parser whose primary advantage is speed faces a more complicated future when the official compiler is no longer slow.
The Honest Summary
TypeScript won. Not over JavaScript — JavaScript is still the most-used language by total developer count, still the foundation that TypeScript builds on, still the runtime everything compiles to. TypeScript won the argument about how serious teams should write JavaScript. That argument is effectively over.
"TypeScript has won. Not as a bundler, but as a language," as Nuxt core team leader Daniel Roe put it.
What comes next is harder than winning. Managing an ecosystem of 50 million users through a compiler rewrite, holding framework defaults and tooling compatibility together while making fundamental architectural changes — this is the work that follows victory. It doesn't generate the same headlines. It is more important.
TypeScript 7.0 and Project Corsa are Microsoft's answer to the question of whether a language that won by moving fast can keep moving fast at the scale it now operates. The benchmarks suggest the answer is yes. The migration experience of the developer community over the next eighteen months will tell you whether those benchmarks survive contact with real codebases.
