Over the last couple of years, we’ve witnessed a remarkable shift in the JavaScript ecosystem, as many popular developer tools have been rewritten in systems programming languages like Rust, Go, and Zig.

This transition has delivered dramatic performance improvements and other innovations that are reshaping how developers build JavaScript-backed applications.

In this article, we’ll explore the driving forces behind this revolution, its implications for the wider ecosystem, and some of the most impactful projects leading the charge.

Why is This JavaScript Tooling Shift Happening?

The shift toward building JavaScript tooling in systems languages is a response to real, mounting pressure in the ecosystem. While JavaScript engines have become remarkably fast over the years, the language itself wasn’t designed for CPU-heavy workloads.

Modern JavaScript applications aren’t just a few scripts anymore — they’re sprawling codebases with thousands of dependencies, complex module graphs, and extensive build pipelines.

JavaScript-based tools that were once "good enough" now struggle to keep up, leading to sluggish build times, laggy editor experiences, and frustratingly slow feedback loops.

That’s where languages like Rust and Go come in. They offer native performance, better memory management, and efficient concurrency — all of which translate into tooling that’s not just faster, but more reliable and scalable.

Rust, in particular, with its seemingly cult-like following, has become the language of choice for much of this new wave. Its growing popularity has inspired a new generation of developers who care deeply about correctness, speed, and user experience. This has created a virtuous cycle where we get more tools and faster innovation.

All of this points to a broader realization in the JavaScript world: if we want tooling that scales with the demands of modern development, we have to look beyond JavaScript itself.

Exploring the New Generation of JavaScript Tools

Let’s look at some of the most influential and promising tools redefining the JavaScript developer experience: SWC, ESBuild, BiomeJS, Oxc, FNM/Volta, and TypeScript in Go.

1. SWC

SWC was among the first major JavaScript tools written in a language other than JavaScript itself (Rust), thus establishing a pattern that many others would follow.

At its core, it provides a high-performance platform for JavaScript/TypeScript transpilation, bundling, minification, and transformation through WebAssembly.

It has been largely successful in its goal of serving as a drop-in replacement for Babel, delivering transpilation speeds up to 20x faster while maintaining broad compatibility with most Babel configurations.

2. ESBuild

At a time when most developer tools were still being written in JavaScript, the idea of using systems languages like Go or Rust was considered more of an experiment than a trend.

But ESBuild changed that. In many ways, it sparked a broader wave of interest in building faster, lower-level tools that could dramatically improve the developer experience.

Created by Evan Wallace (former CTO of Figma), ESBuild was purpose-built to replace legacy bundlers like Webpack and Rollup with a much faster, simpler alternative. It achieves 10–100x faster performance in tasks like bundling, minification, and transpilation due to its Go-backed architecture.

Its speed, minimal configuration, and modern architecture have since influenced a generation of tools and helped shift the expectations around what JavaScript tooling should feel like, and for this reason, it remains the most adopted non-JavaScript tool to date, with over 50 million weekly downloads on NPM.

3. BiomeJS

BiomeJS is an ambitious Rust-based project that combines code formatting and linting into a single high-performance JavaScript toolchain.

Originally a fork of the now defunct Rome project, BiomeJS delivers significant performance improvements over its entrenched predecessors:

• Its formatter is ~25 times faster than Prettier.
• Its linter is over 15 times faster than ESLint.
• It benefits from Rust’s multi-threaded architecture for dramatic speed gains (up to ~100x faster depending on the hardware).

BiomeJS simplifies the development workflow by consolidating these functions into a unified configuration system, eliminating the need to manage separate tools with overlapping functionality.

Though it’s still catching up to its more established counterparts in language support and extensibility, it is an increasingly attractive option for anyone seeking better performance and simpler tooling.

4. Oxc

A newer entrant to the field, Oxc is a collection of Rust-based JavaScript tools focusing on linting, formatting, and transforming JavaScript/TypeScript code.

It is part of the VoidZero project founded by Evan You (creator of Vue.js and Vite), and aims to be the backbone for the next-generation of JavaScript tooling.

Oxc’s headline features include:

• A JavaScript parser that’s 3x faster than SWC.
• A TypeScript/JSX transformer that’s 20x to 50x faster than Babel.
• An ESLint-compatible linter that runs significantly faster (~50-100x).

oxlint has been a massive win for us at Shopify. Our previous linting setup took 75 minutes to run, so we were fanning it out across 40+ workers in CI. By comparison, oxlint takes around 10 seconds to lint the same codebase on a single worker, and the output is easier to interpret. We even caught a few bugs that were hidden or skipped by our old setup when we migrated!

— Jason Miller, creator of Preact

5. FNM/Volta

Modern Node.js version management has greatly improved with tools like Fast Node Manager (fnm) and Volta, which are compelling alternatives to NVM. Another option is Mise, which supports Node.js along with many other development tools.

These Rust-based tools offer significantly faster shell initialization times and full cross-platform support with a much smaller memory footprint.

They address long-standing pain points in NVM, such as sluggish startup and lack of Windows compatibility, while adding conveniences like per-project version switching and seamless global package management.

6. TypeScript in Go

Perhaps the most surprising development in recent months is Microsoft’s work on porting TypeScript’s compiler to Go.

While it’s still in active development, preliminary benchmarks already show remarkable improvements in build times (~10x for VS Code’s codebase), editor startup speeds, and memory usage.

This native port addresses TypeScript’s scaling challenges in large codebases, where developers previously had to compromise between snappy editor performance and rich type feedback.

While some viewed the choice of Go over Rust as a missed opportunity, given the latter’s dominance in modern JavaScript tooling, the rationale behind this decision aligns well with the project’s practical goals:

The existing code base makes certain assumptions – specifically, it assumes that there is automatic garbage collection – and that pretty much limited our choices. That heavily ruled out Rust. I mean, in Rust you have memory management, but it’s not automatic; you can get reference counting or whatever you could, but then, in addition to that, there’s the borrow checker and the rather stringent constraints it puts on you around ownership of data structures. In particular, it effectively outlaws cyclic data structures, and all of our data structures are heavily cyclic.

— Anders Hejlsberg, creator of TypeScript

Microsoft intends to ship the Go-based implementation as TypeScript 7.0 in the coming months, but native previews are already available for experimentation.

Implications for the Future of JavaScript Tooling

Beyond the clear performance gains, the rise of native tooling for JavaScript brings deeper, ecosystem-wide implications.

With many established and upcoming tools now relying on entirely different runtimes and ecosystems, contributing becomes less accessible to the majority of JavaScript developers.

At the same time, this shift may influence the skill sets that developers choose to pursue in the first place. While not everyone needs to write systems-level code, understanding how these languages work and what they make possible will drive even more innovative tooling in the coming years.

Unsurprisingly, although learning Rust or Zig presents a steeper barrier to entry, developers overwhelmingly prefer faster tools (even if they’re harder to contribute to).

One other subtle, but important, tradeoff is the loss of dogfooding, where tool creators stop using their own language to build their tools: which has historically helped developers in tune with the experience they’re shaping.

Moving to a different implementation language can weaken that feedback loop, and while many projects are aware of this risk, the long-term impact of a lack of dogfooding remains an open question.

Other Tools

The tools covered here represent just a slice of the growing ecosystem of performance-focused, native-powered developer tools, and the momentum behind this new wave is undeniable.

Other notable efforts in this space include Turbopack and Turborepo (from Vercel), Dprint (a Prettier alternative), and even full-fledged runtimes like Bun (written in Zig) and Deno (Rust), which reimagine what’s possible by rebuilding JavaScript infrastructure from the ground up.

Together, these tools reflect a broader shift in the JavaScript world that makes it clear that the future of JavaScript tooling is being written in Rust, Go, Zig, and beyond.

Wrapping Up

In this post, we explored several tools driving a new wave of performance and innovation across the JavaScript ecosystem.

The performance revolution in JavaScript tooling is a fascinating case study in ecosystem evolution.

Instead of being constrained by the limitations of JavaScript itself, the community has pragmatically embraced other languages to push the boundaries of what’s possible.