Show HN: htmz – uma ferramenta de baixo consumo para HTML

Artigo original ↗ Discussão no Hacker News ↗

Um minúsculo “microframework” HTML de 181 bytes chamado htmz, que usa um iframe e o atributo `target` para trocar fragmentos de página sem AJAX tradicional ou frameworks de front-end, está impressionando muitos desenvolvedores como uma forma engenhosa e minimalista de construir páginas interativas. Comentadores o comparam ao htmx e a técnicas mais antigas como pjax, ponderando sua elegância e baixa complexidade em contraste com desvantagens práticas como comportamento quebrado do botão Voltar, falta de degradação elegante sem JavaScript, compatibilidade com CSP e latência para UIs altamente interativas. O sentimento geral é que o htmz é melhor visto como uma prova de conceito afiada que destaca o quão perto os navegadores estão de suportar nativamente apps declarativas, orientadas por hipertexto, em vez de uma solução pronta para produção.

Reação geral & intenção

  • Muitos acham o htmz impressionantemente pequeno, elegante e uma demonstração engenhosa de profundo conhecimento da plataforma.
  • Ele é repetidamente descrito como um “hack divertido”, “experimento” ou até paródia de frameworks mais pesados, embora alguns ainda o considerariam para pequenos projetos reais.
  • Outros o veem como tecnicamente interessante, mas confuso ou frágil para depurar, e não como algo que gostariam de herdar em código de produção.

Relação com htmx e outras ferramentas

  • O htmz é amplamente descrito como um subconjunto / reimplementação em uma linha do comportamento central do htmx (fragmentos renderizados no servidor trocados no DOM).
  • O htmx é apontado como mais pesado porque adiciona suporte a histórico, sistemas de eventos/callbacks, morphing do DOM, SSE, coleta de inputs e degradação elegante; isso é apresentado tanto como recurso quanto como custo.
  • Fazem-se comparações com pjax, Vue (frequentemente elogiado por “reduzir de escala”), Alpine, hyperscript e outros frameworks “HTML-first” ou micro.

Mecanismo & semântica HTML

  • Truque central: usar <base target> e um <iframe> oculto como proxy; links/formulários apontam para o iframe, cujo fragmento carregado é movido para o DOM principal com base no hash da URL.
  • Alguns veem a reutilização de identificadores de fragmento (#id) e o uso original de <slot> como abuso semântico; outros argumentam que isso é um hack aceitável, consistente com o comportamento de iframe.
  • Sugestões incluem usar elementos inertes como <div> ou <output>, e padrões alternativos de seletores CSS para reduzir ainda mais o snippet.

Histórico / comportamento do botão Voltar

  • Vários comentaristas observam que cada clique adiciona uma entrada no histórico do navegador, quebrando o comportamento esperado do Voltar e poluindo o histórico.
  • Propostas: usar botões em vez de links, usar replaceState, ou uma “extensão” para gerenciar o histórico; alguns acham que peculiaridades de histórico são aceitáveis para demos, mas ruim de UX para apps reais.

Dependência de JavaScript & degradação elegante

  • O htmz quebra completamente sem JS; ele também se comporta mal quando usuários abrem links em novas abas ou copiam destinos de links.
  • Há um debate extenso sobre se o suporte sem JS ainda importa:
    • Um lado insiste que progressiva melhoria e “HTML-first, JS como atualização” são importantes para acessibilidade, privacidade e dispositivos legados/de baixa potência.
    • Outro lado argumenta que desativar JS equivale a desativar parte do navegador, então falhas são aceitáveis.
  • Variadas estratégias são propostas: inserção dinâmica da tag base, parâmetros de query especiais, cookies e o novo cabeçalho Sec-Fetch-Dest: iframe para distinguir páginas completas de fragmentos.

Desempenho & trade-offs de UX

  • Alguns se preocupam com a latência de ida e volta para cada interação (por exemplo, alternar abas) e dizem que tais interações deveriam ser puramente no cliente.
  • Outros respondem que pequenos fragmentos HTML pela rede podem superar grandes bundles de JS, e que atrasos modestos são aceitáveis em muitas regiões e casos de uso.
  • Surgem ideias híbridas: HTML renderizado no servidor para a maioria dos fluxos, com pequenos scripts no cliente (ou coisas como hyperscript/Alpine) para interações locais de latência zero.

Segurança, CSP & preocupações entre origens

  • onload inline e iframes podem entrar em conflito com uma Content-Security-Policy estrita; são mencionadas alternativas como nonces ou hashes.
  • Variantes entre origens usando postMessage são sugeridas, mas apontadas como perigosas se targetOrigin: '*' for usado, já que isso pode vazar conteúdo do iframe.

Discussão mais ampla sobre a plataforma

  • Vários comentaristas veem o htmz como evidência de que “AJAX nativo em HTML” ou carregamento de fragmentos deveria ser padronizado.
  • Há referências a propostas existentes (por exemplo, um elemento html-include) e à ideia de um novo tipo MIME de fragmento.
  • Há nostalgia pelos hacks de iframe/XHR pré-SPA e a sensação de que stacks modernas de UI complicam em excesso o que a hiper mídia básica já faz bem.