- No desenvolvimento web moderno, a falsa dicotomia entre HTML e grandes frameworks JavaScript está empurrando desenvolvedores para uma complexidade desnecessária
- O HTMX lida com requisições AJAX, atualizações parciais e transições animadas apenas com atributos HTML, oferecendo uma forma de refletir na tela exatamente o HTML retornado pelo servidor
- Sua estrutura permite adoção gradual sem grandes mudanças na base de código existente, reduzindo a complexidade do frontend e aumentando produtividade e manutenibilidade
- Em comparação com SPAs baseadas em React, casos reais em produção mostraram grandes melhorias em quantidade de código, dependências, tempo de build e velocidade de carregamento
- Em vez de escolher frameworks em excesso, uma abordagem simples baseada em hipermídia é mais vantajosa no longo prazo para produtividade e manutenção
Levantando o problema: a falsa escolha no desenvolvimento web
- Nas discussões sobre desenvolvimento web, só se repetem escolhas extremas: usar apenas HTML ou usar um grande framework como React
- HTML puro já é forte em recursos básicos como links, formulários e
dialog, mas tem limitações em atualização parcial e resposta imediata
- Ao escolher React, Vue ou Angular, vêm junto centenas de dependências, builds lentos e debates complexos sobre gerenciamento de estado
- Mesmo para apps simples de CRUD, dashboards e aplicações centradas em formulários, a realidade é de uso de um arsenal de ferramentas excessivo
Conceitos centrais do HTMX
- HTMX é uma ferramenta que adiciona atributos especiais a elementos HTML para realizar comunicação assíncrona com o servidor
- Por exemplo, com os atributos
hx-get e hx-post, é possível enviar requisições e inserir a resposta em uma área específica do DOM
- Ele expande o HTML para que qualquer elemento HTML possa ser o originador de uma requisição HTTP
- O servidor retorna fragmentos de HTML em vez de JSON, e o HTML retornado é substituído ou inserido automaticamente na posição especificada
- O comportamento é definido apenas pela declaração de atributos HTML, sem escrever JavaScript diretamente
- A biblioteca tem cerca de 14kb (gzip), sendo extremamente leve
- Pode ser aplicada diretamente em documentos HTML existentes sem ferramentas de build ou configuração de framework
- É uma estrutura que combina bem com o estilo tradicional de desenvolvimento web centrado em renderização no servidor
Principais recursos
- Processamento de requisições AJAX: realiza requisições GET e POST apenas com atributos HTML
- Atualização do DOM: aplica automaticamente a elementos específicos o HTML retornado pelo servidor
- Tratamento de eventos: conecta chamadas ao servidor a eventos do usuário, como clique e digitação
- Gerenciamento de histórico: integra-se às ações de voltar e avançar do navegador
Casos reais de adoção e números
- A Contexte migrou um SaaS baseado em React para Django + HTMX
- Redução de 67% no total de linhas de código (21.500 → 7.200)
- Redução de 96% nas dependências JavaScript (255 → 9)
- 88% menos tempo de build (40 segundos → 5 segundos)
- Melhoria de 50~60% na velocidade de carregamento da página
- Dois terços da base de código foram apagados, e o app ficou melhor
- Sem separar frontend e backend, todos os desenvolvedores puderam trabalhar de forma full stack
Organizando as objeções mais comuns
- "Será que não é necessário um gerenciamento de estado complexo no cliente?"
- Na prática, a maioria dos casos se resume a formulários, listas e elementos que aparecem conforme cliques, e isso pode ser tratado suficientemente bem com HTMX
- Ferramentas de colaboração em tempo real como Google Docs são exceção, mas na maior parte dos casos estamos superestimando apps de CRUD
- "E as vantagens do ecossistema React?"
- Um ecossistema enorme também significa gigabytes de
node_modules, escolhas intermináveis e debates sobre gerenciamento de estado
- No ecossistema do HTMX, tudo termina em uma única linguagem server-side escolhida por você
- "SPA não parece mais rápida na prática?"
- No início, é preciso passar por download, parsing, execução e hidratação de grandes volumes de JavaScript
- O HTMX é rápido já no carregamento inicial e, depois disso, mantém a resposta veloz ao substituir apenas as partes alteradas
- "E se eu realmente precisar de algum recurso específico do React?"
- Em alguns casos, React pode de fato ser a escolha adequada
- Mas, na prática, muitas vezes se escolhe por hábito uma ferramenta necessária apenas para uma parte do problema total
- Por que escolher HTMX?
- O motivo de times falharem não é um framework errado, mas sim a escolha excessiva de frameworks
- O HTMX aposta na simplicidade, e no longo prazo a simplicidade traz vantagens em manutenção e produtividade
Quando HTMX não é adequado
- Ferramentas de edição colaborativa em tempo real (Google Docs, Figma)
- Aplicações que exigem grande volume de processamento no cliente (editores de vídeo, ferramentas CAD)
- Estruturas offline-first (embora seja possível combinar várias abordagens)
- Casos que realmente exigem estado de UI complexo
- Mas você realmente está construindo esse tipo de coisa?
- Será que você não está apenas criando mais um dashboard, painel administrativo, site de e-commerce, blog ou app SaaS composto basicamente de formulários, tabelas e listas?
- Para esse tipo de coisa, o HTMX é realmente surpreendentemente bom — a ponto de dar vontade de dizer: "Por que eu tornei isso tão complexo?" e "Meu Deus, perdi tempo demais com isso"
Então, experimente uma vez
- Você já usou React, já usou Vue e provavelmente já experimentou Angular para depois se arrepender, não é?
- E provavelmente já mexeu ao menos uma vez no meta-framework da moda desta semana no Hacker News
- Simplesmente experimente HTMX uma vez
- Invista um dia do fim de semana
- Escolha um projeto paralelo
- Ou pegue uma ferramenta interna com a qual ninguém se importa tanto assim
- Ou desenterre algo que você estava adiando refazer um dia
- Adicione uma tag
<script> e escreva um atributo hx-get, depois veja com seus próprios olhos funcionando
- No pior caso, você só perde um dia do fim de semana, então o prejuízo não é grande
- Mas você provavelmente não vai desgostar
- Na verdade, vai acabar se perguntando por que o desenvolvimento web ficou tão complicado assim
8 comentários
No ano passado eu tinha feito uma apresentação dessas. Quase ninguém assistiu, mas enfim^^
https://www.slideshare.net/slideshow/htmx-2024/274315966
Também cheguei a fazer algo assim como PoC
https://github.com/iolo/hx
Mas ninguém usa htmx mesmo haha
É uma pena que, depois de nos acostumarmos com a situação atual e de se formar um ecossistema tão grande, tudo tenha se cristalizado e pareça não haver mais movimento em direção à inovação.
Os slides estão bem divertidos, é uma pena que eu não pude ver a apresentação haha
Lembro que já assisti a uma palestra relacionada na PyCon, e me marcou o fato de o palestrante também ter dito que ainda não tinha conseguido usar isso no trabalho real.
Rust, por favor, experimentem pelo menos uma vez?
Já tentei usar Alpine.js, mas na maioria das vezes eu precisava de gerenciamento de estado...
A menos que você projete desde o início para gerenciar o estado no backend, lembro que era bem complicado resolver estado por etapas, estado condicional e coisas do tipo.
Concordo com tudo, mas o htmx simplesmente não me atrai ;_;
Comentários do Hacker News
Eu sou o criador do htmx. Agradeço a atenção gerada por artigos exagerados, mas não gosto muito desse tipo de hype
Há várias formas de criar web apps, e cada uma tem seus prós e contras. Resumi os pontos fortes e fracos do htmx neste texto
Também recomendo muito experimentar o Unpoly, outra excelente biblioteca orientada a hypermedia
(Adendo) Revendo o conteúdo do artigo, achei melhor do que eu esperava. Ainda assim, espero que o htmx seja tratado de forma mais comedida
Atualizar campos com dropdown, criar modais, caixa de busca com autocomplete, tudo isso é simples
Ainda assim, a complexidade dos frontends RIA está em como atualizar o frontend quando os dados mudam.
É preciso algum ajuste no backend, e seria melhor ter uma estrutura capaz de lidar com vários updates parciais ao mesmo tempo
Hoje faço um projeto paralelo com Rails + Stimulus, e o Stimulus até parece exagerado. Fico pensando quando faz sentido escolher Inertia ou Stimulus
É um plugin do Alpine.js que adiciona funcionalidades básicas de AJAX a links e formulários
Estou cansado de textos que dizem que é melhor que React usando exemplos de “Hello World”
Em exemplos simples, qualquer coisa funciona bem. Mas, na prática, a maioria dos casos envolve backends com muitas dependências e UIs complexas
A demo básica é boa, mas é preciso mostrar como isso pode escalar quando se adicionam recursos mais complexos
Fico pensando onde entra o JS, se é necessário um build step e o quanto isso te prende ao paradigma do htmx
Não é questão de ser melhor que React, e sim de ser mais uma abordagem
O paradigma de substituir partes do DOM é muito simples e intuitivo
Ex.: effect-ts é poderoso, mas até uma saída simples é complicada
Nossa startup adotou HTMX, mas no fim está migrando para React
No HTMX, a complexidade de tratar respostas é alta, e cada endpoint precisa retornar vários fragmentos de HTML
Faltam documentação e casos de uso, e também boas práticas em larga escala.
React é maduro e também combina bem com codificação com IA. HTMX serve para projetos simples, mas além disso fica difícil
Cada endpoint faz só uma coisa, e a Optimistic UI reage imediatamente
O tratamento de erros fica simples, e
hx-swap-oobé usado no mínimoA chave ao escolher tecnologia é minimizar os trade-offs
Por isso, eu deixo a validação centrada no backend e faço o frontend apenas exibir
Eu não quero SSR. O backend deve fornecer apenas uma JSON API, e o frontend consome isso
Acho que SSR é um conceito supervalorizado. Parece mais uma estratégia para vender serviços de nuvem
O exemplo Demo 3 Live Search tem um problema sério de travamento de rolagem (jank).
Parece que os resultados são inseridos diretamente no documento e o layout fica sendo recalculado o tempo todo
React é bom o suficiente. Mesmo em projetos simples, não há motivo para aprender outro paradigma à força
Já o HTMX você aprende em 15 minutos e consegue usar por 10 anos
Historicamente, paradigmas leves venceram o mercado. React já foi uma dessas opções um dia
Eu me apaixonei completamente não pelo HTMX, e sim pelo Alpine.js
A ideia de melhorar (enhance) HTML renderizado no servidor fez sentido para mim
Dropdowns, show/hide etc. são todos intuitivos, e não é preciso build step
É intuitivo e fácil de administrar até em projetos grandes
Colocar JS inline no HTML dificulta a manutenção, e o gerenciamento de estado fica implícito
Sinto que Hotwire ou Stimulus são muito melhores em organizações maiores
Se você usa HTMX em apps grandes, fico curioso sobre carga no servidor e custo
Como o HTML é renderizado no servidor, parece que o volume de processamento seria maior do que com JSON
Muitas vezes é mais eficiente do que serialização em JSON, e o cliente também tem custo de desserialização
HTMX, quando usado com ferramentas como Alpine.js, também consegue lidar facilmente com estados complexos
Não serve para tudo, mas em muitos casos funciona muito bem
Evangelização de framework é a pior cultura do ecossistema web
Se uma solução é boa, ela será adotada no fim. Não há necessidade de agir como evangelista
O pânico com ataques ao npm também é exagerado. No fim, htmx também pode usar npm
O mundo está cheio de soluções ruins adotadas por causa de marketing e reconhecimento de marca
Para preservar o verdadeiro senso de ofício, é preciso resistir a esses vieses
HTMX parece juntar só as desvantagens dos dois mundos
SSR é coeso, e CSR é separado; HTMX mistura os dois e cria acoplamento implícito
Se eu quiser mostrar os mesmos dados em formatos diferentes, será que preciso criar dois endpoints no backend?
Na maioria dos apps, o estado do backend já basta, e fora melhorias de UX não há grande ganho
Se a página inteira é montada no servidor, os dados já estão ali dentro