Show HN: Hice un playground de HTMX 100% en el navegador

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

Un playground de HTMX en el navegador ha llevado a desarrolladores web a compartir cómo usan HTMX con frameworks como Django y Rust para construir UIs interactivas, impulsadas por el servidor y sin frontends pesados en JavaScript. Los comentaristas debaten hasta dónde puede escalar este enfoque centrado en hipermedia, cómo se compara con las SPAs, LiveView y herramientas como Unpoly, y dónde falla (por ejemplo, aplicaciones offline-first o backends solo de GraphQL). El creador de HTMX interviene sobre la filosofía de diseño, los casos de uso apropiados y tranquiliza a los escépticos diciendo que la biblioteca es fácil de aprender y puede convivir con JavaScript tradicional cuando haga falta.

Concepto de HTMX y comparaciones

  • HTMX se presenta como una generalización de los controles de hipertexto HTML: cualquier elemento puede desencadenar solicitudes HTTP e incrustar el HTML devuelto en el DOM.
  • Varios lo comparan con DHTML, Turbolinks/Hotwire, Phoenix LiveView y Unpoly:
    • DHTML dependía mucho de JS y era anterior a XHR; HTMX se centra en el hipermedia.
    • Turbolinks/Hotwire y Unpoly se ven como de nivel más alto, más “mágicos”, mientras que HTMX es de nivel más bajo y menos opaco.
    • LiveView y HTMX resuelven problemas similares pero en stacks distintos.
  • Se considera que HTMX encaja mal cuando el backend es una API pura de JSON/GraphQL en lugar de devolver hipermedia.

Casos de uso y experiencias de integración

  • Múltiples informes de uso exitoso con Django, SQLAlchemy, Rust, Go y Node; a menudo reemplazando configuraciones SPA con mucho JS.
  • Patrón: usar HTMX para el 90–99% de la UI e incorporar pequeñas cantidades de JS/Vue/Alpine personalizado para piezas muy interactivas.
  • La gente elogia la simplicidad de adoptar HTMX, especialmente para desarrolladores inclinados hacia el backend.

Mejora progresiva y actualizaciones parciales

  • Se debatió sobre mejorar envíos de formularios tradicionales para que el mismo endpoint devuelva una página completa para usuarios sin JS, pero HTMX solo intercambie fragmentos específicos.
  • Se mencionaron técnicas como hx-target, hx-select, hx-boost y la extensión de multi-swap para actualizar solo partes de la respuesta.
  • Unpoly se cita como otra herramienta que destaca en este patrón.

Comportamiento sin conexión, tipo SPA y móvil

  • Varios exploran o defienden arquitecturas tipo HTMX para aplicaciones offline-first:
    • Service worker como “servidores virtuales” o backends locales complementarios.
    • Algunos afirman haber construido aplicaciones offline-first elegantes de esta manera; otros lo consideran sobreingenierizado y contrario al espíritu de HTMX.
  • Hay debate sobre usar hipermedia/HATEOAS más allá de la web (escritorio/móvil), con opiniones mixtas sobre sus beneficios reales de UX.

Adopción por equipos, contratación y complejidad

  • Preocupación: un grupo de talento HTMX más pequeño frente a frameworks JS convencionales.
  • Contraargumentos:
    • HTMX se aprende rápido si conoces HTML/JS.
    • Fomenta la propiedad full-stack y una estructura centrada en el backend.
    • El código espagueti es un riesgo en cualquier paradigma; las SPA no lo previenen por sí solas.
  • Se informa que HTMX está creciendo en popularidad, pero se considera solo una herramienta, no una solución universal.

Comentarios específicos sobre el playground

  • La recepción general del playground de HTMX es muy positiva.
  • Sugerencias: mejor soporte móvil, salida de errores mejorada, posibilidad de limpiar los registros de red y algunos debates sobre el editor (Ace vs Monaco).