Replacing ESLint and Prettier for Biome: 10x Faster, Zero Config

I've been running ESLint and Prettier on every project for years. Then Biome showed up promising to replace my entire linting and formatting stack with a single tool—written in Rust, 10x faster, with zero configuration required.

Sounded too good to be true. So I tested it properly: 3 months across 8 client projects, ranging from small Next.js apps to large React Native codebases. Here's what actually happened.

What Is Biome?

Biome is a single toolchain that combines linting and formatting. Think of it as ESLint + Prettier in one, but rewritten in Rust for speed. It was forked from Rome Tools after that project shut down, and it's been gaining serious traction in the JavaScript ecosystem.

The pitch is simple:

One tool instead of two
One config file instead of three (.eslintrc, .prettierrc, .prettierignore)
Significantly faster execution
Built-in support for TypeScript, JSX, JSON

I spend a lot of time waiting for linters. On my largest project (React Native app with 450 components), ESLint takes 38 seconds to lint the entire codebase. Pre-commit hooks slow down every commit. CI pipelines spend minutes on code quality checks.

If Biome could actually deliver 10x performance, that's worth investigating.

The Performance Claims: Testing "10x Faster"

I benchmarked three codebases of different sizes. All tests run on the same MacBook Pro M2, cold cache, measuring full lint + format operations.

Small Project (Next.js landing page, 45 files)

ESLint + Prettier: 3.2 seconds
Biome: 0.4 seconds
Result: 8x faster

Medium Project (E-commerce dashboard, 180 files)

ESLint + Prettier: 12.8 seconds
Biome: 1.1 seconds
Result: 11.6x faster

Large Project (React Native app, 450+ files)

ESLint + Prettier: 38.4 seconds
Biome: 2.9 seconds
Result: 13.2x faster

The claims are real. Biome is genuinely 8-13x faster in my testing. On larger codebases, the difference becomes dramatic.

For pre-commit hooks, this is transformative. Commits that used to pause for 5-10 seconds now complete instantly. I actually keep the pre-commit hooks enabled instead of bypassing them.

"Zero Config" Reality Check

The marketing says zero config. The reality is more nuanced.

For basic formatting and linting, yes—install Biome, run it, and it works out of the box. No configuration file needed. It comes with sensible defaults that cover 80% of what most teams want.

But if you're migrating from ESLint + Prettier with custom rules (and most established projects are), you'll need to configure Biome to match your existing code style. Otherwise, you're reformatting thousands of lines of code.

Here's what my typical biome.json looks like:

{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "suspicious": {
        "noExplicitAny": "warn",
        "noArrayIndexKey": "warn"
      },
      "complexity": {
        "noForEach": "off"
      }
    }
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "trailingCommas": "es5"
    }
  }
}

So yes, configuration is simpler than juggling ESLint and Prettier configs. But "zero config" is aspirational rather than practical for real projects.

Migrating from ESLint + Prettier

I've now migrated 8 projects. The process takes 30-90 minutes depending on codebase size and how many custom ESLint rules you have.

Step 1: Install Biome

npm install --save-dev --save-exact @biomejs/biome

Step 2: Initialize Config

npx @biomejs/biome init

This creates a basic biome.json with recommended settings.

Step 3: Match Your Current Style

Run Biome on one file and compare the output to your current formatting:

npx @biomejs/biome format --write src/App.tsx

Adjust biome.json until the output matches your Prettier style. Common adjustments:

Line width (I use 100, Biome defaults to 80)
Quote style (single vs double)
Trailing commas
Semicolons

Step 4: Migrate ESLint Rules

This is the tedious part. Biome doesn't support all ESLint rules yet. Check Biome's rules documentation and map your ESLint config.

For rules Biome doesn't support, you have three options:

Accept that the rule won't be enforced
Keep ESLint for those specific rules (defeats the purpose)
Wait for Biome to add support

I chose option 1 for most projects. The rules Biome lacks are generally nice-to-haves rather than critical.

Step 5: Update Scripts

Replace your package.json scripts:

{
  "scripts": {
    "lint": "biome lint ./src",
    "format": "biome format --write ./src",
    "check": "biome check --write ./src"
  }
}

The check command runs linting and formatting in one pass—very convenient for CI.

Step 6: Clean Up

Remove ESLint, Prettier, and all their plugins:

npm uninstall eslint prettier @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-config-prettier eslint-plugin-react eslint-plugin-react-hooks

Delete .eslintrc.js, .prettierrc, .prettierignore, .eslintignore.

Feels good.

What You Lose Migrating to Biome

Honesty time: there are trade-offs.

Missing ESLint Rules

Biome supports about 200 lint rules. ESLint has thousands. Some gaps I noticed:

No react-hooks/exhaustive-deps equivalent (this one hurts)
Limited accessibility linting
Fewer stylistic rules for edge cases
No custom plugin ecosystem

For most projects, this doesn't matter. But if you rely on niche ESLint plugins, check compatibility first.

Editor Integration Is Newer

The VS Code extension works well, but it's younger than ESLint/Prettier extensions. I hit occasional issues:

Format-on-save sometimes doesn't trigger
Error underlines occasionally lag
Restart VS Code to fix extension weirdness

These are minor annoyances, not blockers. The extension has improved significantly in the last few months.

Community and Resources

ESLint has 15 years of Stack Overflow answers, blog posts, and shared configs. Biome is 2 years old. When you hit a weird issue, there's less community knowledge to search.

What You Gain

The speed is the headline feature, but there are other benefits.

Simpler Dependency Tree

Before: 127 npm packages for ESLint + Prettier + plugins After: 1 package for Biome

Fewer dependencies means faster installs, smaller node_modules, and less supply chain risk.

One Tool, One Config, One Command

Running biome check --write handles both linting and formatting in a single pass. No more "run Prettier, then ESLint, then Prettier again because ESLint changed something."

Better Error Messages

Biome's error messages are clearer than ESLint's. Example:

ESLint: "Unexpected var, use let or const instead" Biome: "Don't use var for variable declarations. Use let or const instead. var is discouraged and can cause unexpected behavior."

More context, more helpful.

Native Performance

Written in Rust, compiled to native binaries. This matters more than I expected. Biome uses significantly less memory than Node-based tooling, which helps on memory-constrained CI runners.

Does It Live Up to the Hype?

After 3 months on 8 projects: mostly yes.

The performance is real. The developer experience is genuinely better. The migration path is straightforward for most projects.

I've kept Biome on 6 of 8 projects. The two I rolled back:

A project heavily dependent on eslint-plugin-jsx-a11y for accessibility linting
A React Native monorepo with complex custom ESLint rules

For new projects, I'm defaulting to Biome now. For existing projects, I evaluate case-by-case based on how many ESLint-specific rules they need.

When to Use Biome vs ESLint + Prettier

Use Biome if:

Starting a new project
Your ESLint config is mostly standard rules
You value performance and simplicity
You're okay with slightly fewer lint rules

Stick with ESLint + Prettier if:

You rely on niche ESLint plugins (accessibility, security, etc.)
You have extensive custom ESLint rules
You're resistant to tooling changes
You need maximum lint rule coverage

For most projects—especially modern web applications using React, Next.js, or Vue—Biome is the better choice in 2024.

Conclusion

Biome delivers on its core promise: dramatically faster linting and formatting with simpler configuration. The 10x performance claim is accurate (sometimes it's even faster). The "zero config" claim is slightly oversold, but configuration is still simpler than the ESLint + Prettier combo.

The trade-off is a smaller rule set and younger ecosystem. For most projects, this is an acceptable trade. The speed gains are immediately noticeable, and the simplified toolchain reduces cognitive overhead.

I'm not ripping out ESLint from every project, but for new work and mobile app development, Biome has become my default. The tooling keeps improving, and the performance advantage is substantial.

Planning to migrate your project to Biome? I've now done this migration 8 times and learned all the gotchas. If you'd like help ensuring a smooth transition—or discussing whether it's right for your codebase—get in touch.