Baseline: O Segredo para Enviar Muito Menos JavaScript

Baseline: O Segredo para Enviar Muito Menos JavaScript

Lembra dos bons tempos do jQuery? Você jogava um arquivo de 90KB no projeto e, de repente, `$(document).ready()` fazia tudo parecer incrivelmente suave. Depois ficamos mais espertos, dividimos nossos bundles e trocamos o jQuery por React, Vue e um armário cheio de micro-bibliotecas para cada coisinha.

Mas aqui está o que eu pego fazendo o tempo todo: alcançar por uma biblioteca de 20KB para formatar datas quando o navegador que eu estou mirando literalmente entrega uma API que faz a mesma coisa. De graça. Sem requisição de rede. Sem atualização de versão. Sem manutenção futura.

É aqui que o **Baseline** entra.

Se você ainda não ouviu falar, Baseline é uma iniciativa apoiada pelo W3C que nos dá um rótulo simples e universal: "quando posso usar esta funcionalidade com segurança?" Ele responde à pergunta mais irritante do desenvolvimento web com uma só palavra: **hoje**. E ao ajudar você a identificar o que a própria plataforma web já consegue fazer, Baseline pode reduzir drasticamente o JavaScript que você envia. Vamos ver como.

O que é Baseline, na Prática?

Baseline é um entendimento compartilhado sobre o suporte a navegadores entre todos os principais: Chrome, Edge, Firefox, Safari e Opera. Em vez de verificar uma matriz de "funciona em 97% dos navegadores", Baseline diz se uma funcionalidade está **disponível** (funciona nos navegadores atuais) ou **recém-disponível** (acabou de chegar nas versões mais recentes). A ideia é eliminar as suposições.

Pense nele como o "caniuse, mas com um veredito mais amigável". Quando uma funcionalidade se torna Baseline, significa que todos os navegadores no ecossistema comum a suportam. Esse é o seu sinal verde.

E a melhor parte? Baseline já está integrado em lugares que você provavelmente já usa. Visite as tabelas de compatibilidade do MDN, procure por uma funcionalidade, e você verá um selo do Baseline bem ao lado. Ou confira o [web.dev/baseline](https://web.dev/baseline) para um painel do que já está pronto hoje.

Por Que Isso Importa para o Tamanho do Seu Bundle

A lacuna entre "você precisa de uma biblioteca para isso" e "o navegador faz isso" continua diminuindo. A cada ano, os navegadores adicionam APIs que costumavam exigir polyfills, bibliotecas auxiliares e funções utilitárias. Se você ainda está enviando `moment-timezone` para cálculos de fuso horário ou `lodash` para `_.debounce()`, você está pagando por algo que a plataforma já fornece — tanto em bytes quanto em complexidade.

Vou te mostrar três exemplos práticos de como Baseline pode ajudar a cortar peso morto.

Cenário 1: Formatação de Datas Sem a Dependência de 50KB

Certa vez trabalhei em um projeto que importava `date-fns` só para formatar algumas datas em um painel. O aplicativo inteiro era um painel estático. Estávamos enviando 16KB de funções localizadas para renderizar strings como "9 de ago. de 2026".

Mas aqui vai um experimento: abra o console do seu navegador agora e digite:

```js
new Intl.DateTimeFormat('pt-BR', { dateStyle: 'full' }).format(new Date())
```

Pronto. **Sem importação, sem npm install, sem fixação de versão.** O objeto `Intl` é uma funcionalidade Baseline há anos. Ele lida com formatação específica por localidade, fusos horários, até mesmo tempo relativo estilo date-fns com `Intl.RelativeTimeFormat`.

Quer eliminar o bundle inteiro? Mapeie suas funções do date-fns para suas equivalentes nativas:

- `format` → `Intl.DateTimeFormat`
- `formatDistance` → `Intl.RelativeTimeFormat`
- `parseISO` → `Date.parse()` (ou `new Date()` com cuidado)
- `zonedTimeToUtc` → `Intl` com a opção `timeZone`

Sim, existem casos extremos, mas para 90% dos projetos, a API nativa do Intl dá conta. E ela está disponível no Baseline, então todo navegador moderno a suporta.

Cenário 2: Substituindo o Lodash pelo DOM

Ainda vejo `lodash.debounce` em alguns códigos. Cinco quilobytes para forçar uma função a esperar um pouco antes de executar. Mas o navegador já tem isso embutido:

```js
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
```

Ou, se você é preguiçoso como eu, um simples `setTimeout` num event listener funciona bem para a maioria dos casos. O mesmo vale para `_.throttle`, `_.clamp`, `_.range` — tudo com apenas umas linhas de JavaScript puro.

Mas vai mais fundo. Já usou `_.forEach`? O protótipo do Array tem `forEach`, `map`, `filter`, `reduce` — todos Baseline. `_.get` para acessar propriedades aninhadas com segurança? Optional chaining é uma funcionalidade Baseline desde 2020. `_.unique`? Isso é só `Set`.

O próprio DOM é uma mina de ouro: `classList.toggle()` substitui `_.toggleClass`, `Element.matches()` substitui seletores como `_.is()`, e o `IntersectionObserver` nativo substitui bibliotecas inteiras de scroll-spy. Na próxima vez que estiver para adicionar uma dependência, pergunte a si mesmo: "Isso é só um wrapper chique para algo que `document.querySelectorAll` já me dá?"

Cenário 3: Requisições HTTP Sem o Axios

O Axios é uma biblioteca linda, mas em 2026, a API nativa `fetch` já é Baseline e lida com quase todos os casos de uso. Streaming? `fetch` suporta `response.body.getReader()`. Autenticação? Você pode definir headers, credenciais e interceptores com um pequeno wrapper. Abortar? Isso é `AbortController`, também Baseline.

Para um projeto pequeno, eu substituí o axios inteiramente por um helper de 20 linhas:

```js
async function request(url, options = {}) {
const res = await fetch(url, {
headers: { 'Content-Type': 'application/json', ...options.headers },
signal: options.signal ?? (options.timeout && AbortSignal.timeout(options.timeout)),
...options,
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
```

Sem npm, sem o excesso de node_modules, sem avisos de dependências circulares. Apenas rápido, nativo e confiável.

Como Auditar Suas Dependências Usando Baseline na Prática

Você ficou convencido, e agora? Aqui está um processo prático que você pode fazer esta tarde.

1. Liste Suas Dependências de Runtime

Execute `npm ls --production` ou simplesmente olhe seu `package.json`. Destaque qualquer coisa que não seja seu framework ou uma biblioteca de gerenciamento de estado. Esses pequenos pacotes utilitários são os principais alvos.

2. Verifique Cada Uma Contra o Baseline

Para cada biblioteca na sua lista, faça duas perguntas:

- Que problema isso resolve?
- Posso resolver isso com uma API da web que está disponível no Baseline?

Pesquise no MDN pela funcionalidade. Se você vir o selo verde "Baseline available", está tudo bem. Se vir "Newly available" e você só mira em navegadores modernos, ainda vale considerar. Se for vermelho "Limited", talvez mantenha a biblioteca por enquanto.

Uma dica rápida: abra as ferramentas de desenvolvedor no Chrome, Safari ou Firefox e teste a API diretamente. Se funcionar sem nenhuma flag, é um ótimo sinal.

3. Grepie Seu Código por Sinais Característicos

Procure por padrões como `import * as _ from 'lodash'`, `from 'date-fns'`, `from 'axios'` ou `from 'jquery'`. Depois observe com que frequência essas funções são realmente usadas. Às vezes você descobre que usa apenas três métodos de uma biblioteca de 200 métodos. Isso é uma oportunidade clara.

4. Substitua e Compare

Faça a migração uma biblioteca por vez. Mantenha um PR separado para medir a mudança no tamanho do bundle. Use o relatório de tamanho da sua ferramenta de build ou simplesmente verifique o tamanho do arquivo nas devtools. Eu recomendo rodar o Lighthouse antes e depois. Ver aquele "tempo de execução do JavaScript" cair é uma sensação maravilhosa.

O Lado Humano de Enviar Menos JavaScript

Por que nos importamos, além da satisfação com o ego de ter um bundle menor? Porque JavaScript é o recurso mais caro que enviamos aos navegadores. Cada byte precisa ser baixado, analisado, compilado e executado. Cada API economizada significa uma carga mais rápida para alguém num Android barato com uma conexão 3G instável. Nem todo mundo tem um MacBook Pro conectado a fibra óptica.

Enviar menos JavaScript também significa menos sobrecarga mental para você, desenvolvedor. Cada dependência é uma potencial vulnerabilidade de segurança, um potencial headache de migração e uma potencial fonte de bugs estranhos quando seu mantenedor decide se aposentar. As APIs nativas são mantidas pelos fabricantes dos navegadores, o que significa que serão atualizadas, documentadas e suportadas por anos.

E há um benefício mais profundo: você começa a entender a própria plataforma web. Quando você usa `Intl`, `URL`, `Promise`, `Map`, `Optional Chaining` e `fetch` diretamente, você se torna um desenvolvedor web melhor. Você não é apenas um consumidor de abstrações; é um construtor que conhece a textura da madeira.

Existem Ressalvas? Sim. Não Seja Ingênuo.

Baseline não é uma varinha mágica. Algumas APIs avançadas ainda são muito novas para estarem disponíveis no Baseline em todos os lugares. Por exemplo, a Popover API ou a View Transitions API são "recém-disponíveis" mas não estão totalmente implementadas em todos os navegadores. Se você está construindo um site público para um público amplo, talvez queira esperar ou fornecer um fallback gracioso.

Além disso, eliminar uma biblioteca nem sempre significa escrever menos código. Às vezes você tem que escrever um pouco mais de JS puro para alcançar o mesmo comportamento. Mas ei, umas linhas extras do seu próprio código são mais manuteníveis do que uma biblioteca utilitária monolítica que você não entende totalmente.

E finalmente, não se torne um "fanático por APIs nativas". Se uma biblioteca muda completamente sua produtividade e facilita sua vida, use-a. O objetivo do Baseline não é envergonhar você por usar bibliotecas chiques. É ajudar você a fazer trocas informadas. Apenas não envie `safe-password-generator` quando `crypto.getRandomValues()` já é Baseline desde 2015.

Bônus: Como Manter-se Atualizado com o Baseline

A plataforma web evolui rapidamente. Para ficar por dentro do que está se tornando disponível no Baseline, eu faço duas coisas:

1. Verifico o painel **Web Platform Features** no [web.dev/baseline](https://web.dev/baseline) uma vez por mês, mais ou menos.
2. Leio a seção de **notícias do MDN Baseline**, que lista funcionalidades recém-disponíveis a cada mês.

Você também pode seguir o repositório GitHub do grupo de comunidade WebDX em [github.com/web-platform-dx/baseline](https://github.com/web-platform-dx/baseline). É lá que a mágica acontece.

Perguntas Frequentes

O que exatamente significa "disponível no Baseline"?

Significa que uma funcionalidade é suportada nas versões atuais e recentes de todos os principais navegadores — Chrome, Edge, Firefox, Safari e Opera. Você pode usá-la sem polyfill ou fallback para esses navegadores.

Baseline é o mesmo que "caniuse.com"?

Não, mas estão relacionados. O Caniuse te dá tabelas de compatibilidade detalhadas, incluindo versões mais antigas. O Baseline destila esses dados em um rótulo simples "pronto ou não pronto". Ele também garante que a informação esteja contextualizada — só porque algo funciona no Chrome 120 não significa que funciona no Safari 12.

E se eu ainda precisar suportar um navegador mais antigo como o IE11?

O IE11 está morto, e mesmo antes, era uma exceção. O Baseline exclui explicitamente navegadores legados como o IE11. Se você deve suportar ambientes tão antigos, precisará verificar tabelas individuais e talvez incluir polyfills para as APIs que escolher. Mas em 2026, é seguro perguntar por que você ainda suporta o IE11 — seus usuários são os que decidem ficar com tecnologia antiga, e você está pagando o preço.

Como posso convencer minha equipe a começar a usar o Baseline?

Mostre os números. Escolha uma dependência, estime o tamanho do bundle e o custo de manutenção, depois demonstre a substituição nativa num protótipo rápido. Eu fiz isso com o `lodash` num emprego anterior, e quando meu líder viu a diferença — uma utilidade de 5KB substituída por duas linhas de JS puro — ele foi convencido. Aponte-os também para este post. 😉

Conclusão

Baseline não é apenas mais uma ferramenta de compatibilidade — é uma mudança de mentalidade. Em vez de perguntar "qual biblioteca devo usar para isso?", você começa a perguntar "o que o navegador já pode fazer por mim?". No momento em que você faz essa mudança, a inchação do JavaScript começa a derreter.

Seus usuários recebem um site mais rápido. Seu eu do futuro recebe um codebase mais limpo. E a web fica um pouquinho mais leve para todos.

Agora, vá e abra suas devtools, olhe o bundle do seu projeto e veja o que pode cortar. Seu navegador provavelmente já está esperando com a resposta.