Show HN: htmz – una herramienta ligera para HTML

Artículo original ↗ Discusión en Hacker News ↗

Un diminuto “microframework” HTML de 181 bytes llamado htmz, que usa un iframe y el atributo `target` para intercambiar fragmentos de página sin AJAX tradicional ni frameworks frontend, está impresionando a muchos desarrolladores como una forma ingeniosa y minimalista de construir páginas interactivas. Los comentaristas lo comparan con htmx y técnicas antiguas como pjax, sopesando su elegancia y baja complejidad frente a desventajas prácticas como el mal funcionamiento del botón Atrás, la falta de degradación elegante sin JavaScript, la compatibilidad con CSP y la latencia en interfaces muy interactivas. El sentimiento general es que htmz se entiende mejor como una prueba de concepto afilada que pone de relieve lo cerca que están los navegadores de soportar de forma nativa aplicaciones declarativas impulsadas por hipermedia, más que como una solución lista para producción.

Reacción general e intención

  • Muchos consideran que htmz es impresionantemente pequeño, elegante y una demostración ingeniosa de un profundo conocimiento de la plataforma.
  • Se lo describe repetidamente como un “hack divertido”, un “experimento” o incluso una parodia de frameworks más pesados, aunque algunos sí lo tendrían en cuenta para pequeños proyectos reales.
  • Otros lo ven como algo técnicamente interesante pero confuso o frágil de depurar, y no como algo que quisieran heredar en código de producción.

Relación con htmx y otras herramientas

  • htmz se describe ampliamente como un subconjunto / reimplementación en una sola línea del comportamiento central de htmx (fragmentos renderizados en el servidor intercambiados dentro del DOM).
  • Se señala que htmx es más pesado porque añade soporte de historial, sistemas de eventos/callbacks, morphing del DOM, SSE, recopilación de entradas y degradación elegante; eso se presenta tanto como una ventaja como un costo.
  • Se establecen comparaciones con pjax, Vue (a menudo elogiado por “reducirse”), Alpine, hyperscript y otros microframeworks “HTML-first”.

Mecanismo y semántica de HTML

  • Truco principal: usar <base target> y un <iframe> oculto como proxy; los enlaces/formularios apuntan al iframe, cuyo fragmento cargado se mueve al DOM principal según el hash de la URL.
  • Algunos ven la reutilización de identificadores de fragmento (#id) y el uso original de <slot> como un abuso semántico; otros argumentan que esto es un hack aceptable y coherente con el comportamiento de iframe.
  • Se sugieren elementos inertes como <div> o <output>, y patrones alternativos de selectores CSS para reducir aún más el snippet.

Historial / comportamiento del botón Atrás

  • Varios comentaristas señalan que cada clic agrega una entrada al historial del navegador, rompiendo el comportamiento esperado de Atrás y ensuciando el historial.
  • Propuestas: usar botones en lugar de enlaces, usar replaceState, o una “extensión” para gestionar el historial; algunos piensan que las rarezas del historial son aceptables para demos pero mala UX para aplicaciones reales.

Dependencia de JavaScript y degradación elegante

  • htmz se rompe por completo sin JS; además se comporta mal cuando los usuarios abren enlaces en nuevas pestañas o copian destinos de enlaces.
  • Hay un amplio debate sobre si el soporte sin JS sigue importando:
    • Un bando insiste en que la mejora progresiva y “HTML-first, JS como actualización” son importantes por accesibilidad, privacidad y dispositivos antiguos/de bajo consumo.
    • Otro bando sostiene que desactivar JS equivale a desactivar parte del navegador, así que que se rompa es aceptable.
  • Se proponen varias estrategias: inserción dinámica de la etiqueta base, parámetros de consulta especiales, cookies y el nuevo encabezado Sec-Fetch-Dest: iframe para distinguir páginas completas de fragmentos.

Compromisos de rendimiento y UX

  • A algunos les preocupa la latencia de ida y vuelta en cada interacción (por ejemplo, cambiar pestañas) y dicen que esas interacciones deberían ser puramente del lado del cliente.
  • Otros responden que fragmentos HTML pequeños sobre la red pueden superar a grandes bundles de JS, y que retrasos modestos son aceptables en muchas regiones y casos de uso.
  • Surgen ideas híbridas: HTML renderizado en el servidor para la mayoría de los flujos, con pequeños scripts del lado del cliente (o cosas como hyperscript/Alpine) para interacciones locales sin latencia.

Seguridad, CSP y preocupaciones entre orígenes

  • Los onload en línea y los iframes pueden entrar en conflicto con políticas estrictas de Content-Security-Policy; se mencionan soluciones como nonces o hashes.
  • Se sugieren variantes entre orígenes usando postMessage, pero se advierte que son peligrosas si se usa targetOrigin: '*', ya que puede filtrar contenido del iframe.

Discusión más amplia de la plataforma

  • Varios comentaristas ven htmz como evidencia de que el “AJAX nativo de HTML” o la carga de fragmentos debería estandarizarse.
  • Se hacen referencias a propuestas existentes (por ejemplo, un elemento html-include) y a la idea de un nuevo tipo MIME para fragmentos.
  • Hay nostalgia por los hacks de iframe/XHR anteriores a las SPA y la sensación de que las pilas UI modernas complican en exceso lo que la hipermedia básica ya hace bien.