Biome vs ESLint vs oxlint: Best JavaScript Linter (2026)

ESLint has dominated JavaScript linting for a decade. Now Rust-based alternatives — Biome and oxlint — offer 10-100x faster linting. Is it time to switch?

Quick Comparison

Feature	Biome	ESLint	oxlint
Language	Rust	JavaScript	Rust (Oxc)
Speed	10-30x faster than ESLint	Baseline	50-100x faster than ESLint
Formatter	Built-in (Prettier-compatible)	No (use Prettier)	No
Rules	270+	300+ (core) + thousands (plugins)	400+
Plugin system	Limited (GritQL)	Extensive	No
TypeScript	Native	Via parser plugin	Native
Auto-fix	Yes	Yes	Yes
Config	biome.json	eslint.config.js (flat config)	.oxlintrc.json
IDE support	VS Code, IntelliJ	All major IDEs	VS Code
Import sorting	Built-in	Via plugin	No

Biome: The All-in-One Toolchain

Biome (formerly Rome) combines linting, formatting, and import sorting in a single Rust-based tool.

Strengths

• Fast. 10-30x faster than ESLint. Lints a large codebase in milliseconds.
• All-in-one. Linter + formatter + import sorter. Replace ESLint, Prettier, and import sorting plugins with one tool.
• Zero config to start. Sensible defaults work for most projects. npx @biomejs/biome check . and you're linting.
• Prettier-compatible formatter. 97%+ compatibility with Prettier output. Most teams can switch without changing code style.
• TypeScript native. Parses TypeScript directly — no @typescript-eslint/parser needed.
• One dependency. Single npm package vs. ESLint's typical 15-20 dev dependencies.

Weaknesses

• Fewer rules. 270+ rules vs ESLint's ecosystem of thousands. Missing some niche rules.
• Limited plugin system. No equivalent to ESLint's vast plugin ecosystem. GritQL-based custom rules exist but are early.
• No framework-specific rules. No eslint-plugin-react-hooks, eslint-plugin-next, or similar. These are gradually being added.
• Newer. Less battle-tested edge cases compared to ESLint's decade of production use.

Best For

Teams that want a fast, simple, unified toolchain and don't rely heavily on ESLint plugins. Especially good for new projects without existing ESLint config debt.

ESLint: The Ecosystem Standard

ESLint has been the standard JavaScript linter since 2013. Its plugin ecosystem is unmatched.

Strengths

• Largest rule ecosystem. Thousands of rules across hundreds of plugins. React, Vue, Angular, Next.js, accessibility, testing — there's a plugin for everything.
• Flat config (v9+). New configuration system is cleaner and more composable than the old .eslintrc format.
• Custom rules. Write custom rules in JavaScript. Extensive AST documentation and tooling.
• Universal IDE support. Every code editor supports ESLint natively or via extensions.
• Type-aware rules. @typescript-eslint provides rules that use TypeScript's type checker for deeper analysis.
• Industry standard. Every tutorial, every boilerplate, every CI/CD template assumes ESLint.

Weaknesses

• Slow. JavaScript-based execution is inherently slower than Rust. Large codebases can take 10-30 seconds to lint.
• Config complexity. Even with flat config, ESLint setups often involve 10+ plugins and complex rule configurations.
• Dependency bloat. A typical ESLint setup installs 50-100+ transitive dependencies.
• No formatter. You still need Prettier (and eslint-config-prettier to avoid conflicts).
• Breaking changes. Major version upgrades (v8→v9) require significant config migration.

Best For

Teams that need specific framework plugins, type-aware linting, or custom rules. The safe default choice for any JavaScript project.

oxlint: Raw Speed

oxlint is part of the Oxc (Oxidation Compiler) project. It's the fastest JavaScript linter available.

Strengths

• Blazing fast. 50-100x faster than ESLint. Lints massive monorepos in under a second.
• 400+ rules. Covers most of ESLint's core rules plus popular plugin rules (React, TypeScript, import, Jest, etc.).
• Zero config. Works with sensible defaults. No configuration file needed to start.
• Drop-in complement. Designed to run alongside ESLint — handles the fast checks, ESLint handles the complex type-aware checks.

Weaknesses

• No plugin system. Can't extend with custom rules. You get what's built-in.
• No formatter. Linting only — still need Prettier or Biome for formatting.
• No type-aware rules. Can't use TypeScript's type checker for deeper analysis.
• Early stage. API and rule coverage are still evolving.
• Limited IDE integration. VS Code extension available, but less mature than ESLint's.

Best For

Large monorepos where linting speed is a bottleneck. Works best as a complement to ESLint (oxlint for fast checks, ESLint for type-aware rules).

Speed Benchmarks

On a typical large TypeScript project (~500 files):

Tool	Time	Relative
oxlint	~50ms	1x
Biome	~200ms	4x
ESLint (without type-checking)	~5s	100x
ESLint (with type-checking)	~15s	300x

In CI/CD pipelines, this difference is significant. In IDE save-on-type, all three are fast enough.

Migration Guide

ESLint → Biome

# Install
npm install --save-dev @biomejs/biome

# Migrate config (auto-converts ESLint rules to Biome equivalents)
npx @biomejs/biome migrate eslint

# Check what changes
npx @biomejs/biome check . --write

# Remove ESLint + Prettier
npm uninstall eslint prettier eslint-config-prettier @typescript-eslint/parser ...

Biome's migration tool handles most rule conversions. Review the output for rules that don't have Biome equivalents.

Adding oxlint alongside ESLint

# Install
npm install --save-dev oxlint

# Add to scripts
# package.json
{
  "scripts": {
    "lint": "oxlint . && eslint .",
    "lint:fast": "oxlint ."
  }
}

Run oxlint first (fast), then ESLint for type-aware rules. Disable overlapping rules in ESLint to avoid duplicate warnings.

Decision Matrix

Priority	Choose
Speed above all	oxlint
All-in-one (lint + format)	Biome
Maximum rule coverage	ESLint
New project, minimal config	Biome
Existing project, heavy ESLint config	Stay with ESLint (add oxlint for speed)
Monorepo with slow CI	oxlint + ESLint
Framework-specific rules needed	ESLint
Type-aware linting	ESLint

FAQ

Can Biome fully replace ESLint?

For most projects, yes. The gap is shrinking rapidly. The main blockers are framework-specific rules (React hooks, Next.js) and type-aware linting. Check Biome's rule list against your ESLint config to verify.

Should I use oxlint instead of ESLint?

Use both. oxlint for fast feedback (pre-commit, CI), ESLint for comprehensive checks (type-aware rules, framework plugins). They complement each other.

Is ESLint dying?

No. ESLint's flat config and ongoing development show an active project. However, its role may shift from "the only linter" to "the deep analysis linter" while Rust-based tools handle fast linting.

Which is best for a new project?

Biome. One tool, one config, fast, and covers most needs. Add ESLint later if you need specific plugins.

The Verdict

• New projects: Start with Biome. One tool replaces ESLint + Prettier with better performance.
• Existing projects with heavy ESLint config: Keep ESLint, add oxlint for fast CI checks.
• Monorepos/large codebases: oxlint for speed, ESLint for depth.
• Need specific plugins: ESLint remains necessary when framework-specific rules are critical.

The future is Rust-based linting. The question is whether you switch now (Biome) or transition gradually (oxlint alongside ESLint).