Microsoft Just Shipped the Last TypeScript Written in JavaScript. That's the Whole Point.

The Macro: The Compiled Language That Ate the Web Is About to Eat Itself

Somewhere around 2018, TypeScript stopped being a preference and became an assumption. If you were starting a serious JavaScript project, you were probably starting it in TypeScript. The friction had dropped, the tooling had matured, and the alternative, which was shipping runtime errors you could have caught at compile time, looked increasingly indefensible.

That shift created something interesting. TypeScript isn’t competing with other type systems anymore, at least not directly. It’s competing with its own weight. As codebases scale into the hundreds of thousands of lines, the JavaScript-based compiler becomes the bottleneck. Build times slow. CI pipelines bloat. Engineers start skipping full type checks locally because they don’t have ten minutes.

This is the problem Microsoft is actually solving with the Go rewrite announced earlier this year. According to Visual Studio Magazine, they’re targeting 10x native performance gains with TypeScript 7.0. ByteIota reports the stable native compiler is aimed at early 2026. That number is the headline, and Microsoft knows it.

But the open source software market context matters here too. Multiple market research firms peg the global open source software market somewhere between $21.7 billion in 2023 and projected figures near $55 billion by 2032. That range is wide enough to be suspicious, but the directional consensus is clear. Developer tooling at scale is valuable, and infrastructure that millions of engineers depend on daily has leverage that most enterprise software never achieves.

TypeScript’s real competitors aren’t Go or Rust, though both have typed, compiled stories worth watching. The competition is inertia. The migration path from the JavaScript compiler to the Go compiler is TypeScript 6.0. If that path is rough, adoption of 7.0 stalls. If it’s smooth, Microsoft just quietly completed one of the more ambitious language rewrites in recent memory.

The Micro: One Release to Close the Old World and Open the New One

TypeScript 6.0 is, in the most literal sense, a bridge release. Microsoft has been explicit about that framing. The JavaScript-based compiler lives on through the 6.x series. TypeScript 7.0, the Go-native version, is where the architecture changes. So 6.0’s job is to prepare every codebase that will eventually need to make that jump.

What that looks like in practice: strict mode is now on by default. ESM-first configuration replaces the old CommonJS defaults. The compilation target moves to ES2025. These aren’t minor tweaks. For teams running legacy TypeScript configs, some of this will break things. That’s intentional. The deprecations here are specifically targeting patterns that won’t survive the native port, so the message is clear. Fix it now or get surprised in 7.0.

The additive features are genuinely useful. Built-in types for the Temporal API mean no more installing third-party date-time type packages and hoping they’re current. Map.getOrInsert lands as a standard method. RegExp.escape gets first-class support. None of these are revolutionary in isolation. Together they feel like the language finally catching up to what JavaScript itself has already shipped, which is a reasonable complaint to have had for a while.

The interesting product decision here is the deprecation strategy. Microsoft is essentially using 6.0 to force a cleanup pass across the ecosystem before the architecture switches underneath everyone. It’s a controlled disruption. You can argue about the timeline, and some engineers on LinkedIn apparently are, but the logic is defensible. Better to break things predictably now than chaotically during a compiler rewrite.

It got solid traction on launch day, which tracks. The TypeScript community is large and pays attention to official releases.

For teams already on strict mode and ESM, this upgrade is close to painless. For teams on older configs, the migration guide is going to get some real traffic. If you’re managing a large open source project, the same questions about tooling costs and compatibility that come up with things like AI-assisted coding workflows are going to surface here too.

The Verdict

I think this release does what it needs to do, and that is a more complicated compliment than it sounds.

TypeScript 6.0 isn’t trying to be exciting. It’s trying to be correct. The defaults modernization is overdue. The deprecations are honest about where the language is going. The new API types are genuinely useful rather than performative. This is a release built for the long-term health of the compiler, not for the announcement blog post.

The 30-day question is adoption friction. How many teams run into unexpected breakage from the new defaults and how loudly do they complain? If the migration stories are mostly smooth, 6.0 builds confidence for the 7.0 jump. If they’re messy, Microsoft has a credibility problem going into the most significant compiler change in TypeScript’s history.

At 60 to 90 days, I’d want to see real benchmark data from teams who’ve upgraded large codebases. The 10x performance claim for 7.0 is attributed to Microsoft, and it’s a big number. Whether 6.0 paves that road cleanly or creates new debt is the actual story here.

The bet Microsoft is making is that engineers will accept short-term migration pain for long-term compiler speed. Given that TypeScript already won the adoption war, that bet seems reasonable. The execution still has to land.