JavaScript tooling is slowly moving away from JavaScript.
ESLint, Prettier, Babel and other tools have been the foundation of modern frontend development for years. But a growing number of projects are rebuilding parts of the toolchain in Rust.
One project increasingly worth watching is Oxc.
Oxc is a collection of high-performance JavaScript and TypeScript tools written in Rust. It already includes a parser, transformer, resolver, minifier, linter and formatter. Its broader goal is to provide shared building blocks for a faster JavaScript toolchain.
And it is starting to appear in more places.
Oxc just landed in Nx
Nx 23.2 introduced experimental support for both Oxlint and Oxfmt.
The release includes an @nx/oxlint plugin, configuration support and integration with Nx’s module-boundary rules. That matters because Nx is widely used for large JavaScript and TypeScript codebases and monorepos.
This isn’t just another benchmark showing that a Rust tool is faster.
It means Oxc is starting to integrate with the workflows where JavaScript tooling actually becomes painful: large repositories, CI pipelines and complex monorepos.
What is Oxc replacing?
Potentially, quite a lot.
| Traditional tool | Oxc alternative | Status |
|---|---|---|
| ESLint | Oxlint | Production-ready |
| Prettier | Oxfmt | Growing rapidly |
| Babel / SWC transforms | Oxc Transformer | Available |
| Terser | Oxc Minifier | Available |
| Node-style module resolution | Oxc Resolver | Available |
| JavaScript / TypeScript parser | Oxc Parser | Available |
Oxc’s biggest advantage isn’t necessarily one individual tool.
It is the idea of sharing the same underlying infrastructure across the toolchain.
Instead of multiple tools independently parsing the same codebase, Oxc can provide common building blocks for parsing, transforming, resolving and analyzing JavaScript and TypeScript.
The speed numbers are impressive
Oxlint positions itself as a high-performance alternative to ESLint, with strong ESLint migration support and hundreds of built-in rules.
Oxfmt is targeting a Prettier-compatible workflow while focusing heavily on performance.
The Oxc project reports significant performance improvements, particularly on large repositories and CI workloads. Recent work on JavaScript plugin support is also important: Oxlint can increasingly support existing ESLint plugins instead of forcing every project to immediately rewrite its configuration.
That last part might be more important than raw speed.
Fast tooling is nice.
Fast tooling that doesn’t require rewriting your entire project is much more useful.
Why Rust?
Rust has become a popular choice for developer tooling.
The reason isn’t simply that „Rust is fast”.
For tools that repeatedly parse and analyze large codebases, native performance can make a significant difference. Faster feedback loops also mean:
- quicker pre-commit hooks,
- faster CI pipelines,
- shorter builds,
- less duplicated work,
- and potentially lower CI costs.
We’ve already seen this trend with tools such as Biome, SWC and now Oxc.
The interesting question is whether JavaScript developers will eventually stop thinking about the language used to build their tools.
Your application can still be written in TypeScript.
But the tools compiling, linting, formatting and analyzing it may increasingly be written in Rust.
Is Oxc ready to replace everything?
Not yet.
The JavaScript tooling ecosystem is enormous. ESLint alone has years of plugins, custom rules and unusual configurations behind it.
Migration compatibility remains one of the biggest challenges.
Oxc itself acknowledges this by supporting incremental migration. Teams can run Oxlint alongside ESLint and gradually move supported rules instead of replacing everything in a single pull request.
That is probably the right approach for large projects.
| Project type | Our recommendation |
|---|---|
| New TypeScript project | Worth trying Oxc |
| Small ESLint project | Test Oxlint migration |
| Large monorepo | Consider incremental adoption |
| Heavy custom ESLint plugins | Check compatibility first |
| Stable working setup with no performance problems | No reason to migrate just for hype |
The bigger trend
Oxc is interesting because it isn’t trying to build just one faster linter.
It is building infrastructure for a larger ecosystem.
The project now covers much of the JavaScript toolchain, while Oxlint and Oxfmt are increasingly becoming practical alternatives to ESLint and Prettier. Nx adding Oxc support is another sign that these tools are moving closer to mainstream development workflows.
The JavaScript ecosystem probably won’t be „replaced by Rust”.
But more and more of the infrastructure underneath it already is.
And for developers, that might be the best possible outcome:
Keep writing JavaScript. Make the tooling faster.
At Fireup, we have already seen how much developer experience can improve when linting and formatting become significantly faster. The next few years may bring an even bigger shift: instead of choosing separate tools for every part of the pipeline, teams could increasingly adopt unified toolchains built on shared, high-performance foundations.
