HTMX é tão legal que eu fiz o meu próprio (2024)

• HTMX é uma abordagem que melhora o frontend de forma progressiva com foco em HTML renderizado no servidor, evoluindo a partir do jeito de fazer as coisas antes de UIs JavaScript modernas no estilo React incharem demais
• Ao trocar SvelteKit por DinoSsr na refatoração do servidor de um podcast web app auto-hospedado, surgiu o problema de a navegação entre páginas interromper a reprodução de áudio, e com HTMX foi possível atualizar apenas a área `` e manter o componente de áudio
• HTMX é distribuído como uma biblioteca de frontend, mas boa parte da implementação fica nos templates e na configuração do backend, e requisições HTTP que retornam HTML acabam funcionando, na prática, como a API do HTMX
• Os atributos hx-*, o exemplo de `` clicável e exemplos avançados com muito JavaScript inline mostram limitações dos templates declarativos com atributos e pontos de incômodo na documentação
• A mini implementação própria usou cache com 304, a History API, substituição de `` e preload baseado em eventos de ponteiro como elementos principais, resultando em menos JavaScript no navegador e em um codebase menor e mais simples

---

O lugar do HTMX

• HTMX rejeita a UI JavaScript moderna e prefere HTML renderizado no servidor, sendo uma abordagem que evoluiu a partir do modo de desenvolvimento anterior ao inchaço do frontend com React
• Scroll infinito e resultados de busca em tempo real são exemplos populares de HTMX, e embora ele pareça limitado por não tentar resolver todos os problemas que React e afins tentam resolver, dentro desses limites é uma ferramenta de grande valor
• HTMX não é uma “magic bullet”, e o ponto principal é a visão de que algumas das ideias por trás do HTMX são mais importantes do que o próprio HTMX

Experimento

• Ler a documentação não foi suficiente, então foi testado o uso real, e a refatoração do servidor do podcast web app auto-hospedado virou o alvo da aplicação de HTMX
• A implementação anterior usava SvelteKit, que é uma ferramenta preferida, mas pode ser pesada para sites pequenos
• O alvo da substituição era o DinoSsr, que o autor estava criando por conta própria e que também é usado no mesmo projeto para build de site estático e para servir um blog de bookmarks
• O DinoSsr é principalmente orientado ao lado do servidor e pode fornecer componentes como “islands” de frontend, mas não é estruturado para oferecer interação de página inteira
• O componente de player de áudio precisava ser mantido durante a navegação entre páginas, e quando a navegação recarregava a página inteira a experiência de reprodução terminava rapidamente
• O SvelteKit cuidava das atualizações de UI e do roteamento no frontend, mas na nova build apenas o componente do player de áudio usa JavaScript no frontend, e o DinoSsr intencionalmente não tenta fazer roteamento no lado do cliente
• Algumas páginas diferem apenas na seção ``, então, ao melhorar os links progressivamente com HTMX e atualizar só essa área, foi possível manter o componente de áudio sem recarregar a página inteira
• A aplicação de HTMX funcionou bem, mas logo depois o HTMX foi removido e substituído por uma versão mínima feita à mão com a mesma ideia

Algumas ideias sobre HTMX

• Nesse experimento, o HTMX foi um substituto para o Svelte no frontend, mas não um substituto de encaixe imediato como o React, e sim uma grande mudança de mentalidade
• HTMX é distribuído como uma biblioteca JavaScript para melhorar o frontend de forma progressiva, mas a maior parte da implementação acontece no backend, em uma estrutura em que os templates e a configuração do servidor precisam ser preparados manualmente
• Requisições HTTP que servem HTML funcionam na prática como a API do HTMX, e detalhes como configurar cabeçalhos HTTP são importantes para o cache correto
• Há os atributos padrão data-* e o dataset, então usar atributos com prefixo não padrão hx-* é uma pequena reclamação
• A documentação do HTMX tem muitos exemplos com ``, e o exemplo abaixo é uma estrutura em que, quando o usuário clica em uma div, é enviada uma requisição PUT para /messages e a resposta é carregada nessa mesma div

    Put To Messages

• Há críticas de que exemplos em que o usuário precisa clicar em um elemento `` não são desejáveis
• Alguns exemplos avançados de HTMX que usam JavaScript inline ficam meio bagunçados e mostram os limites de templates declarativos baseados em atributos
• Independentemente das críticas, HTMX oferece um conjunto de recursos limitado, porém útil, e é uma ferramenta capaz de melhorar muitos padrões comuns de web design

Fazer o próprio

• Logo depois de adicionar HTMX com sucesso, ele foi removido e substituído por uma implementação mínima feita à mão usando as mesmas ideias
• Para permitir requisições fetch com cache, foram usados os cabeçalhos HTTP last-modified, if-modified-since e respostas 304
• A integração básica com histórico usou pushState e popstate
• Foi adicionado código para extrair e substituir o elemento ``, e, inspirado pela extensão preload do HTMX, também foi embutido preload baseado em eventos de ponteiro
• O preload baseado em eventos de ponteiro inicia a requisição fetch antes de o evento click acontecer, oferecendo um pequeno ganho de desempenho
• O código-fonte experimental é bem básico, mas mostra que a quantidade de JavaScript realmente necessária no navegador é pequena
• Com HTMX ou com a abordagem “we have HTMX at home”, o resultado foi um codebase muito menor e mais simples

JavaScript de frontend

• Templates e componentes são praticamente necessários para organização e reutilização de código, a menos que o site seja muito pequeno, e isso também pode ser implementado no lado do servidor com PHP, Ruby, Go, JavaScript etc.
• Não é necessário duplicar essa estrutura no navegador nem implementá-la apenas no navegador, mas muitos desenvolvedores deixaram de fazer essa pergunta por causa da popularidade de React e similares
• O cansaço com JavaScript de frontend é real e se conecta à experiência de preferir templates de servidor mais antigos enquanto, ao mesmo tempo, se superprojeta UI em JS
• Mesmo que o HTMX em si não seja visto como algo tão excelente, sua filosofia ainda é uma abordagem valiosa o bastante para envergonhar desenvolvedores modernos de JavaScript

[GN⁺]

Comentários do Lobste.rs

• É uma implicância pequena, mas não gosto muito de usar atributos HTML com prefixo hx-* onde daria para usar data-* O htmx já suporta há muito tempo o prefixo data- Quanto ao ponto de que não se deve fazer o usuário clicar em um `` elemento, o melhor é usar hx-boost do htmx em tags de âncora e formulário. Ele aprimora automaticamente essas tags da forma correta, então dá para evitar divs clicáveis É um projeto que mostra o quão pouco JavaScript o navegador realmente precisa, e parece que daqui para frente a manutenção será mínima, com quase nenhuma necessidade de patches de segurança. É algo a se comemorar

• O HTMX não sobrecarrega o servidor por renderizar tudo? Passa uma sensação parecida com os problemas de CGI de antigamente

  • Quase certamente não. O problema do CGI era principalmente o custo de iniciar muitos processos de vida curta, e isso foi resolvido com coisas como FastCGI Gerar HTML não é uma tarefa particularmente cara, e também é difícil dizer que seja mais caro do que gerar uma quantidade semelhante de JSON na abordagem alternativa
  • Não entendi o que você quer dizer com “nós”. Meu blog é baseado em CGI, o servidor renderiza HTML e não há JavaScript algum Está assim desde 1999 sem problema nenhum e, como sempre, é preciso verificar onde está o gargalo real com profiling
  • Normalmente isso é chamado de renderização no lado do servidor, mas na prática é mais próximo de gerar HTML bruto no servidor. A renderização de fato e a criação do DOM continuam sendo feitas pelo navegador, e sempre foram Mesmo incluindo PHP na categoria CGI, isso acaba ignorando uns 15 anos de desenvolvimento web em que esse tipo de abordagem era o padrão É verdade que isso coloca mais trabalho no servidor, mas considero que o principal motivo de tanta coisa ter sido empurrada para o cliente ao longo do tempo foi mais um risco calculado para reduzir custos. Muitos usuários finais não percebem que o navegador está fazendo mais trabalho, mas em dispositivos antigos ou fracos a experiência piorou, e ainda piora hoje, especialmente no início Ainda assim, HTMX não é o mesmo que renderização completa no lado do servidor. Em vez de uma API enviar dados em JSON para o cliente renderizar em HTML, o servidor envia os mesmos dados como fragmentos de HTML. Mesmo assim, se o servidor estiver apanhando, é mais provável que seja por outros fatores do que por isso consumir inerentemente mais recursos do que uma API REST
  • É difícil afirmar sem benchmark, mas parece algo parecido. Nos dois casos, no fim das contas, você está emitindo um monte de texto; a diferença é se renderizar texto custa mais do que gerar JSON Pela minha experiência, com JSON há uma tendência de serializar mais coisas, mas não sei muito bem como comparar isso de forma adequada
  • Em aplicações server-side, é raro que a etapa de renderização de HTML em si seja o gargalo; normalmente ele está no que vem antes

• Por motivos parecidos, estou usando alpine-ajax, que é muito semelhante ao htmx

  • Também gosto bastante do alpine-ajax. Se eu fosse começar de novo com a ideia de “obter as vantagens de uma SPA a partir de SSR”, provavelmente iria por esse caminho Até porque já estou usando alpine para os recursos reativos no cliente. Só que, no momento, já há bastante htmx no repositório e também não tenho nenhuma reclamação do htmx
  • Estou usando datastar e tem sido bem agradável de trabalhar