Reimplementar o htmx do zero para entender AJAX sem framework

O htmx virou queridinho de quem quer interatividade sem carregar o peso de uma SPA. Mas o que exatamente ele faz por baixo do capô? A newsletter JavaScript Weekly (edição #797) destacou um experimento de Serge Zaitsev intitulado "Let's Make the Worst htmx Ever", em que ele reconstrói a essência da biblioteca do zero. É a mesma pegada didática que o autor já aplicou antes em versões propositalmente "ruins" de React e Vue: o objetivo não é competir, e sim expor a mecânica.

O que o htmx realmente faz

Na prática, o htmx é bem menos mágico do que parece. A ideia central: em vez de escrever JavaScript para cada botão que dispara uma requisição, você anota o HTML com atributos e a biblioteca cuida do resto. Um hx-get="/rota" num botão significa "quando clicar, faça um GET nessa URL". Um hx-target="#lista" diz onde jogar a resposta. E hx-swap define como inserir o HTML retornado (substituir, anexar, prefixar).

Reconstruir isso do zero, como Serge propõe, esclarece que o núcleo se resume a três responsabilidades:

• Varrer o DOM procurando elementos com atributos hx-*.
• Interceptar eventos (clique, submit, etc.) nesses elementos.
• Fazer fetch e trocar pedaços do DOM com o HTML que o servidor devolve.

Ao montar uma versão mínima disso, fica claro o ponto filosófico do htmx: o servidor devolve fragmentos de HTML prontos, não JSON que o cliente precisa transformar em interface. Essa inversão significa que o servidor volta a ser dono da renderização.

Por que isso importa para apps legados

Aqui está o valor prático para o público brasileiro que mantém sistemas mais antigos. Muita base de código roda em Rails, Laravel, Django ou até PHP puro, gerando HTML no servidor. Migrar tudo para React só para ter um formulário que atualiza sem recarregar a página é trocar um problema por um custo enorme: build, bundle, hidratação, estado no cliente.

Entender a arquitetura minimalista que o experimento de Serge revela dá confiança para adotar essa abordagem de forma cirúrgica. Dá para introduzir interatividade AJAX ponto a ponto sem reescrever a aplicação e sem adicionar um framework pesado. Em muitos casos, você nem precisa da biblioteca completa: com o conhecimento de como o mecanismo funciona, um fetch mais alguns event listeners resolvem casos simples.

Trade-offs que o exercício deixa claros

Reimplementar algo do zero é ótimo justamente porque escancara o que a versão de produção resolve e você provavelmente vai esquecer:

• Requisições concorrentes e cancelamento. O usuário clica duas vezes rápido; qual resposta vence? O htmx real lida com isso, sua versão de fim de semana não.
• Histórico e navegação. Trocar conteúdo via AJAX quebra o botão "voltar" se você não mexer na History API. É trabalho que some quando você usa a biblioteca pronta.
• Acessibilidade. Trocar um pedaço do DOM sem avisar tecnologias assistivas gera uma experiência ruim. Regiões aria-live, gerenciamento de foco e ordem de leitura precisam ser pensados a cada swap. Isso não é rodapé: se o conteúdo muda e o leitor de tela não anuncia, você excluiu gente do fluxo.
• Performance percebida. A vantagem óbvia é bundle mínimo e menos JavaScript executando. Mas cada interação vira uma ida ao servidor, então latência de rede passa a pesar. Vale medir: em conexões instáveis, um estado local otimista de uma SPA pode parecer mais rápido, ainda que carregue mais código na primeira visita.

O que levar do experimento

O exercício de Serge não é uma receita para usar em produção, e ele mesmo brinca com isso ao chamar de "o pior htmx". O ganho é conceitual. Depois de ver o núcleo desmontado peça por peça, o htmx deixa de ser caixa-preta e vira uma escolha arquitetural consciente: HTML sobre a rede, servidor no comando, cliente magro.

Para quem quer explorar, a recomendação é montar um sandbox mínimo (um servidor que devolva fragmentos e uma página com dois ou três atributos hx-* implementados à mão) e comparar o resultado com a biblioteca oficial. Meça o tamanho do bundle, o número de requisições e teste com o teclado e um leitor de tela antes de decidir. A leitura completa está no artigo de Serge Zaitsev linkado pela JavaScript Weekly, e vale como um estudo de caso sobre quanto de complexidade a gente carrega sem precisar.

Fonte: JavaScript Weekly