Overview

Pick Biome for any new TypeScript or JavaScript project in 2026 where one tool that lints and formats with a single config is the win. Pick ESLint plus Prettier when the codebase relies on rule plugins Biome does not yet cover (framework-specific, accessibility-deep, custom organizational rules) or when the migration cost outweighs the speedup. The split is concrete: Biome owns “greenfield projects and teams that hate config sprawl”; ESLint plus Prettier owns “established codebases with rule depth and migration risk.”

When Biome wins

Biome is the right pick when speed, single-binary simplicity, and zero plugin config matter.

  • One binary, two jobs: biome lint and biome format cover what ESLint plus Prettier did, with one config file (biome.json). The transformer pipeline is shared.
  • Speed: Biome is written in Rust and runs 10 to 50 times faster than ESLint plus Prettier on the same codebase. A 200k-LoC repo lints in 1 to 2 seconds.
  • No plugin coordination: no eslint-config-prettier, no eslint-plugin-prettier, no version-matrix problems between formatter and linter.
  • Sensible defaults: the rules ship opinionated and aligned with idiomatic TypeScript. Most teams write a 30-line biome.json and never touch it again.
  • Editor integration: official extensions for VS Code, Zed, JetBrains. Fast enough to run on save without delay.
  • LLM agents pattern-match Biome well: one config, fewer surfaces, predictable output.

When ESLint plus Prettier wins

ESLint plus Prettier is the right pick when the rule ecosystem or the migration cost is decisive.

  • Plugin depth: eslint-plugin-react, eslint-plugin-jsx-a11y, eslint-plugin-import, eslint-plugin-jest, eslint-plugin-vue. Biome covers the basics; the long tail still belongs to ESLint.
  • Custom rules: an org-specific lint rule (no internal console.error outside lib/log) is a one-file ESLint plugin. Biome supports custom rules via GritQL but the catalog is younger.
  • Existing investment: a codebase with a 200-line .eslintrc.js plus a CI gate is not worth migrating unless lint speed is hurting daily work.
  • Framework-specific lint: Next.js ships eslint-config-next. Nuxt, Astro, and others ship Prettier and ESLint configs. Biome support is catching up but lags.
  • Accessibility-deep rules: eslint-plugin-jsx-a11y has 30+ rules. Biome’s a11y rules are present but smaller. See accessibility equivalents.
  • Format-only-with-Prettier users: Prettier’s plugin ecosystem (Tailwind class sorting, Astro, Markdown, YAML) is broader than Biome’s.

Trade-offs at a glance

DimensionBiomeESLint + Prettier
ToolsOne binaryTwo tools, glue config
Speed10 to 50x fasterBaseline
Config filesbiome.json.eslintrc, .prettierrc, glue
Plugin ecosystemGrowingLargest in 2026
Custom rulesGritQL, newerMature plugin API
Framework configsSmaller catalogNative for every major framework
Format supportJS, TS, JSX, JSON, CSS, GraphQLJS, TS, plus Prettier plugins
Editor experienceFast on-saveAcceptable; slower on big files
MonorepoSingle config or per-packagePer-package configs, glue
Migration codemodbiome migrate eslintNative
LLM agent outputSmall surface, predictableLarge surface; more idioms to know
LicenseOpen source (MIT, Apache 2.0)Open source (MIT)

Migration cost

ESLint plus Prettier to Biome is mostly automated for greenfield-shaped repos. Established repos with deep rule libraries cost more.

  • Run biome migrate eslint and biome migrate prettier. These import rules and format options into biome.json. The output covers 80 to 90 percent of typical configs.
  • Drop eslint, prettier, eslint-config-prettier, eslint-plugin-prettier from package.json. Remove the per-plugin packages Biome already covers.
  • Audit remaining ESLint plugins: if you depend on eslint-plugin-react-hooks exhaustive-deps or a custom org plugin, you keep ESLint for that subset. Most teams either drop the plugin or run a tiny ESLint config alongside Biome.
  • Plan one engineer-day per 50k LoC for a clean repo; one engineer-week for a repo with deep custom rules and CI gates that rely on ESLint output format.
  • Pre-commit hooks: swap lint-staged commands from eslint --fix and prettier --write to biome check --apply. See github.

Recommendation

  • New TypeScript or JavaScript project in 2026: Biome.
  • Existing project, team happy, lint speed not painful: stay on ESLint plus Prettier. Migration is not free.
  • Next.js project that relies on eslint-config-next: stay on ESLint until Biome’s Next.js story matures, or run both with Biome doing formatting only.
  • React project with deep a11y lint requirements: ESLint plus eslint-plugin-jsx-a11y. Biome covers the basics.
  • Monorepo with consistent style across many packages: Biome; one config, one binary, fast.
  • Library author publishing to npm: Biome; smaller dev-dependency footprint for contributors.