Dependências de frontend envelhecem de um jeito curioso. Algumas continuam no projeto porque resolvem um problema difícil. Outras permanecem porque, quando foram instaladas, o navegador ainda não tinha uma alternativa confiável. Anos depois, o pacote segue no bundle, o lockfile recebe atualizações e ninguém pergunta se a plataforma já assumiu aquele trabalho.
Baseline ajuda a fazer essa pergunta com menos achismo. O projeto organiza informações de compatibilidade da plataforma web e indica quando um recurso está disponível nos principais navegadores. Ele não manda apagar bibliotecas; oferece um ponto de partida para avaliar se ainda precisamos delas.
Newly e Widely Available dizem coisas diferentes
Um recurso Baseline Newly Available já está interoperável no conjunto principal de navegadores, mas versões recentes ainda podem não ter chegado a todo o público. Widely Available significa que passaram trinta meses desde essa interoperabilidade, oferecendo cobertura mais confortável para a maioria dos sites.
Essa classificação é mais útil do que decorar números de Chrome, Safari e Firefox. Mesmo assim, não substitui os dados do seu produto. Um sistema corporativo preso a uma versão antiga e um aplicativo voltado a usuários com navegadores atualizados podem tomar decisões diferentes diante do mesmo badge.
Audite por capacidade, não por preconceito
Comece pelas dependências entregues ao usuário e agrupe o que elas fazem: requisições HTTP, clonagem de dados, agrupamento de arrays, operações com conjuntos, diálogos, popovers, formatação internacional, datas e posicionamento de elementos. Depois procure a capacidade equivalente na plataforma e confira compatibilidade.
const copy = structuredClone(original);
const byCategory = Object.groupBy(
products,
(product) => product.category,
);
const sharedRoles = adminRoles.intersection(editorRoles);structuredClone, Object.groupBy e os métodos de Set ilustram funções que antes frequentemente puxavam helpers. Cada substituição precisa respeitar semântica. Clonar objetos com protótipos, agrupar com chaves especiais ou depender de uma API ainda recente no navegador mais antigo do público pode mudar o resultado.
Uma biblioteca entrega mais do que uma função
Trocar pacote por API nativa não é uma vitória se você reimplementar acessibilidade, normalização e casos extremos de forma pior. Um componente de dialog pode incluir gerenciamento de foco, fechamento por teclado, empilhamento e testes entre navegadores. O elemento nativo cobre parte importante do problema, mas a biblioteca talvez continue agregando comportamento necessário ao produto.
Compare o uso real, não a página inicial do pacote. Se a aplicação importa uma biblioteca inteira para duas operações já nativas, existe uma boa candidata. Se depende profundamente de uma abstração madura e testada, o tamanho isolado não conta a história inteira.
Meça o que chega à rede
package.json não revela sozinho o custo do cliente. Tree shaking pode remover boa parte de uma biblioteca; duplicação de versões pode fazer o oposto. Use o analisador do bundler, verifique bytes comprimidos, parse e execução. Uma dependência pequena que roda em toda interação pode custar mais do que um módulo maior carregado sob demanda.
- Liste apenas dependências de produção que entram no bundle.
- Identifique a capacidade usada e a alternativa da plataforma.
- Confira Baseline, sua matriz de navegadores e dados reais de acesso.
- Compare semântica, acessibilidade, testes e custo de manutenção.
- Remova uma candidata, meça a saída e rode os fluxos afetados.
Progressive enhancement evita a escolha binária
Quando uma API é útil, mas ainda não cobre todo o público, detecção de recurso permite oferecer a experiência moderna e manter um fallback. Polyfills também continuam válidos quando o custo é menor que manter uma biblioteca completa. O importante é não enviar a mesma solução duplicada para todos por tempo indefinido.
Defina uma data para revisitar decisões. A plataforma evolui, mas o bundle não emagrece sozinho. Uma auditoria trimestral curta costuma ser mais eficiente do que uma grande campanha de “zero dependências” que cria regressões e depois nunca se repete.
Menos JavaScript não é um placar moral. É menos código para transferir, analisar, executar, atualizar e confiar. Baseline ajuda a enxergar onde o navegador já pode carregar parte dessa responsabilidade. A remoção só vale quando o usuário mantém a compatibilidade e a equipe termina com menos trabalho, não apenas com menos uma linha no package.json.