For years, JavaScript developers have accepted an annoying tax: two tools, two configs, and the constant possibility that they’ll disagree. ESLint worries about code quality; Prettier reshapes your style. In theory they’re complementary. In practice, teams end up with drift, duplicated rules, and a pipeline that feels heavier than it should. Biome changes the equation: one fast, Rust-based tool that both formats and lints—without you hand-tuning a peace treaty between systems that were never meant to work together.

The real problem: two tools, one codebase, endless edge cases⌗

ESLint and Prettier solve different problems, but they create shared responsibilities:

  • ESLint enforces rules (style, correctness, best practices) and can also format in limited ways.
  • Prettier enforces formatting (whitespace, quotes, commas, indentation) and will reformat whatever it’s pointed at.

The friction starts when teams try to make those responsibilities overlap just enough to avoid conflicts. The common response is to configure ESLint with rules like “delegate formatting to Prettier,” disable stylistic rules, add plugins, and wire up both tools in scripts—often in a sequence that depends on file types, editor behavior, and CI.

Here’s what that looks like in real projects:

  • Developers run eslint locally and sometimes see issues that disappear after formatting.
  • Prettier changes code in ways that make an ESLint rule complain differently (or vice versa).
  • Teams accumulate “temporary” rules and overrides to quiet a specific case.
  • Migrations become multi-step: update dependencies, adjust configs, then revisit rules, then fix formatting diffs that show up everywhere.

This is not just inconvenience—it’s a DX tax. Every time formatting and linting are separate, you pay with complexity: more configuration, more tooling surface area, more chances for the editor to behave differently than CI, and more time watching diffs scroll by.

What Biome does differently: one pass for style and correctness⌗

Biome is a single tool designed to be a formatter and linter in one. Conceptually, the win is simple:

  • Formatting isn’t an external “afterthought” step.
  • Linting isn’t blind to the formatting decisions that will be applied.
  • Configuration doesn’t need to coordinate two separate rule engines.

Practically, Biome aims for a workflow where running it is deterministic: the same input yields the same output, and both linting feedback and formatted code come from the same source of truth.

The result is a more cohesive developer experience. Instead of asking, “Should I run ESLint or Prettier first?” you just run one tool and move on. Instead of maintaining a brittle chain of config choices to prevent conflicts, you rely on one tool’s built-in philosophy about what good code looks like.

And yes—the speed matters. When a tool is fast enough, it changes how people work: formatting-before-commit becomes default behavior instead of a background chore. On large repositories, the difference is visceral—less time waiting, fewer context switches, and fewer “why is CI taking so long” conversations.

Migration: replacing a two-tool pipeline with one command⌗

Most teams don’t want a rewrite. They want a swap.

Step 1: Install Biome and add a config⌗

You add Biome to your dev dependencies and let it generate or adopt configuration. Biome supports formats and linting in a way that maps cleanly to typical expectations: you don’t need to invent a new governance process, you replace the enforcement engine.

Step 2: Start by wiring Biome into scripts⌗

A straightforward migration typically looks like:

  • Run Biome in CI to ensure formatted code and lint rules are satisfied.
  • Optionally run Biome in a pre-commit hook for quick feedback.
  • Update developer scripts so local checks match CI.

Instead of eslint . and prettier --check . (plus whatever plugins and ignore rules make those behave), you run Biome and let it do both. The key benefit isn’t just fewer commands—it’s fewer mismatched behaviors.

Step 3: Accept and commit the formatting baseline⌗

Your first Biome run will produce diffs. That’s normal, and it’s the point. Commit a clean formatting baseline so future diffs reflect real changes, not tooling churn.

A practical tip: do this as a single atomic commit (or a small number of commits) and communicate it clearly. Teams that treat migration diffs as background noise tend to lose trust in the toolchain. Treat it as “day one, reset the baseline,” and you’ll get cleaner downstream behavior.

Step 4: Lock in linting expectations⌗

Then you tune linting to your preferences—without maintaining two different rule systems. If you currently have ESLint rules that exist only to prevent formatting chaos, expect them to disappear in the new world. If you relied on Prettier to control style, those decisions become part of Biome’s formatting pipeline.

The outcome: fewer “override files” and fewer “we had to disable that rule because Prettier changes it” conversations.

Editing and CI: making “works on my machine” less of a thing⌗

A large part of the ESLint/Prettier era is the mismatch between:

  • Editor formatting (what happens when you save)
  • Local scripts (what you run manually)
  • CI checks (what gatekeepers enforce)

Even when teams “configure correctly,” these three can still drift due to plugin versions, extension settings, file globs, ignore rules, and ordering.

Biome’s value shows up when you make one tool authoritative:

  • If the editor uses Biome for formatting, your saved code matches the CI expectation.
  • If the same Biome config drives both lint and formatting checks, you avoid the “formatting passes but lint fails” loop.
  • If it runs quickly, teams actually enable it everywhere (pre-commit, CI, and—critically—editor save hooks).

A good target workflow is: save triggers formatting, and commits trigger lint + formatting checks. When everything is the same tool, you reduce the number of moving pieces that can disagree.

Performance is not a “nice to have”—it changes team behavior⌗

The slogan “100x faster” is marketing unless you’ve felt the alternative. In practice, slower formatter/linter combos produce predictable habits:

  • Developers defer running formatting to “later.”
  • People skip linting locally and rely on CI.
  • Pre-commit hooks get disabled or weakened because they feel too slow.
  • Large diffs become painful because the feedback loop is sluggish.

Biome shifts the incentives. When checks are quick, teams tighten the loop: run checks more often, fix issues sooner, and stop treating linting as a gate you survive at the end of the day. You get less friction and more consistency—and because it’s one tool, you get fewer “why did that change?” mysteries.

On big monorepos, this matters even more. Toolchain overhead scales with the number of files and the number of times you run it. The best DX improvements aren’t always about adding features; sometimes they’re about removing the need to run two heavyweight passes across the same code. Biome’s approach is that removal made real.

Common concerns: “Will it match our existing standards?” and “What about rule parity?”⌗

Migration anxiety is healthy. Teams should ask:

  • Will Biome format code in a way that matches our current style expectations?
  • Will our current ESLint rules translate cleanly?
  • Will we lose coverage?

The honest answer: you’ll want to evaluate it in your codebase. But the migration path usually benefits from the same observation that motivates Biome in the first place: if you’re currently maintaining two tools to approximate one consistent style, you already know your setup isn’t perfectly coherent.

A pragmatic plan:

  1. Run Biome and review diffs to ensure formatting isn’t wildly surprising.
  2. Port lint expectations incrementally—start broad, then tighten.
  3. Measure trust: once developers see that Biome’s output is consistent and fixes issues quickly, adoption becomes easy.

If you truly require specific custom ESLint rule behavior, you’ll need to verify Biome’s lint coverage for those exact cases. But even when teams find one or two rule gaps, the overall direction remains compelling: fewer conflicts, less configuration complexity, and faster feedback loops.

Conclusion: one tool to enforce one standard⌗

The Prettier/ESLint era wasn’t a mistake—it was a necessary compromise for a messy time in tooling. But the compromise is over. Biome offers a simpler model: one Rust-based tool that formats and lints together, producing consistent results with less configuration and dramatically faster feedback.

If your team is still juggling rule overrides, sequencing scripts to avoid conflicts, and watching formatting + lint diffs become background noise, it’s time to collapse the pipeline. The best DX upgrade isn’t another plugin. It’s fewer tools doing more correctly—faster—so developers can spend their attention on the code, not the toolchain.