Show HN: Eu fiz um Playground de HTMX 100% no navegador

Um playground de HTMX no navegador levou desenvolvedores web a compartilhar como usam HTMX com frameworks como Django e Rust para construir UIs interativas guiadas pelo servidor sem frontends pesados em JavaScript. Os comentários discutem até onde essa abordagem centrada em hipermídia pode escalar, como ela se compara a SPAs, LiveView e ferramentas como Unpoly, e onde ela falha (por exemplo, apps offline-first ou backends apenas com GraphQL). O criador do HTMX comenta sobre a filosofia de design, os casos de uso apropriados e tranquiliza os céticos de que a biblioteca é fácil de aprender e pode coexistir com JavaScript tradicional quando necessário.

Conceito de HTMX e comparações

  • HTMX é apresentado como uma generalização dos controles de hipermídia do HTML: qualquer elemento pode disparar requisições HTTP e transcluir o HTML retornado para dentro do DOM.
  • Vários o comparam a DHTML, Turbolinks/Hotwire, Phoenix LiveView e Unpoly:
    • DHTML era pesado em JS e anterior ao XHR; HTMX é focado em hipermídia.
    • Turbolinks/Hotwire e Unpoly são vistos como mais de alto nível, mais “mágicos”, enquanto HTMX é de nível mais baixo e menos opaco.
    • LiveView e HTMX resolvem problemas semelhantes, mas em stacks diferentes.
  • HTMX é considerado uma má escolha quando o backend é uma API pura de JSON/GraphQL em vez de retornar hipermídia.

Casos de uso e experiências de integração

  • Há vários relatos de uso bem-sucedido com Django, SQLAlchemy, Rust, Go e Node; muitas vezes substituindo setups de SPA pesados em JavaScript.
  • Padrão: usar HTMX para 90–99% da UI e inserir pequenas quantidades de JS/Vue/Alpine personalizado para partes altamente interativas.
  • As pessoas elogiam a simplicidade de adotar HTMX, especialmente para desenvolvedores mais voltados ao backend.

Enhancement progressivo e atualizações parciais

  • Houve discussão sobre aprimorar envios tradicionais de formulários para que o mesmo endpoint retorne uma página completa para usuários sem JS, enquanto o HTMX troca apenas fragmentos específicos.
  • Técnicas mencionadas: hx-target, hx-select, hx-boost e a extensão multi-swap para atualizar apenas partes da resposta.
  • Unpoly é citado como outra ferramenta que se destaca nesse padrão.

Offline, comportamento tipo SPA e mobile

  • Vários exploram ou defendem arquiteturas parecidas com HTMX para apps offline-first:
    • service workers como “servidores virtuais” ou backends companheiros locais.
    • Alguns afirmam ter construído apps offline-first elegantes dessa forma; outros chamam isso de exagerado e contrário ao espírito do HTMX.
  • Há debate sobre usar hipermídia/HATEOAS além da web (desktop/mobile), com opiniões mistas sobre os benefícios reais de UX.

Adoção em equipe, contratação e complexidade

  • Preocupação: um pool menor de talentos em HTMX em comparação com frameworks JS mais mainstream.
  • Contra-argumentos:
    • HTMX é rápido de aprender se você conhece HTML/JS.
    • Ele incentiva responsabilidade full-stack e uma estrutura centrada no backend.
    • Código espaguete é um risco em qualquer paradigma; SPAs não o evitam por si só.
  • HTMX é relatado como estando em alta popularidade, mas é considerado apenas uma ferramenta, não uma solução universal.

Feedback específico do playground

  • A recepção geral do playground de HTMX é muito positiva.
  • Sugestões: melhor suporte a mobile, saída de erros aprimorada, possibilidade de limpar os logs de rede e algumas discussões sobre o editor (Ace vs Monaco).