Contexto
Encontrar código problemático (lint) e padronizar sua formatação (format) são dois problemas historicamente resolvidos por ferramentas separadas no ecossistema JavaScript. E é exatamente aí que Biome e a dupla ESLint + Prettier discordam sobre quantas peças móveis essa solução deveria ter. ESLint nasceu como ferramenta de lint, e formatação nunca fez parte do seu escopo original: esse papel é do Prettier, um projeto separado, com seu próprio arquivo de configuração, sua própria versão e seu próprio ciclo de release. Rodar os dois juntos historicamente exige uma camada extra de configuração — algo como eslint-config-prettier — só para desligar as regras de estilo do ESLint que entrariam em conflito com o que o Prettier já decide sozinho.
Biome nasceu depois, como resposta direta a essa fragmentação: um único binário, escrito em Rust, que faz lint e format com o mesmo parser e a mesma configuração, sem depender de dois projetos concordando sobre quem decide o quê. A tabela de fatos acima reflete só o pacote eslint. Prettier é instalado, versionado e tem sua própria licença e seu próprio número de downloads, que não aparecem nesses números porque é, de fato, um pacote separado do ESLint.
Quando escolher Biome
Biome compensa quando o time quer consolidar lint e format numa única ferramenta, com configuração mínima e velocidade de processamento que vem de ser compilado em vez de interpretado:
// biome.json
{
"linter": { "enabled": true },
"formatter": { "enabled": true, "indentStyle": "space" }
}
Um único arquivo cobre as duas responsabilidades, e como o mesmo motor faz lint e format, não existe a categoria inteira de bug de "o formatter desfez o que o linter pediu" que aparece quando duas ferramentas independentes disputam a mesma responsabilidade de estilo. Como o parser é compartilhado entre lint e format, Biome também consegue rodar as duas etapas numa única passada sobre a árvore sintática do arquivo, em vez de duas ferramentas lendo e reanalisando o mesmo código de forma independente — parte de onde vem o ganho de velocidade em bases de código grandes. O trade-off é maturidade de ecossistema: o conjunto de regras de lint do Biome, embora cresça a cada versão, ainda é menor do que o acervo de anos de plugins específicos de framework, biblioteca ou convenção de time que existe para o ESLint; então times com dependências fortes em regras muito específicas podem não encontrar equivalente pronto no Biome.
Quando escolher ESLint + Prettier
ESLint + Prettier compensa quando o projeto depende de plugins específicos — de um framework, de uma biblioteca ou de uma convenção de acessibilidade — que só existem no ecossistema ESLint, construído ao longo de muitos anos por uma comunidade muito maior:
// eslint.config.js
export default [
{ plugins: { "jsx-a11y": jsxA11y }, rules: { "jsx-a11y/alt-text": "error" } },
];
Esse plugin de acessibilidade é só um exemplo entre milhares publicados para o ESLint, cobrindo praticamente qualquer framework, padrão de código ou regra de negócio que um time queira impor automaticamente. Prettier, por sua vez, resolve formatação de forma isolada e amplamente adotada, com sua própria configuração e integração de editor já madura — mas justamente por ser um projeto à parte, ele não compartilha parser nem árvore sintática com o ESLint, então as duas ferramentas precisam de uma configuração explícita (como um preset que desativa regras de estilo do ESLint) para não brigarem sobre a mesma linha de código. A contrapartida de manter os dois é justamente ter duas ferramentas para configurar, atualizar e manter compatíveis entre si, o que Biome resolve consolidando em uma peça só, ao custo de um ecossistema de regras ainda em construção.
Veredito
Não é uma disputa de "mais rápido vence": Biome ganha em velocidade e simplicidade de configuração quase sempre, mas isso só importa se o conjunto de regras que ele já cobre for suficiente para o seu projeto. Para times que usam principalmente lint e format genéricos de JS/TS, sem uma pilha grande de plugins de framework específicos, Biome consolida duas ferramentas numa peça só sem perda perceptível. Para times que já dependem de um plugin de nicho do ecossistema ESLint — seja de acessibilidade, de um framework específico ou de uma convenção interna publicada como pacote — trocar de ferramenta significa primeiro confirmar se esse plugin específico tem equivalente no Biome, e não o contrário.