Biome: The 100x Faster ESLint + Prettier 2026

Two Tools, One Problem

Every JavaScript project runs two tools for code quality: ESLint for linting and Prettier for formatting. They're both excellent, but the combination has friction:

• Configuration conflict — ESLint and Prettier disagree on formatting, requiring eslint-config-prettier to disable overlapping rules
• Two config files — .eslintrc.js + .prettierrc (or their dozen supported formats)
• Two plugin ecosystems — Different plugin APIs, different extension mechanisms
• Slow — ESLint parses your code in JavaScript, which is inherently slower than native alternatives
• Two CI steps — Separate lint and format checks

Biome replaces both with a single, Rust-powered tool that's 100x faster. Here's why teams are switching.

What Is Biome?

Biome is an open source toolchain for web projects. It provides a formatter (replacing Prettier), a linter (replacing ESLint), and more — all in one binary written in Rust.

• License: MIT + Apache 2.0
• Language: Rust
• Replaces: ESLint + Prettier (and partially TypeScript compiler checks)
• Supports: JavaScript, TypeScript, JSX, TSX, JSON, CSS, GraphQL
• GitHub stars: 15K+

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

# Format + lint in one command
npx biome check --write .

Speed Benchmarks

We benchmarked on a real-world Next.js project (500 files, 45K lines of code):

Formatting

Tool	Time	vs Prettier
Prettier	4.2s	baseline
Biome format	0.035s	120x faster

Linting

Tool	Time	vs ESLint
ESLint	12.5s	baseline
Biome lint	0.12s	104x faster

Combined (Format + Lint)

Tool	Time	vs ESLint + Prettier
ESLint + Prettier	16.7s	baseline
Biome check	0.15s	111x faster

These aren't synthetic benchmarks — they're real projects with real codebases. The speed difference is shocking because Biome processes everything in Rust with parallel execution, while ESLint and Prettier run in single-threaded Node.js.

CI Impact

For a team running lint + format checks on every PR:

Setup	CI Time	Monthly CI Minutes (100 PRs)
ESLint + Prettier	17s	28 min
Biome	0.15s	0.25 min

That's a 99% reduction in CI time for code quality checks.

Feature Comparison

Linting Rules

Category	ESLint	Biome
Core JavaScript	280+ rules	200+ rules
TypeScript	100+ (via @typescript-eslint)	50+ (built-in)
React/JSX	80+ (via eslint-plugin-react)	40+ (built-in)
Accessibility	30+ (via eslint-plugin-jsx-a11y)	20+ (built-in)
Import sorting	eslint-plugin-import	Built-in
Custom rules	✅ (plugin API)	❌ (not yet)
Auto-fix	Partial	✅ (most rules)

Biome covers ~75% of the ESLint rules most projects actually use. The missing 25% are mostly niche rules from specialized plugins.

Formatting

Feature	Prettier	Biome
JavaScript/TypeScript	✅	✅
JSX/TSX	✅	✅
JSON	✅	✅
CSS/SCSS	✅	✅
HTML	✅	❌ (planned)
Markdown	✅	❌ (planned)
GraphQL	✅	✅
YAML	✅	❌ (planned)
PHP, Ruby, etc.	Via plugins	❌
Prettier compatibility	N/A	97%+ match

Biome's formatter produces output that's 97%+ identical to Prettier. The remaining differences are intentional improvements (better line-breaking decisions in some edge cases).

Migration Guide

Step 1: Install Biome

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

This creates a biome.json configuration file.

Step 2: Migrate ESLint Rules

Biome provides a migration command that reads your ESLint config and generates equivalent Biome rules:

npx biome migrate eslint --write

This reads your .eslintrc.* and updates biome.json with matching rules. Rules that Biome doesn't support are listed so you can decide whether to drop them or find alternatives.

Step 3: Migrate Prettier Config

npx biome migrate prettier --write

This reads your .prettierrc and translates settings (tab width, semicolons, quotes, etc.) into Biome configuration.

Step 4: Update Scripts

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

Step 5: Update CI

# Before
- run: npx prettier --check .
- run: npx eslint .

# After
- run: npx biome ci .

The biome ci command runs both formatting and linting checks, failing on any issues (without auto-fixing).

Step 6: Remove Old Dependencies

npm uninstall eslint prettier eslint-config-prettier eslint-plugin-react \
  @typescript-eslint/parser @typescript-eslint/eslint-plugin \
  eslint-plugin-import eslint-plugin-jsx-a11y

That's typically 8-15 packages removed, replaced by a single @biomejs/biome.

Step 7: Remove Old Config Files

Delete:

• .eslintrc.js / .eslintrc.json / .eslintrc.yml
• .prettierrc / .prettierrc.js / .prettierrc.json
• .eslintignore
• .prettierignore

Configuration

Biome uses a single biome.json file:

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

One file. No plugins to install. No conflicts to resolve.

IDE Integration

VS Code

Install the Biome VS Code extension. It provides:

• Real-time linting diagnostics
• Format on save
• Quick fixes and code actions
• Import sorting

// .vscode/settings.json
{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "quickfix.biome": "explicit",
    "source.organizeImports.biome": "explicit"
  }
}

JetBrains (WebStorm, IntelliJ)

Biome has a JetBrains plugin with equivalent functionality.

What Biome Can't Do (Yet)

Be honest about the gaps:

1. Custom lint rules — ESLint's plugin API lets you write custom rules. Biome doesn't support this yet (planned via GritQL).
2. HTML/Markdown formatting — Prettier handles these; Biome doesn't yet.
3. Non-JS/TS languages — Prettier supports PHP, Ruby, Java, and more via plugins. Biome is JavaScript/TypeScript focused.
4. Ecosystem plugins — No equivalent to eslint-plugin-tailwindcss, eslint-plugin-testing-library, etc.

If you rely heavily on specialized ESLint plugins (Tailwind class sorting, testing library rules, etc.), you may need to keep ESLint for those specific rules while using Biome for everything else. They can coexist.

When to Switch

Switch Now If:

• Your ESLint config is mostly recommended rules — Biome covers these
• CI speed matters — 100x faster checks
• You want simpler tooling — one tool, one config file
• You're starting a new project — no migration cost

Wait If:

• You depend on specialized ESLint plugins with no Biome equivalent
• You format HTML, Markdown, or YAML with Prettier — Biome doesn't support these yet
• Your team has invested heavily in custom ESLint rules

Gradual Migration

You can adopt Biome incrementally:

1. Start with formatting only — Replace Prettier with Biome formatter
2. Add import sorting — Replace eslint-plugin-import
3. Enable linting — Migrate ESLint rules gradually
4. Remove ESLint — Once all rules are covered

Why Biome Matters for Developer Tooling in 2026

The JavaScript ecosystem has a long history of fragmented tooling. For years, developers accepted a combination of ESLint, Prettier, and various configuration glue as the inevitable cost of writing quality code. Biome challenges this assumption directly by offering a single, coherent tool that eliminates the friction between linting and formatting.

The timing matters because modern JavaScript codebases are growing in complexity. TypeScript adoption has crossed 70% among professional developers. Monorepos with dozens of packages running lint and format checks on every commit are common. At that scale, shaving 100x off code quality checks has a real compounding effect on developer productivity. A team of ten developers running checks dozens of times per day reclaims meaningful hours every week.

Beyond raw speed, Biome's unified configuration model reduces cognitive overhead. Maintaining separate configs for ESLint and Prettier — including the glue packages required to prevent them from conflicting — is a maintenance burden that accumulates over time. Biome replaces this with a single biome.json that governs both formatting and linting rules. New team members have one file to understand instead of three or four.

The Rust foundation also has long-term implications. As JavaScript projects grow and TypeScript compiles more complex type hierarchies, tools written in interpreted languages face performance ceilings that Rust-based tools don't encounter. Biome's architecture positions it well for the increasingly complex codebases of 2026 and beyond.

How to Choose Between Biome and ESLint for Your Team

The decision to migrate to Biome depends on your project's specific characteristics, not just the headline benchmark numbers.

If your codebase relies heavily on a standard set of ESLint rules — the recommended presets from @typescript-eslint and eslint-plugin-react — Biome is likely a complete replacement today. These rules represent the bulk of what most projects actually enforce, and Biome covers them with built-in equivalents. The migration command (biome migrate eslint --write) automates the translation, making the switch low-risk.

The picture changes when specialized ESLint plugins are involved. Teams using eslint-plugin-tailwindcss for class ordering, eslint-plugin-testing-library for test quality, or eslint-plugin-security for security patterns will find that Biome has no equivalents for these niche rules. The practical approach in this case is a hybrid setup: Biome handles formatting and the core linting rules, while ESLint runs only the specialized plugins. This splits the tooling but preserves the most valuable 95% of Biome's performance benefits.

Team familiarity also matters. Prettier's configuration model (print width, tab width, quote style) maps cleanly to Biome's formatter settings, and the biome migrate prettier --write command handles this translation automatically. Engineers who have strong opinions about Prettier's output style will find Biome's 97%+ compatibility reassuring — the visual difference in formatted code is minimal.

For new projects starting in 2026, the calculation is straightforward: Biome should be the default choice. There is no existing configuration to migrate, no habits to change, and no legacy plugins to preserve. Starting with Biome means starting with a faster, simpler, more maintainable toolchain.

Common Pitfalls When Migrating to Biome

The migration from ESLint and Prettier to Biome is generally smooth, but a few patterns catch developers off-guard.

The most common issue is incomplete rule migration. biome migrate eslint translates the rules it can and reports the ones it cannot. Developers sometimes skip reviewing these unmigrated rules, then discover later that expected errors are no longer being caught. After running the migration command, review the output carefully and decide explicitly whether to drop each unmigrated rule, find a Biome equivalent, or keep ESLint for that specific plugin.

Formatting disagreements in early PRs are predictable. Even with 97% Prettier compatibility, the 3% of cases where Biome formats differently can produce noisy diffs in the first commit after migration. The cleanest approach is to run biome format --write . on the entire codebase as a single migration commit before any other changes. This establishes a clean baseline and prevents individual feature PRs from containing unrelated formatting changes.

Editor configuration needs attention on both sides. VS Code's editor.defaultFormatter setting must point to biomejs.biome rather than esbenp.prettier-vscode. Teams with shared .vscode/settings.json files should update this setting and remove any Prettier-specific configuration before the migration goes live. Developers who forget this step end up with Biome running in CI but Prettier running locally — a confusing inconsistency that produces different formatting in different environments.

Pre-commit hooks that invoke ESLint and Prettier directly need to be updated to biome check --write. Tools like lint-staged and husky just need their command targets updated — the hook infrastructure itself remains the same.

For teams building AI-assisted development workflows, Biome's fast feedback cycle pairs well with tools like those covered in Best Open Source Alternatives to GitHub Copilot 2026. The faster your linting runs, the tighter the feedback loop between AI-generated code suggestions and quality validation. Teams evaluating their broader developer tooling choices may also find Best Open Source AI Coding Assistants 2026 useful context for building a modern, fast development environment.

Conclusion

Biome is the most compelling open source alternative to the ESLint + Prettier combination. The 100x speed improvement isn't a marginal gain — it fundamentally changes developer experience. Instant formatting, instant linting, instant CI checks.

The ecosystem gaps are real but shrinking. For most projects in 2026, Biome covers enough rules to be a full replacement. For the rest, it can run alongside ESLint for the specific plugins you need.

If you're evaluating your team's overall approach to open source tooling, understanding how open core licensing works can help you make better decisions about which tools to adopt long-term — Biome's permissive MIT + Apache 2.0 dual license makes it one of the least restrictive options in the ecosystem.

Compare Biome with ESLint and Prettier on OSSAlt — see deployment guides, community metrics, and migration resources.