TypeScript Devours JavaScript as Runtimes Battle Over Speed

When Microsoft shipped the TypeScript 7.0 beta in April 2026, it did something the language team had publicly resisted for years: it rewrote the compiler in Go. The result, according to the release notes covered by heise online, is a compiler that runs "ten times faster than its predecessor", a claim that lands differently when you remember the predecessor was written in TypeScript itself, a recursive tribute to the project's bootstrapping ethos that had, by 2025, become its single largest bottleneck.

The speedup is not a marginal improvement. A tenfold reduction in compile time for a codebase of any real size turns type-checking from a background tax into something that feels instantaneous. But the rewrite also raises a question the TypeScript community has been circling since 2023: if the compiler needs to be rewritten in a systems language to keep up, what does that say about the runtime that ultimately executes the JavaScript it produces? Three different runtimes, Node, Bun, and Deno, have arrived at three different answers to that question, and the divergence is now the most consequential technical argument in the JavaScript ecosystem.

The through-line across all three is type stripping. In January 2026, InfoWorld's Matthew Tyson reported on a shift that had been gathering momentum across runtimes: "By treating types as whitespace, modern runtimes are unlocking a 'no-build' TypeScript that keeps stack traces accurate and workflows clean." The idea is deceptively simple. Instead of requiring a separate compilation step that transpiles TypeScript into JavaScript before execution, the runtime strips the type annotations on the fly and runs the resulting JavaScript directly. No source maps, no intermediate files, no mismatch between what you wrote and what the debugger shows.

But the three runtimes implement this vision with very different philosophies. Node.js, stewarded by the OpenJS Foundation and still the default choice for server-side JavaScript at most enterprises, added experimental type stripping via the --experimental-strip-types flag. The approach is conservative: strip the types, run what remains, and leave full type-checking to the dedicated tsc compiler in CI. Node's maintainers have been explicit that they are not building a type checker into the runtime. They are building a loader that knows how to ignore the parts of a .ts file that are not JavaScript.

Bun, the Zig-written runtime created by Jarred Sumner and developed by Oven, took the opposite approach from its first public release. TypeScript is a first-class input format, transpiled internally by Bun's bundler and executed with no configuration. The pitch is speed and simplicity: bun run index.ts just works. Bun also bakes in a test runner, a package manager, and a bundler, an integrated toolkit that recalls the Go toolchain's "one binary does everything" philosophy. The trade is that Bun's transpiler is fast but not fully spec-compliant with every edge case in TypeScript's type system, which means some valid TypeScript patterns will fail silently at runtime in Bun even if tsc accepts them.

Deno, created by Node's original architect Ryan Dahl, sits between the two poles. Deno treats TypeScript as its default language and type-checks code at runtime using the official TypeScript compiler, cached aggressively to mitigate the performance hit. It is the only runtime that actually verifies types during execution rather than silently stripping them. This has always been Deno's bet: that correctness is worth the slower startup, and that Web-standard APIs plus first-class TypeScript would attract developers tired of configuring Node.

The State of JavaScript 2025 survey, covered by InfoQ in March 2026, showed TypeScript cementing its dominance: over 70 percent of respondents reported using it as their primary language for new projects, and satisfaction scores remained among the highest in the survey's history. But the runtime satisfaction data told a more complicated story. Node held its majority share, Bun's satisfaction ratings climbed sharply among developers who had adopted it, and Deno's numbers plateaued, strong among a niche, flat everywhere else. The fragmentation was not just technical; it had become demographic.

Then there is the security story nobody saw coming. In March 2026, Bleeping Computer reported that the LeakNet ransomware gang had begun using the ClickFix technique for initial access into corporate environments and was deploying a malware loader "based on the open-source Deno runtime for JavaScript and TypeScript." Attackers had discovered what Deno's designers intended as a feature: a single self-contained binary that can fetch and execute TypeScript from anywhere, with built-in permissions that are permissive enough by default to give a loader everything it needs.

The LeakNet story is not an indictment of Deno's security model, any runtime that can execute network-fetched code is a potential vector, but it is a reminder that runtime diversity has a dark side. When every runtime implements TypeScript execution slightly differently, and when one of those runtimes ships as a compact, dependency-free binary, the operational security surface of an organization becomes harder to reason about. A Deno binary dropped on a server does not announce itself the way a Node installation does. It does not leave traces in the usual places.

The Go compiler rewrite for TypeScript 7, meanwhile, is reordering the economics of the entire toolchain. Visual Studio Magazine reported in October 2025 that Microsoft had brought the Go-based native compiler to Visual Studio 2026 Insiders, describing "up to 10x performance gains and a dual-track roadmap alongside the current JavaScript-based compiler." The dual-track strategy is crucial: the JavaScript compiler remains the reference implementation, guaranteeing correctness, while the Go compiler delivers speed. But it also means the TypeScript team is now maintaining two compilers in two languages, a maintenance burden that will be felt most acutely when language features land in one track before the other.

By treating types as whitespace, modern runtimes are unlocking a 'no-build' TypeScript that keeps stack traces accurate and workflows clean., Matthew Tyson, InfoWorld, January 2026

What Tyson's line captures is the end state the ecosystem is converging toward, even if the runtimes are taking different roads to get there. The "no-build" dream, write TypeScript, run TypeScript, never configure a bundler, was fringe five years ago. Now it is the baseline expectation for every new runtime. Even Node, the most conservative of the three, has acknowledged that a build step represents friction, and friction is what drives developers toward competitors.

The question that hangs over this convergence is whether type stripping is actually enough. Stripping types at runtime makes the developer loop faster, but it also means a whole category of errors, the ones TypeScript was designed to catch, will not surface until CI runs the real compiler, or worse, until production. Deno's choice to actually type-check at runtime addresses this, but at a cost that has limited its adoption. Bun's choice to prioritize speed over spec-compliance means some programs behave differently in Bun than they do in Node. Node's choice to defer type-checking entirely offloads the problem onto tooling that every team must configure separately.

The fragmentation is not just about technical tradeoffs. It is about who bears the cost of those tradeoffs. When Bun silently accepts a TypeScript pattern that tsc rejects, the cost falls on the developer who debugs a production incident they cannot reproduce locally. When Deno type-checks at startup and adds two seconds to every invocation, the cost falls on the developer who runs a script fifty times a day. When Node requires a separate build step, the cost falls on every new developer who joins a project and spends their first afternoon configuring a toolchain.

Microsoft's bet with the TypeScript 7 Go compiler is that none of these runtime-level solutions address the root problem: the compiler itself needs to be fast enough that nobody minds running it. A compiler that finishes in under a second on a large codebase changes the calculus. If tsc --noEmit is instantaneous, the runtime does not need to do type-checking at all, the developer can run the compiler as a persistent background process, or a watcher, or a pre-commit hook, and the runtime can focus on running code.

That vision, if it materializes, would make the type-stripping approach of Node and Bun the clear winner and turn Deno's runtime type-checking into an expensive redundancy. But it depends on the Go compiler landing at full parity with the JavaScript reference implementation, shipping as the default, and being fast enough in practice, not just on benchmarks, that developers stop reaching for workarounds. The TypeScript team has not committed to a timeline for making the Go compiler the default, and the dual-track maintenance period could stretch for years.

The LeakNet development complicates this picture from an unexpected direction. If a Go-compiled TypeScript toolchain makes Deno's runtime type-checking obsolete for developer workflows, Deno still has other differentiators: its permissions model, its Web-standard APIs, its single-binary deployment. But one of those differentiators, the single-binary deployment, is exactly what made it attractive to ransomware operators. The same properties that make a runtime easy to deploy legitimately make it easy to deploy maliciously. The runtime ecosystem has largely avoided reckoning with this tension, treating security as a feature checklist rather than an emergent property of design choices.

By mid-2026, the JavaScript runtime landscape looks less like a three-way competition and more like three overlapping visions of what a post-build-step world should look like, each with a different answer to the question of where type safety lives. Node's answer is that it lives in CI, and the runtime should be a dumb pipe. Bun's answer is that it lives in the transpiler, and speed covers a multitude of semantic sins. Deno's answer is that it lives in the runtime, and correctness is worth the wait. TypeScript 7's answer, still in beta but looming, is that it lives in a compiler so fast the question stops mattering.

The realignment is not yet settled. The TypeScript 7 Go compiler must ship as stable, the Node type-stripping implementation must exit experimental, and Bun must close its spec-compliance gaps without sacrificing the speed that earned it attention in the first place. Meanwhile, every organization that deploys JavaScript in production is running a de facto bet on which of these resolutions arrives first, and whether a ransomware group weaponizing an open-source runtime forces the conversation toward security in a way that design manifestos never quite managed to do. Watch for the TypeScript 7 general availability release candidate, expected in the second half of 2026. The runtime that integrates cleanly with a 10x-faster compiler on day one will have an advantage that no amount of manifesto-writing can match.