Cómo uso HTMX con Go

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

El HTML renderizado en el servidor mejorado con HTMX está emergiendo como una alternativa popular a los frontends pesados en JavaScript para desarrolladores web de Go, que valoran modelos mentales más simples, menos pasos de build y la posibilidad de publicar apps de “un solo binario”. Los comentaristas comparten patrones de stack (p. ej., Go + HTMX + SQLite, Datastar, templ) y herramientas para templating, SQL y streaming, al tiempo que señalan puntos de dolor como la ergonomía de `html/template` de Go, componentes interactivos complejos (como grillas de datos ricas) y la resistencia de los equipos a enfoques no React. Muchos ven HTMX como ideal para apps CRUD y paneles, pero menos adecuado para UIs muy interactivas con estado compartido, donde frameworks como SvelteKit, LiveView o React pueden seguir siendo una mejor opción.

Sentimiento general sobre Go + HTMX

  • Muchos comentaristas valoran mucho Go + HTMX para aplicaciones web pequeñas o medianas: despliegue rápido y simple, “un solo binario”, JS mínimo y aprovechamiento del renderizado tradicional del lado del servidor.
  • Se elogia HTMX por reemplazar el boilerplate repetitivo de eventos/DOM en JavaScript vainilla con atributos declarativos, especialmente para CRUD, paneles, UIs de administración y diseños “nativos de hipertexto”.
  • Varias personas dicen usar patrones similares con otros backends (Rust, Python, ASP.NET Razor Pages, stack Kotlin, Bun).

Stacks, herramientas y templating

  • “Stacks” populares mencionados: GUS/HUGS (Go/HTMX/Unix/SQLite), GoTH, Go + Datastar, PAHG (Pico.css/Alpine/HTMX/Go).
  • Herramientas comunes de Go: templ, gomponents, sqlc, jet, goose, generadores OpenAPI, librerías de SQLite, flujos de trabajo durables, automatización del navegador, etc.
  • Fuerte interés en HTML y SQL con seguridad de tipos: templ, gomponents, HTML estilo JSX o estilo DSL (Kotlinx.html, gsx, JinjaX, literales de plantilla etiquetados).
  • A varios no les gusta la ergonomía de html/template en Go (clonado, plantillas “stringy”); otros lo defienden como seguro y sencillo cuando se usa de otra manera.
  • Un hilo pide más textos “listos para producción”: empaquetado de assets, hashing, servidores de desarrollo, hot reload y gestión de las pocas dependencias JS.

Casos de uso, límites y alternativas

  • Muchos dicen que HTMX destaca para apps simples a moderadamente complejas; los problemas aparecen con:
    • Componentes altamente interactivos (grillas de datos ricas, filtros complejos, virtualización).
    • Estado compartido entre muchos componentes interconectados.
    • Colaboración multiusuario en tiempo real.
  • En esos casos, algunas personas reportan mejores experiencias con Svelte/SvelteKit, React, Vue o Elixir Phoenix LiveView.
  • Datastar y Unpoly se citan como alternativas más cercanas a una “reactividad completa” sin dejar de ser centradas en HTML; Datastar recibe elogios por potencia/tamaño, pero es en parte comercial y (según un comentario) más débil en progressive enhancement.
  • Algunos argumentan que HTMX te empuja deliberadamente lejos de interfaces estilo app móvil hacia flujos web clásicos; otros ven esto como una limitación.

Seguridad e Hyperscript

  • Hyperscript gusta como forma de manejar estado del lado del cliente/cambios en el DOM sin archivos JS separados.
  • El debate se centra en CSP: el código inline o evaluado puede obligar a políticas más débiles; se mencionan extensiones y enfoques basados en nonce como mitigaciones.
  • Consenso: con una CSP estricta y validación adecuada en el servidor, el riesgo se puede gestionar, pero los detalles de CSP importan.

Dinámica de equipo, popularidad y meta

  • Varias personas dicen que los equipos resisten HTMX por considerarlo “no serio” o por no estar familiarizados, o por no entender bien formularios/SSR.
  • Otras se enfrentan al problema inverso: organizaciones aferradas a SPAs en React pese a problemas de escalabilidad.
  • Algunos dicen que el alcance limitado de HTMX y la complejidad creciente para apps grandes explican por qué no es “ultra popular”; otros reportan que apps medianas/grandes funcionan bien cuando las abstracciones se diseñan con cuidado.
  • Un comentarista señala que más posts originales y en profundidad pueden destacar ahora porque menos gente bloguea extensamente, lo que podría explicar apariciones repetidas en la portada de HN.