Htmx e Web Components: Uma combinação perfeita

Artigo original ↗ Discussão no Hacker News ↗

HTMX e Web Components estão atraindo interesse renovado como uma alternativa mais simples a frameworks pesados de single-page app, empurrando mais lógica de volta para o servidor e deixando fragmentos HTML conduzirem a interatividade. Defensores destacam gerenciamento de estado mais fácil, menos modelos duplicados entre cliente e servidor e bom encaixe para apps CRUD ou com muito conteúdo, enquanto céticos questionam escalabilidade, casos de uso complexos e a ergonomia de HTML carregado de atributos — especialmente quando combinado com CSS utility-first como Tailwind. Grande parte do debate gira em torno de trade-offs entre experiência de desenvolvimento, manutenção de longo prazo e escolher o nível certo de JavaScript para cada projeto.

Sinergia entre HTMX + Web Components e problemas de ciclo de vida

  • Muitos veem HTMX e Web Components como complementares: componentes se inicializam sozinhos quando são anexados ao DOM, tornando-os fáceis de “AJAXar”.
  • Padrões práticos: tags personalizadas como <my-modal> envolvendo HTML normal, com pequeno JS para listeners e atributos.
  • Problemas de ciclo de vida observados: componentes-pai podem precisar acessar elementos personalizados filhos antes de eles estarem conectados. Foram discutidos contornos:
    • Filhos se registrando nos pais.
    • Uso de CustomEvent com bubbling, slotchange, MutationObserver ou whenDefined.
  • Alguns argumentam que a composição de web components é limitada sem um framework, já que atributos são baseados em strings e compartilhar estado mais rico é complicado.

HTMX: benefícios, limites e questões de arquitetura

  • Os fãs gostam de ver o HTMX restaurando UIs dirigidas pelo servidor: menos JS, sem modelos duplicados no cliente e no servidor, apps CRUD mais simples e “divertido como em 2007, mas com CI/CD moderno”.
  • Ele é elogiado para apps pequenos a médios, com muito conteúdo, em que a complexidade de uma SPA completa não se justifica. Muitos relatam escrever muito menos JS, usando-o apenas para casos-limite.
  • Céticos veem isso como montar fragmentos HTML de um jeito que lembra antigos apps MVC que se tornaram difíceis de manter. Alguns preferem embutir pequenos widgets de SPA em vez disso.
  • Preocupação: necessidade de endpoints separados para HTML (HTMX) e APIs JSON; outros argumentam que separar UI e APIs de integração é saudável.
  • Permanecem perguntas em aberto sobre:
    • Escalar para codebases muito grandes; poucos deployments grandes de HTMX documentados publicamente são citados.
    • SEO e comportamento de crawlers com respostas parciais em HTML (sem consenso claro no fio).

Frameworks de SPA vs abordagens hipermídia

  • Vários comparam experiências: projetos em React/Angular descritos como lentos para iterar, com gerenciamento de estado doloroso (stores globais, reducers, prop drilling), embora outros digam que isso é um problema de arquitetura, não do framework.
  • Alguns enfatizam que a maioria dos apps do mundo real é pequena; stacks de SPA e JS pesado são vistos como exagero para formulários e tabelas básicos que o HTMX pode tratar com renderização no servidor.
  • Outros ressaltam que SPAs ainda se destacam para UIs “webapp” complexas, altamente interativas, e para estado global compartilhado; HTMX é visto como uma má escolha nesse cenário.

Tailwind, CSS e “inline styles reinventados”

  • Forte divisão:
    • Pró-Tailwind: criação de UI mais rápida, escalas consistentes para espaçamento/cores, fácil de ler/atualizar em um só lugar, ótimo para equipes e sistemas de design, muitas vezes com menos CSS no geral.
    • Anti-Tailwind: o HTML vira uma “sopa de classes” ruidosa, manutenção de longo prazo mais difícil, perda de nomes de classes semânticos e do aprendizado tradicional de CSS, sensação de inline styles glorificados.
  • Alguns mitigam com bibliotecas de componentes (Bootstrap, daisyUI), libs de CSS atômico (UnoCSS, open-props), ou misturando utilitários do Tailwind com classes personalizadas.
  • O debate continua sobre se a abordagem “parecida com inline styles” do Tailwind é um retrocesso ou uma abstração pragmática.