What Is Biome? ESLint and Prettier in One Rust Tool

Biome is a single, Rust-based toolchain that lints and formats JavaScript, TypeScript, JSX, JSON, and CSS — the two jobs that ESLint and Prettier have traditionally split between two separate tools, two configuration files, and a plugin ecosystem that has to be assembled and kept in sync by hand.

It isn’t the first attempt to consolidate that toolchain, but it’s arrived at a moment where JavaScript tooling has been broadly moving toward compiled, non-JavaScript implementations for speed — the same motivation behind projects rewriting bundlers and package managers in Rust or Go rather than JavaScript itself.

What problem it’s solving

A typical JavaScript project’s linting and formatting setup usually looks like this: ESLint for catching bugs and enforcing code style rules, Prettier for reformatting code layout, an eslint-config-prettier package to stop the two from fighting over formatting rules, and a handful of plugins for framework- or language-specific rules — one for TypeScript, one for React, one for import ordering. Each piece has its own configuration format, its own release cadence, and its own compatibility matrix with the others.

Biome collapses that into one binary with one configuration file (biome.json), covering both linting and formatting out of the box. There’s no separate “make sure the linter and formatter agree” step, because they’re the same tool applying one consistent understanding of the code.

Why it’s fast

ESLint and Prettier are both written in JavaScript and run on Node.js. Biome is written in Rust and compiled to a native binary, which — combined with parsing each file only once for both linting and formatting, instead of running two separate tools that each re-parse the file independently — gives it a substantial speed advantage on large codebases. For a small project the difference is unlikely to matter; for a large monorepo running lint and format checks in CI on every commit, the gap compounds.

This mirrors the broader trend covered in why Rust keeps winning for infrastructure and developer tooling: language-level performance matters most in tools that run constantly, in the background, on every file save or every CI run — exactly the profile of a linter and formatter.

Biome vs ESLint + Prettier

	ESLint + Prettier	Biome
Number of tools	Two, plus a compatibility package	One
Language	JavaScript (Node.js)	Rust, compiled binary
Config files	.eslintrc + .prettierrc (and more)	One biome.json
Plugin ecosystem	Large, mature, framework-specific	Smaller, built-in rule set
Rule customization	Extensive, via plugins	Growing, but narrower
Setup complexity	Higher — must reconcile two tools	Lower — one tool, one config

The plugin ecosystem is the real tradeoff. ESLint’s decade-plus head start means there’s a plugin for nearly any framework-specific or highly specialized rule a team might want; Biome’s built-in rule set covers the common cases well but doesn’t yet match that long tail. Teams with a highly customized ESLint setup — extensive framework-specific rules, custom plugins written in-house — are the ones most likely to find gaps; teams using ESLint and Prettier in a fairly standard configuration are the ones most likely to migrate painlessly.

Where it fits with the rest of the toolchain

Biome only handles linting and formatting — it isn’t a bundler, a test runner, or a package manager, so it sits alongside tools like Vitest for testing and npm, pnpm, or Yarn for dependency management rather than replacing them. It’s also independent of which JavaScript runtime a project uses: it works the same whether the project runs on Node.js or Bun, since it operates on source files directly rather than depending on runtime-specific APIs.

That narrow scope is deliberate. Rather than trying to be an all-in-one JavaScript toolchain, Biome focuses on doing the linting-and-formatting job well and quickly, leaving the rest of the toolchain to whatever a project already uses.

Migrating an existing project

Biome ships a migration command that reads an existing ESLint and Prettier configuration and generates an equivalent biome.json, translating as many rules as it can map directly. It won’t be a perfect one-to-one translation for a heavily customized setup — some ESLint plugin rules simply have no Biome equivalent yet — but for projects using mostly standard rule sets, the migration path is largely automated rather than a rules audit done by hand.

Because Biome and ESLint can technically coexist during a transition, a common approach is running Biome as the formatter first, keeping ESLint for linting temporarily, and only fully cutting over to Biome’s linter once its rule coverage has been checked against the project’s actual usage.

The takeaway

Biome merges linting and formatting into one fast, Rust-based tool with a single configuration file, aimed squarely at the friction of coordinating ESLint and Prettier as two separate systems. The tradeoff is a narrower plugin ecosystem than ESLint’s — fine for a fairly standard setup, a real gap for a codebase leaning on many specialized ESLint plugins. For most projects starting fresh, or for teams willing to migrate a standard configuration, the consolidation and the speed are a meaningful upgrade over running two separate tools.