Removendo React.js da base de código e adaptando o Htmx para interatividade de UI (2023)

Artigo original ↗ Discussão no Hacker News ↗

Substituir SPAs no estilo React por HTMX e HTML renderizado no servidor é apresentado como uma opção atraente para fóruns e sites pesados em CRUD, onde a maioria das interações é simples e o tamanho do payload e o tempo até a interatividade importam mais do que o estado rico no cliente. Defensores destacam stacks mais simples, melhor cache e carregamentos iniciais mais rápidos, enquanto críticos argumentam que o HTMX escala mal para UIs complexas e altamente interativas, leva a “attribute spaghetti” e repete problemas antigos das abordagens da era AngularJS. Muitos concluem que o HTMX funciona bem quando o estado do lado do cliente é mínimo e as páginas são em grande parte documentais, mas frameworks no estilo React/Vue continuam mais adequados para interfaces sofisticadas, com aparência de aplicativo.

Escopo do HTMX vs Frameworks React/SPA

  • Muitos veem o HTMX como ideal para apps renderizadas no servidor, ricas em conteúdo ou do tipo CRUD (fóruns, UIs administrativas, formulários, filtros, paginação).
  • Outros argumentam que frameworks no estilo React/Vue/Solid são melhores para UIs complexas, altamente interativas e com estado (chat, notificações, editores, players de mídia, DAWs).
  • Debate sobre se o frontend moderno “se estabilizou” em JSX; alguns dizem que sim (domínio de React/Solid), enquanto outros apontam grandes frameworks que não usam JSX por padrão.

Desempenho, Tráfego e Cache

  • Comentários pró-HTMX: menos JavaScript enviado, renderização inicial mais rápida, cache mais simples de fragmentos HTML, melhor para dispositivos de baixo custo e landing pages de alto tráfego.
  • Críticos afirmam que React com SSR/hydration e CDNs pode ser eficiente; geração pesada de fragmentos HTML em escala (>10k req/s) pode ser cara para o HTMX.
  • Um praticante achou o HTMX lento ao retornar grandes respostas HTML para filtros complexos; mudar para Alpine + parciais reduziu o payload e pareceu mais rápido.

Gerenciamento de Estado e Preocupações com “Spaghetti”

  • Detratores argumentam que abordagens baseadas em HTMX/atributos lembram Angular 1.0: “codelets” espalhados, gerenciamento de estado difícil e eventual “spaghettification”.
  • Defensores do HTMX respondem que o estado do lado do cliente deve ser mínimo; o estado real vive no servidor, com atualizações HTML refletindo a verdade do servidor.
  • Outros relatam equipes voltando para React depois que o HTMX se tornou difícil de gerenciar, enquanto alguns dizem que sistemas baseados em HTMX continuam mais fáceis de manter.

Limites de Interatividade e Contornos

  • Pontos fracos citados: interações ricas na página (listas com rolagem que atualizam durante a rolagem, preservação de seleção de texto, formulários complexos com facetas).
  • Mitigações sugeridas: extensões de morphing do DOM, swaps out-of-band, combinação de HTMX com pequenos componentes JS (Alpine, Web Components, Leaflet, etc.).
  • Alguns veem o HTMX como incompleto para experiências “tipo app”; outros recomendam arquiteturas híbridas (HTMX para a maioria das páginas, “ilhas” React/Vue para widgets pesados).

Casos de Uso, Ferramentas e Alternativas

  • Relatos entusiasmados de HTMX alimentando apps web completos e até PWAs; suporte offline exige service workers e cache pesado, o que alguns consideram convoluto.
  • Reclamações sobre a fraca composição de componentes do HTMX e a falta de ferramentas no estilo Storybook; sugestões incluem sistemas no estilo LiveView, Places.js, Pyview ou frameworks SSR first em JS.
  • Vários enfatizam que não existe uma ferramenta universalmente melhor; a escolha correta depende do nível de interatividade, da complexidade do estado, da escala e das habilidades da equipe.