O que é htmx 4.0
O htmx 4.0 é uma nova versão da biblioteca que permite criar interações web usando atributos HTML. Em vez de concentrar toda a experiência em um framework de componentes, você pode pedir requisições, trocas de conteúdo e ações do navegador diretamente na marcação.
O anúncio oficial da versão 4.0.0 foi publicado em 28 de agosto de 2026 pela Big Sky Software, organização responsável pelo projeto htmx. A versão chega como uma evolução do modelo conhecido, sem exigir que aplicações baseadas em htmx 2 sejam atualizadas imediatamente.
O interesse pela versão está ligado à tentativa de manter a simplicidade do HTML enquanto a biblioteca melhora sua base interna e suas extensões. O resultado é uma atualização relevante para quem trabalha com aplicações renderizadas no servidor, mas que merece testes antes de chegar a um ambiente crítico.
Como funciona
O htmx adiciona comportamento a elementos HTML por meio de atributos como hx-get, hx-post, hx-target e hx-swap. O navegador envia a requisição indicada e recebe uma resposta do servidor, normalmente um fragmento de HTML pronto para ser inserido na página.
Na versão 4, a implementação interna migrou de XMLHttpRequest para fetch(). Essa troca deve ser transparente para a maioria dos projetos, mas representa uma mudança importante para extensões e códigos que dependiam de eventos ou APIs ligados ao XHR.
A versão também altera a herança de atributos. Em htmx 4, atributos não são herdados automaticamente pelos elementos descendentes. Quando essa herança for desejada, ela precisa ser declarada de forma explícita, o que torna o comportamento mais previsível em telas grandes.
Pense no htmx como uma ponte entre HTML e respostas do servidor. O navegador continua responsável pela tela, enquanto o backend decide qual fragmento deve voltar.
Principais recursos
A versão 4 preserva o fluxo baseado em atributos, mas organiza melhor partes que cresceram ao longo da história do projeto. Isso inclui nomes de eventos mais consistentes e um conjunto maior de extensões para cenários interativos.
Entre os recursos que mais chamam atenção está o suporte nativo a morphing swaps, que compara estruturas e aplica mudanças de forma mais cuidadosa. Também há extensões para Server-Sent Events, WebSockets e uma solução de scripts chamada hx-live.
- Eventos padronizados: nomes como
htmx:beforeRequestpassam a seguir uma forma com fases, comohtmx:before:request. - Trocas morphing: atualizações podem preservar melhor partes existentes do DOM.
- Streaming: as extensões
hx-sseehx-wsatendem fluxos com eventos e WebSockets. - Scripts integrados:
hx-liveadiciona reatividade orientada ao DOM. - htmax.js: reúne htmx e extensões populares em um pacote único.
- Ferramenta de migração: o projeto oferece um verificador para encontrar incompatibilidades em templates e scripts.
Esses recursos não transformam o htmx em um framework de estado completo. A proposta continua sendo permitir interfaces dinâmicas com uma quantidade pequena de JavaScript escrito pelo time da aplicação.
Como começar: instalação ou acesso passo a passo
O requisito principal é ter um backend capaz de responder às requisições com HTML. Você também precisa de um navegador moderno e de uma estratégia para manter a versão do htmx controlada, especialmente em produção.
Para um teste rápido, a própria página oficial de lançamento mostra o uso do arquivo distribuído por CDN. Fixar a versão evita que uma alteração futura em uma URL genérica mude o comportamento do projeto sem revisão.
<script src='https://unpkg.com/[email protected]/dist/htmx.min.js'></script>Antes de alterar uma aplicação existente, rode o verificador de atualização sobre a pasta de templates. Ele aponta usos antigos de atributos, eventos e APIs que podem exigir revisão manual.
npx [email protected] upgrade-check -- ./templatesNão atualize a biblioteca em todas as telas de uma vez. Comece por uma rota representativa, valide os eventos e compare o comportamento em navegadores usados pelos seus clientes.
Exemplo prático
Imagine uma tela de suporte que precisa carregar uma saudação sem recarregar a página. O botão pode apontar para uma rota do backend e indicar onde a resposta deve aparecer.
<button hx-get='/api/saudação' hx-target='#resultado' hx-swap='innerHTML'>Carregar saudação</button>
<div id='resultado'></div>Ao clicar, o htmx faz a requisição para /api/saudação. Se o servidor responder com <p>Olá, desenvolvedor!</p>, esse fragmento ocupa o elemento identificado por resultado.
Em uma migração para a versão 4, o cuidado aparece quando o projeto escuta eventos antigos. Um listener para htmx:afterRequest deve ser revisado conforme a nova convenção htmx:after:request, sempre com testes que cubram sucesso e erro.
Separe o contrato do endpoint do código do navegador. Se a resposta HTML continuar estável, a migração da biblioteca fica mais fácil de testar e de reverter.
Comparação com alternativas
O htmx 4.0 não substitui todas as abordagens de frontend. A escolha depende de onde está a complexidade: no servidor, no navegador ou na sincronização de estado entre os dois.
| Abordagem | Quando faz sentido | Ponto de atenção |
|---|---|---|
| htmx 4.0 | Telas server-side com interações incrementais | Exige cuidado com eventos e herança na migração |
| fetch() manual | Poucas interações e controle direto do JavaScript | O time precisa organizar troca de DOM e estados |
| React ou Vue | Interfaces ricas com estado complexo no cliente | Aumentam a estrutura e a responsabilidade no frontend |
Em relação ao fetch() manual, o htmx oferece uma convenção pronta para selecionar alvos, trocar conteúdo e lidar com eventos. Isso reduz código repetido, mas também significa aceitar o modelo de resposta e ciclo de vida definido pela biblioteca.
Em relação a React ou Vue, o htmx costuma ser mais direto em páginas que já dependem do servidor para renderizar HTML. A vantagem diminui quando a aplicação precisa de um estado rico no cliente, edição offline ou uma experiência que se comporta como um aplicativo completo.
Pontos positivos e limitações
O principal ponto positivo é a continuidade do modelo HTML. Um desenvolvedor pode colocar a maior parte da regra de interação perto do elemento afetado, sem criar uma árvore inteira de componentes para uma mudança pequena.
Outro benefício é a evolução das extensões. Morphing swaps, streaming por SSE ou WebSockets e hx-live ampliam os cenários possíveis sem abandonar a ideia de respostas orientadas ao DOM.
A limitação mais importante é o custo de migração. Eventos foram reorganizados, a herança automática mudou e extensões próprias precisam ser verificadas por causa da troca interna para fetch().
Não trate uma aplicação que depende de eventos antigos como compatível só porque a página continua abrindo. Um listener quebrado pode afetar indicadores de carregamento, tratamento de erros e integrações silenciosamente.
Casos de uso reais
O htmx 4.0 combina bem com um painel administrativo em que filtros, tabelas e formulários precisam atualizar partes da tela. O servidor pode retornar apenas o fragmento alterado, reduzindo a necessidade de manter uma cópia completa dos dados no navegador.
Também é uma opção para portais de conteúdo com busca, comentários e formulários progressivos. O HTML continua sendo o contrato principal, e o time pode adicionar interações sem converter o site inteiro em uma SPA.
Aplicações internas com dados em tempo real podem avaliar as extensões de SSE ou WebSockets. Nesse caso, o benefício depende da arquitetura do backend, da política de reconexão e do volume de atualizações que a tela precisa receber.
- Times pequenos: menos infraestrutura de frontend para telas baseadas em servidor.
- Produtos CRUD: atualizações parciais para listas, filtros e formulários.
- Portais públicos: HTML como base e JavaScript apenas onde houver ganho claro.
- Dashboards operacionais: extensões de streaming quando o backend já oferece esse canal.
Dicas e boas práticas
A primeira prática é fixar a versão usada no projeto e registrar o motivo da atualização. Assim, o comportamento deixa de depender de uma URL flutuante e a equipe consegue reproduzir os testes.
Rode o upgrade-check antes de editar os templates. O relatório ajuda a transformar uma migração ampla em uma lista concreta de ajustes.
Declare a herança de atributos de forma explícita. Isso deixa a intenção visível e reduz surpresas quando um componente cresce ou muda de lugar.
Crie testes para eventos de sucesso, validação e erro. A padronização de nomes é útil, mas só a execução do fluxo confirma que extensões e listeners continuam integrados.
Outra boa prática é migrar por fatias. Escolha uma tela, compare carregamento, navegação pelo histórico, acessibilidade e resposta a falhas, depois amplie a mudança somente quando os resultados forem consistentes.
Vale a pena?
O htmx 4.0 vale a avaliação para equipes que já usam HTML renderizado no servidor e querem interações parciais com pouco JavaScript próprio. A versão traz recursos interessantes sem obrigar quem usa htmx 2 a fazer uma atualização imediata.
Ela não é a melhor escolha para todo produto. Interfaces offline, experiências com estado complexo no cliente e aplicações que dependem fortemente de um ecossistema de componentes podem continuar mais adequadas a outras abordagens.
O próximo passo é simples: selecione uma rota, fixe a versão 4.0.0, rode o verificador oficial e valide os fluxos mais importantes. Se a tela passar pelos testes, avance gradualmente e mantenha uma forma clara de voltar à versão anterior.