Biome lints 10,000 files in 0.8 seconds. ESLint takes 45.2. That’s the headline driving every “biome vs eslint prettier 2026” Slack thread on your team right now, and it’s why someone keeps asking when you’re switching.
Here’s what the benchmark posts aren’t telling you. ESLint still has 50 million weekly npm downloads and a decade of plugins your codebase probably depends on. Biome v2 is genuinely impressive — but “25x faster” answers the wrong question. The right one is whether that speed math actually works for your project. Let’s run it.
What 25x Faster Actually Means in a Real Project
Speed scales weirdly with project size. The 25x number is real, but where you sit on the curve changes whether it’s life-changing or a rounding error.
Small project, under 500 files. Lint runs in 2 seconds with ESLint, 0.2 with Biome. That difference doesn’t survive the noise floor of your daily work. Your editor lints incrementally, your CI is dominated by npm install and tests, and the savings disappear into the gaps between commands. Speed is not your reason to switch here.
Medium project, around 5,000 files. ESLint takes 22 seconds. Biome takes half a second. This is where the gap becomes a feature. Pre-commit hooks stop being the thing engineers grumble about and silently disable. CI gets back a minute per pipeline. Multiply by 50 PRs a week and you’ve earned back a workday a month.
Monorepo, 10,000+ files. Biome finishes in under a second. ESLint takes 45 — and that’s if nobody added the type-aware rules from typescript-eslint. Add those and ESLint can creep into multi-minute territory on a cold cache. This is where speed turns into developer happiness.
The honest framing: Biome’s biggest wins land in the codebases that are also the hardest to migrate. Your side project gets nothing meaningful. Your fat enterprise monorepo gets the moon — and also has 40 plugins, three Yarn workspaces, and a lint config older than the project lead.
Speed is also no longer Biome’s only pitch. Biome v2 (released March 2025, codename Biotype) added type-aware linting without requiring the TypeScript compiler — the first JS linter to do that. Version 2.3 ships with 423+ rules, which closes a gap that used to be a clean argument against switching.
So if raw speed isn’t the reason, what’s actually worth switching for?
Three Things Biome Nails Out of the Box
The case for switching isn’t a feature list. It’s three specific wins that show up in the work.
One config, no Prettier-vs-ESLint cold war. Every team that uses both tools has spent a meeting — or a Friday afternoon — fighting over eslint-config-prettier, semicolon rules that disagree, or a formatter argument hijacking a code review. Biome ships linting and formatting as one binary, one config, one mental model. The eslint-config-prettier tax disappears. The “who runs first in CI?” question disappears. The dual-tool config sprawl nobody likes maintaining disappears. If you’ve ever onboarded a junior dev who couldn’t figure out why their saved file looked different from the linted file, you already know what this is worth.
Defaults that don’t insult your intelligence. A fresh biome.json with recommended: true gives you a sensible TypeScript lint config in three lines. Compare that to a typical ESLint v9 flat config — extending recommended sets, the TypeScript parser, the import plugin, the React plugin if you’re in React, the a11y plugin if anyone cares about a11y. Biome’s defaults aren’t perfect for every team, but they’re good enough that you can start writing code immediately and tune later. Most ESLint configs get tuned exactly never. They’re inherited from the last person who left.
Type-aware linting without the TypeScript compiler. Biome v2’s Biotype catches floating promises, unsafe any assignments, and several other type-driven rules — all in milliseconds, without spinning up tsc. typescript-eslint does the same thing, but it has to run a real TypeScript program to do it, which is the slow part. On a 5,000-file project, type-aware ESLint can take 10–30 seconds. Biome takes a fraction of that. The catch: Biome’s type rules are a subset of what typescript-eslint offers, and cross-file type narrowing isn’t fully there yet. Useful, but bounded. If you want a refresher on where typed rules pay off, the practical TypeScript guide covers that side.
A unified toolchain, defaults that work, type-aware rules without the compiler tax. Three real wins. So why isn’t this article just “switch already”?
Two Reasons to Stay With ESLint (For Now)
Because the plugin gap is real, and the type-aware story isn’t fully closed.
The plugin ecosystem is specific, and so is what’s missing. Biome covers around 80–90% of common ESLint rules. The remaining 10–20% is the part that hurts. Specifically:
eslint-plugin-react-hooks— theexhaustive-depsrule that catches half your real React bugs. Biome has a partial equivalent, but it’s not a full replacement yet.eslint-plugin-jsx-a11y— accessibility rules that legal might actually care about. Biome has some a11y coverage, but if you’re held to WCAG with a custom rule set, you’ll feel the gap.eslint-plugin-importwith advanced resolver configs — TypeScript path aliases plus monorepo workspaces plus custom resolvers. Biome’s import handling improves every release but isn’t a drop-in replacement.eslint-plugin-jestand other test-framework rules — Biome has none. If your test strategy leans on these, factor that in.eslint-plugin-tailwindcss— class-name ordering and unknown-class detection. No Biome equivalent.- Framework-specific rules for Vue, Svelte, and Astro — varied and incomplete.
If you depend on any of these, the question isn’t “is Biome faster” — it’s “what do I do about the rule I can’t replace?” You either drop the rule (sometimes fine), keep ESLint just for that rule and run both (extra complexity), or write a custom Biome plugin (now possible in v2 but the ecosystem is still young).
Type-aware rule parity isn’t full parity. Biotype is impressive, but typescript-eslint’s strict rule set still catches things Biome doesn’t — particularly cross-file type narrowing and the deeper no-unsafe-* rules. If your team has standardized on those rules and your codebase relies on them, the gap matters.
A third honest thing: ESLint v9’s flat config killed one of Biome’s biggest selling points. Config simplicity is no longer a one-sided contest. And there’s a small but real category of teams who tried Biome, hit a plugin gap they couldn’t work around, and switched back. That’s not failure — that’s the wrong fit for that codebase.
So how do you tell which side you’re on? You run the math.
The Migration Cost Math Nobody Shows You
Here’s what the switch actually costs for a typical 10-person team on a 50,000-line TypeScript codebase.
- Rule mapping. Expect 80–90% of your existing rules to map cleanly. The
biome migrate eslintcommand handles the bulk in minutes. You’ll review the leftovers and make decisions one by one. - Editor and muscle memory. Around 2 hours per developer. Editor extension setup,
biome.jsonorientation, learning the new CLI flags. Multiply by team size — that’s your biggest line item. - CI/CD. 1–2 hours total. Replacing the
eslintandprettiersteps with a singlebiome cicall. Net win on CI minutes after. - Pre-commit hooks. 30 minutes if you use
huskyandlint-staged. Biome’s--stagedflag is cleaner than ESLint’s setup. - The hidden cost. Each plugin gap forces a decision: drop the rule, keep ESLint just for that rule, or write a custom Biome plugin. This is where teams burn an unbudgeted day or two.
Honest total: 25–40 hours of team time. ROI: faster pre-commits plus 30–60 seconds back per CI run typically pays this back in 2–3 months. If you’re also weighing runtime swaps, the same migration-cost math for Bun vs Node.js covers that side of the pipeline.
The math changes by project type. Here’s how to know which math applies to you.
A Decision Framework by Project Type
- Greenfield project. Switch. Defaults are good, speed compounds, nothing to migrate. Easiest call in the article.
- Existing project under 50k LOC, light plugin use. Switch. A 1–2 day investment that pays back fast.
- Project with heavy plugin dependencies (React-hooks, a11y, Tailwind, custom rules). Stay or go hybrid. Run Biome for formatting and base linting, keep ESLint for the plugins that matter. Yes, two tools. Yes, it works. Many teams do this on purpose.
- Large monorepo (Turborepo, Nx). High-value but high-effort — pilot in one package first. Biome handles monorepos well in v2.4, but plan for 1–2 weeks across packages. If you’re still picking your monorepo tool, the Turborepo vs Nx breakdown covers that decision separately.
- Vue, Svelte, or legacy framework. Check Biome’s framework support against your specific stack. The gap closes in v2 but it isn’t gone.
The Bottom Line
The 25x benchmark is real, but it’s not your reason to switch — the unified toolchain and type-aware linting are. Biome is production-ready in 2026 for most projects. Switch when it would make you faster. Stay or run a hybrid when the plugin gap would slow you down. The benchmark answers the wrong question.