O htmx é apenas mais um framework JavaScript?

Artigo original ↗ Discussão no Hacker News ↗

Se o htmx deve ser visto como uma biblioteca JavaScript leve, um framework completo ou até um “polyfill de HTML do futuro” gera questões mais amplas sobre como construímos interfaces web modernas. Comentadores contrastam o modelo centrado em hypermedia, sem build e renderizado no servidor do htmx com SPAs no estilo React e pipelines pesados de bundlers, debatendo trade-offs em complexidade, gerenciamento de dependências, desempenho e estrutura de equipe. Muitos veem o htmx como uma forma pragmática de manter a maior parte da lógica no backend e reduzir JavaScript, ao mesmo tempo observando que ele é mais adequado a certas classes de apps e dificilmente substituirá os frameworks SPA dominantes em grandes organizações tão cedo.

O que é htmx: biblioteca vs framework

  • Debate em andamento sobre definições: alguns veem o htmx como uma biblioteca (o HTML o chama), outros como um framework (ele gerencia um loop de eventos e chama o seu código).
  • Vários comentaristas rejeitam o tradicional “você chama uma biblioteca; um framework chama você” por ser muito impreciso, citando confusão semelhante em torno de React, Spring, Rails etc.
  • Surge uma definição pragmática: bibliotecas são mais fáceis de substituir; frameworks permeiam a base de código e são difíceis de trocar. Por esse padrão, alguns argumentam que o htmx se comporta como framework.

Modelo centrado em hypermedia

  • htmx generaliza os “controles de hypermedia” existentes do HTML (links e formulários) para qualquer elemento, permitindo requisições HTTP declarativas e trocas parciais do DOM.
  • Muitos usuários valorizam manter a maior parte da lógica no backend, retornando HTML em vez de JSON e evitando estado duplicado entre cliente e servidor.
  • Alguns veem o htmx como uma prova de conceito para clientes de hypermedia mais ricos e fluxos de trabalho “sem build”.

Comparação com SPAs e ferramentas JavaScript

  • Críticas fortes ao ecossistema moderno de JS/NPM: explosão de dependências, upgrades frágeis, mudanças quebrando frequentemente, pipelines de build complexos.
  • O htmx atrai como uma forma de:
    • Evitar ou minimizar bundlers/transpilers.
    • Manter a UI mais simples para ferramentas internas e apps CRUD.
    • Obter interatividade “parecida com SPA” com HTML renderizado no servidor.
  • Outros argumentam que, com bloqueio de versões e ferramentas adequadas, TypeScript/React podem ser estáveis, e que a complexidade muitas vezes vem do uso inadequado, não da stack em si.

Limitações, preocupações com DSL e rotas de escape

  • Críticos destacam o baixo “teto de expressividade” da configuração baseada em atributos e o surgimento de mini-DSLs (por exemplo, sintaxe complexa de hx-trigger) e linguagens complementares.
  • Há receio de que, conforme os requisitos crescem, as equipes adicionem mais JS, gerando spaghetti e uma eventual migração para frameworks completos de SPA.
  • Defensores respondem que:
    • htmx opera intencionalmente em um nível limitado de poder; quando as necessidades passam disso, você deve adicionar scripts deliberadamente ou trocar de ferramenta.
    • Ele compõe razoavelmente bem com AlpineJS ou similares para estado no lado do cliente.

Adoção, organização e casos de uso

  • Pontos ideais relatados: ferramentas internas, painéis administrativos, apps de intranet, sites moderadamente interativos; especialmente quando desenvolvedores de backend cuidam tanto dos dados quanto da UI.
  • Alguns observam uso limitado em grandes empresas orientadas a lucro, atribuindo isso a:
    • Investimentos já existentes em React/SPAs.
    • Divisão entre equipes especializadas de frontend e backend.
  • Há debate sobre se o htmx (ou suas ideias) influenciará os padrões do HTML; vários são pessimistas quanto à padronização no curto prazo.