Componentes nativos em 2026: por que apaguei as bibliotecas de dropdown, tooltip e modal dos meus projetos

Resposta direta: em 2026 o navegador já entrega, de fábrica, quase tudo que eu antes instalava como biblioteca. Popover, tooltip ancorado, menu, modal e até o select estilizável viraram nativos, e o resultado é menos JavaScript, mais acessibilidade de graça e menos código para manter. Aqui no Studio Seu eu apaguei essas dependências dos projetos novos e só mantive JavaScript onde a interação é realmente complexa.

O que mudou nos componentes nativos do navegador

Durante anos eu abri todo projeto novo instalando as mesmas três coisas: uma biblioteca de dropdown, uma de tooltip e uma de modal. Era o custo de entrada para ter uma interface decente. Em 2026 esse custo simplesmente sumiu, e eu demorei um tempo para acreditar.

Três peças se encaixaram quase ao mesmo tempo: a Popover API, o CSS anchor positioning e o select customizável. Juntas, elas cobrem a maior parte do que uma biblioteca de UI fazia por mim.

Popover API: abrir e fechar sem uma linha de JavaScript

O atributo popover no elemento e o popovertarget no botão resolvem o ciclo inteiro: abre, fecha, joga o elemento na camada de topo, devolve o foco e fecha ao clicar fora, o famoso light dismiss. Ganhamos também os botões invocadores declarativos, com command e commandfor, que fazem essa ligação sem nenhum handler escrito à mão.

Na minha experiência, é aqui que mora o maior ganho. Quase todo problema de acessibilidade que eu já vi em menu customizado vinha de foco mal devolvido ou de tecla Esc ignorada. O navegador faz isso melhor do que eu faria manualmente, e sem cobrar um byte.

CSS anchor positioning: o fim do Floating UI na maioria dos casos

Ancorar um tooltip no botão certo era o tipo de problema que só se resolvia com JavaScript medindo a tela. O CSS anchor positioning virou Baseline em 2026, com suporte no Chrome 125 e superiores, no Firefox 132 e superiores e no Safari 18.2 e superiores, algo perto de 91% do tráfego global. Desde janeiro de 2026 eu também uso a regra @position-try, que descreve posições alternativas para quando o elemento não cabe do lado escolhido.

Traduzindo para o dia a dia do estúdio: aquele menu que precisava virar para cima quando estava perto do rodapé agora é uma regra de CSS, não um cálculo em JavaScript que quebra assim que o cliente adiciona um banner no topo.

O select finalmente virou um elemento de design

Essa é a mudança que eu mais esperava. Com appearance: base-select, o pseudo elemento ::picker(select) e o elemento selectedcontent, dá para desenhar o botão, a lista e cada opção do select de verdade, sem recriar componente nenhum. O suporte começou no Chrome e no Edge 134, chegou ao Safari 27, e a Mozilla segue prototipando atrás de flag no Firefox Nightly.

O detalhe que me convenceu a usar já: quem não tem suporte cai no select clássico, funcionando. É melhoria progressiva de verdade, não aposta.

O que eu ganhei apagando as bibliotecas

• Peso: em um site de marca de porte médio, saíram dezenas de kilobytes de JavaScript que existiam só para abrir e fechar coisas.
• Acessibilidade: foco, Esc, leitura por leitor de tela e camada de topo passaram a ser responsabilidade do navegador.
• Manutenção: menos dependência significa menos atualização urgente e menos quebra quando o framework muda de versão.
• Velocidade de entrega: um menu ancorado que levava meio dia agora leva minutos.

O que eu ainda não apago

Eu não sou purista. Continuo usando JavaScript quando a interação tem estado de verdade: combobox com busca e filtro, seleção múltipla com etiquetas, tabela com arrastar e soltar, editor de conteúdo. Também mantenho uma camada fina de JavaScript quando o projeto precisa medir interação ou orquestrar animação entre vários elementos.

A pergunta que eu faço antes de instalar qualquer coisa hoje é simples: isso é comportamento ou é estado? Comportamento de abrir, fechar e posicionar, o navegador resolve. Estado de dados, ainda é trabalho nosso.

Como eu migro um projeto que já existe

• Começo pelo mais barato: tooltips e menus simples de navegação.
• Troco modais informativos por dialog e popover, deixando os fluxos críticos por último.
• Coloco o select nativo estilizado em formulários secundários antes de encostar no checkout.
• Meço antes e depois: peso do JavaScript, tempo até a interface responder e erros de navegação por teclado.
• Só então removo a dependência do projeto, nunca no mesmo dia da troca.

Fiz exatamente isso em projetos do Studio Seu neste ano, e a parte mais difícil não foi técnica: foi combinar com o cliente que tirar código também é entrega.

Perguntas frequentes

Componentes nativos funcionam em navegadores antigos?

Funcionam com degradação. O select cai para o formato clássico e o popover aceita um fallback pequeno. Em nenhum dos casos o usuário fica sem acesso ao conteúdo.

Vale a pena refazer um site inteiro por causa disso?

Não. Eu troco por partes, quando já vou mexer naquela tela mesmo. Refação total raramente se paga.

Isso resolve acessibilidade sozinho?

Resolve boa parte do comportamento, não o resto. Contraste, ordem de leitura, rótulos e clareza de texto continuam sendo decisão de design.

O design não fica com cara de navegador?

Não, e esse é justamente o ponto. Agora dá para estilizar o componente real com CSS, mantendo o comportamento que o navegador garante.

O que eu levo disso

Passei anos achando que interface boa era questão de escolher a biblioteca certa. Hoje eu acho o contrário: a interface fica melhor quando eu escolho o que não instalar. Menos dependência, menos superfície de erro, mais tempo sobrando para a parte que ninguém automatiza, que é o desenho.

Se você tem um site cheio de menus, tooltips e modais herdados de outra época, vale sentar comigo e olhar o que dá para apagar. Costuma ser mais do que o time imagina, e o ganho aparece já na primeira medição.