ESLint and Prettier are the standard setup for JavaScript and TypeScript projects. They’re also, by the standards of modern tooling, notably slow. Not catastrophically slow — but slow enough that large monorepos spend meaningful CI time on formatting and linting, and that local lint-on-save can feel sluggish in bigger files.

Biome is the Rust-based alternative that consolidates both tools into one. It’s not the first attempt at this — Rome (the project Biome forked from) tried it first and stalled. The difference is that Biome is actually shipping, has an active maintainer community, and has reached a level of feature completeness where real projects are using it in production.

Here’s an honest look at the current state.

What Biome actually replaces

Biome handles:

  • Formatting: JavaScript, TypeScript, JSX, TSX, JSON, JSONC, CSS (beta). The output is similar to Prettier — opinionated, consistent, not configurable in most ways. That’s the point.
  • Linting: JavaScript and TypeScript. Over 200 rules, covering roughly 90% of what most teams use from ESLint. Rules are categorised by recommended, correctness, nursery (experimental), and so on.

What it doesn’t handle yet:

  • CSS linting (formatting works, linting is still incomplete)
  • Plugin system for custom ESLint rules (Biome rules are built-in only)
  • HTML formatting
  • Vue, Svelte, Astro component files (only the script blocks, not the full templates)

That last point matters for frontend frameworks. If your project is heavy on .vue or .svelte files, Biome won’t fully replace ESLint + Prettier yet. For TypeScript backend, React/Next.js, or general Node.js projects, the coverage is much more complete.

The performance difference

The benchmarks Biome publishes show 25-35x faster formatting than Prettier on a large codebase. In practice, “formatting an entire project” goes from a few seconds to milliseconds.

The more tangible impact is lint times. Running ESLint across a large TypeScript monorepo can take 20-40 seconds. Biome on the same codebase typically finishes in under two seconds. For CI pipelines that run on every PR, that compounds.

On local saves, the difference is most noticeable in large files. Biome’s format-on-save is fast enough to be genuinely imperceptible. ESLint with certain rule sets can cause a brief stutter in larger files — not terrible, but Biome just feels snappier.

Getting started

npm install --save-dev @biomejs/biome
# or
pnpm add -D @biomejs/biome

Then initialise a config:

npx biome init

This creates a biome.json in your project root. A minimal config looks like:

{
  "$schema": "https://biomejs.dev/schemas/1.9.0/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "semicolons": "always"
    }
  }
}

Format your project:

npx biome format --write .

Run the linter:

npx biome lint .

Or run both at once:

npx biome check --write .

The check command applies formatting and lint fixes that are safe to auto-apply. Non-auto-fixable issues are flagged for manual review.

Migrating from ESLint + Prettier

Biome has a migration command that reads your existing ESLint and Prettier configs and generates an equivalent Biome config:

npx biome migrate eslint --write
npx biome migrate prettier --write

This doesn’t cover everything — custom ESLint plugins won’t migrate automatically — but it handles the standard rulesets. After migration, run biome check and review the diff. The first run often surfaces a lot of formatting changes as Biome and Prettier have minor opinionated differences (trailing commas, parentheses in arrow functions, etc.).

The process for most straightforward projects is:

  1. Run the migration commands
  2. Apply the formatting changes as one commit (“migrate to Biome formatting”)
  3. Review lint warnings — some ESLint rules you had enabled may not have direct Biome equivalents
  4. Remove ESLint and Prettier from your dependencies
  5. Update CI scripts and editor config

Expect a few hours of cleanup in a medium-sized project. The main time sinks are edge cases where your ESLint config was doing something non-standard.

Editor integration

VS Code: install the official Biome extension from the VS Code marketplace. Set it as the default formatter for JS/TS files:

// .vscode/settings.json
{
  "[javascript][typescript][typescriptreact][javascriptreact]": {
    "editor.defaultFormatter": "biomejs.biome",
    "editor.formatOnSave": true
  }
}

For teams, commit a .vscode/settings.json and .vscode/extensions.json recommending the extension. It prevents the “I’m still using Prettier locally” drift that happens when you add a new tool but don’t update the team dev environment config.

JetBrains IDE support exists but is less polished. Neovim users have nvim-lspconfig support through Biome’s LSP server. The VS Code extension is the most complete integration.

Where the rough edges are

Honest assessment of where Biome isn’t quite there yet:

Rule coverage gaps. Roughly 10-15% of ESLint rules don’t have Biome equivalents. Many of these are obscure rules most teams have disabled anyway, but some projects rely on rules that are genuinely missing. Before committing to migration, run biome migrate eslint and check how many rules couldn’t be mapped.

Plugin ecosystem. ESLint has a vast plugin ecosystem: eslint-plugin-react, eslint-plugin-react-hooks, TypeScript ESLint, security plugins, and dozens more. Biome has no plugin system — all rules are built-in. React-specific hooks rules are included. TypeScript-specific rules are included. But niche domain-specific plugins you’ve built or pulled in from the ecosystem won’t migrate.

CSS tooling is incomplete. Biome formats CSS well, but the CSS linting is still in development. If you’re using stylelint for CSS, keep it alongside Biome for now.

Astro/Vue/Svelte support. Formatting for the script blocks in these files works, but the template syntax isn’t fully supported. For these frameworks, you’ll likely end up with Biome handling TypeScript files and Prettier handling the framework-specific files — which is messier than a clean replacement.

Is it ready for production?

For a TypeScript-heavy backend or a React/Next.js frontend: yes, Biome is ready. The tooling is stable, the VS Code integration is good, and the performance improvement is real. Teams shipping it report no significant regressions and noticeably faster CI.

For projects that rely heavily on custom ESLint plugins, or that use Vue/Svelte/Astro templates extensively: not quite yet. Keep watching; the project is moving fast and framework file support is actively being worked on.

The migration investment pays off quickly for large projects where linting is a meaningful portion of CI time. For small projects, the time-to-migrate might not be worth it yet — ESLint and Prettier work fine, and Biome will only keep getting better if you wait another six months.