ESLint vs Biome vs Oxc: The Ultimate JavaScript Linter Performance Showdown
In 2024, a typical mid-sized TypeScript monorepo with 500 files can take anywhere from 12 seconds to over 3 minutes to lint. For developers running lint-staged on every commit, that three-minute wait isn’t just annoying—it’s a productivity killer that encourages people to skip the check altogether.
This performance gap is exactly why tools like Biome and Oxc have emerged as serious challengers to ESLint, the long-standing default. But speed isn’t the only metric that matters. Rewriting your entire linting infrastructure carries real costs in plugin compatibility, configuration migration, and team buy-in.
I ran a series of benchmarks on a real-world codebase and analyzed the architectural differences to give you a clear picture of where each tool stands today—and what you should actually adopt in 2025.
The Current State of JavaScript Linting
ESLint has been the industry standard since its release in 2013. Its plugin ecosystem is unmatched: over 3,000 plugins on npm, covering everything from React hooks to security vulnerabilities. The core team’s decision to support custom processors and shareable configs made it the backbone of most CI pipelines.
But ESLint has a structural problem. It’s written in JavaScript and runs on Node.js, which means it parses files into an AST (abstract syntax tree) using JavaScript itself. For a 10,000-line file, that parsing step alone can take hundreds of milliseconds. Multiply that across hundreds of files, and you’re looking at minutes of pure CPU time.
The new generation of tools takes a different approach: write the core in a compiled language (Rust or C/C++) and expose a JavaScript API for integration. This isn’t a new idea—Prettier did it with its own Rust-based engine—but it’s only recently that linters have followed suit.
How We Benchmarked
I tested all three tools on a production codebase with 412 TypeScript files, roughly 85,000 lines of code, including React components and Node.js services. The test machine was a MacBook Pro with an M2 Pro chip and 16GB of RAM, running Node 22 and the latest versions of each tool as of November 2024.
The benchmark measured three scenarios:
- Cold run: No cache, first execution
- Warm run: With cache enabled, second execution
- CI simulation: Running with
--max-warnings 0to ensure all rules are checked
Here’s what I found.
ESLint: The Reliable Heavyweight
ESLint 9.x (with the new flat config) took 38.4 seconds for a cold run on the test codebase. With caching enabled, the warm run dropped to 2.1 seconds—but that cache only helps if no files have changed. In a typical development workflow where you’re editing a few files at a time, the incremental cache works well. In CI, where every run starts fresh, you’re back to the 38-second wall.
The bigger issue is memory. ESLint peaked at 412MB of RAM during the cold run, which can cause problems on memory-constrained CI runners or local machines with limited resources.
That said, ESLint’s strengths remain undeniable. The plugin ecosystem means there’s a rule for almost anything you can think of. TypeScript support via typescript-eslint is mature, handling complex type-aware rules that the newer tools simply can’t match yet. If you need a specific rule for your framework or internal coding standards, ESLint almost certainly has it.
Verdict: Still the most powerful option, but the performance ceiling is real.
Biome: The All-in-One Replacement
Biome (formerly Rome) is built in Rust and positions itself as a drop-in replacement for ESLint and Prettier. It bundles formatting, linting, and import sorting into a single binary with no dependencies.
The performance difference is dramatic. Biome completed the cold run in 1.9 seconds—roughly 20x faster than ESLint. Warm runs were essentially instant at 0.4 seconds. Memory usage peaked at 48MB, a fraction of ESLint’s footprint.
But here’s the tradeoff: Biome currently supports about 200 rules compared to ESLint’s thousands. The TypeScript support is solid for syntax-level checks, but type-aware rules (like no-floating-promises or no-unnecessary-type-assertion) are missing. If your codebase relies heavily on type-aware linting, Biome will catch fewer issues.
The configuration experience is also different. Biome uses a single biome.json file for both formatting and linting, which is simpler than ESLint’s flat config. But migrating an existing ESLint config requires manual translation—there’s no automatic conversion tool.
Verdict: The best performance-to-feature ratio if you’re starting fresh or willing to adjust your rule set.
Oxc: The Newest Contender
Oxc (short for Oxidation Compiler) is the most recent entrant, backed by the same team that created Vue.js. It’s not a linter per se—it’s a set of JavaScript tooling written in Rust, including a parser, transformer, and linter that can be used independently.
In my benchmarks, Oxc’s linter completed the cold run in 1.2 seconds—the fastest of the three. Memory usage was 32MB. Warm runs were 0.3 seconds.
What sets Oxc apart is its architecture. It’s designed as a library first, meaning you can embed its parser and linter into other tools. This is already happening: the oxlint CLI is available, but more interestingly, projects like Vite and Rolldown are integrating Oxc’s parser to speed up their own processing.
However, Oxc’s rule set is even more limited than Biome’s—roughly 150 rules at the time of testing. It’s also the least mature project of the three, with a smaller community and less documentation. If you’re an early adopter, expect to encounter rough edges.
Verdict: The fastest option, but the least production-ready for large teams.
The Plugin Ecosystem Problem
All three tools face the same fundamental challenge: plugins. ESLint’s power comes from its community, and no Rust-based linter can match that overnight.
Consider the eslint-plugin-react ecosystem. It has rules for jsx-no-constructed-context-values, jsx-key, and dozens of other React-specific patterns. Neither Biome nor Oxc has full coverage for these rules. If you’re a React shop, switching to Biome or Oxc means either losing those checks or writing custom rules in a new language (Rust for Biome, which has a steep learning curve).
There are also ecosystem integrations to consider. ESLint has first-class support in VS Code, GitHub Actions, and virtually every CI platform. Biome has a VS Code extension, but it’s less polished. Oxc’s editor integration is still in beta.
A Realistic Migration Path
If you’re currently on ESLint and considering a switch, here’s a pragmatic approach:
Step 1: Run Biome or Oxc alongside ESLint. Use the Rust-based tool for fast feedback during development (file watching, pre-commit hooks) and keep ESLint for CI. This gives you speed where it matters most—your local dev loop—without sacrificing the deep checks in your pipeline.
Step 2: Identify gaps. Use Biome or Oxc’s --rules flag to see which of your critical ESLint rules have equivalents. In my testing, roughly 70% of common ESLint rules have direct counterparts in Biome.
Step 3: Migrate incrementally. Start with formatting-only mode in Biome (which replaces Prettier), then enable lint rules gradually as you verify they catch the same issues.
Step 4: Keep ESLint for type-aware rules. If you heavily use typescript-eslint with type checking, keep ESLint as a final gate in CI. You can run both tools in a single pipeline—the speed difference means the Rust-based tool adds negligible overhead.
The Verdict
There’s no single “best” linter—it depends on your priorities.
Choose ESLint if you have a large existing codebase, rely on type-aware rules, or need an extensive plugin ecosystem. The performance cost is real, but the coverage is unmatched.
Choose Biome if you’re starting a new project, want a single tool for formatting and linting, or you’re frustrated with ESLint’s configuration complexity. The speed gain is significant, and the rule set covers most common needs.
Choose Oxc if you’re an early adopter who values raw performance above all else, or if you’re building tooling that needs an embedded Rust-based parser. Just be prepared for a smaller community and fewer resources.
The broader trend is clear: Rust-based tooling is the future of JavaScript infrastructure. Even ESLint’s team has acknowledged this—they’re working on a Rust port, though it’s still years away from production. For now, the smartest approach isn’t to pick a single winner, but to use the right tool for each job in your development workflow.
The 38-second CI lint time doesn’t have to be your reality. Whether you switch entirely or adopt a hybrid approach, the performance gains from the new generation of linters are too significant to ignore.