How I use HTMX with Go

Original Article ↗ Hacker News Discussion ↗

Server‑rendered HTML enhanced with HTMX is emerging as a popular alternative to heavy JavaScript frontends for Go web developers, who value simpler mental models, fewer build steps, and the ability to ship “one binary” apps. Commenters share stack patterns (e.g., Go + HTMX + SQLite, Datastar, templ) and tooling for templating, SQL, and streaming, while also noting pain points such as Go’s html/template ergonomics, complex interactive components (like rich data grids), and team resistance to non-React approaches. Many see HTMX as ideal for CRUD-style apps and dashboards but less suited to highly interactive, shared‑state UIs, where frameworks like SvelteKit, LiveView, or React may still be a better fit.

Overall sentiment on Go + HTMX

  • Many commenters strongly like Go + HTMX for small–medium web apps: fast, simple deployment, “one binary,” minimal JS, and leveraging traditional server‑side rendering.
  • HTMX is praised for replacing repetitive vanilla JS event/DOM boilerplate with declarative attributes, especially for CRUD, dashboards, admin UIs, and “hypertext‑native” designs.
  • Several people report using similar patterns with other backends (Rust, Python, ASP.NET Razor Pages, Kotlin, Bun stack).

Stacks, tooling, and templating

  • Popular “stacks” mentioned: GUS/HUGS (Go/HTMX/Unix/SQLite), GoTH, Go + Datastar, PAHG (Pico.css/Alpine/HTMX/Go).
  • Common Go tools: templ, gomponents, sqlc, jet, goose, OpenAPI generators, SQLite libraries, durable workflows, browser automation, etc.
  • Strong interest in type‑safe HTML and SQL: templ, gomponents, JSX‑style or DSL‑style HTML (Kotlinx.html, gsx, JinjaX, tagged template literals).
  • Several dislike Go’s html/template ergonomics (cloning, stringy templates); others defend it as secure and straightforward when used differently.
  • One thread asks for more “production‑ready” writeups: asset bundling, hashing, dev servers, hot reload, and managing the few JS dependencies.

Use cases, limits, and alternatives

  • Many say HTMX shines for simple to moderately complex apps; pain appears with:
    • Highly interactive components (rich data grids, complex filters, virtualization).
    • Shared state across many interconnected components.
    • Real‑time multi‑user collaboration.
  • In those cases, people report better experiences with Svelte/SvelteKit, React, Vue, or Elixir Phoenix LiveView.
  • Datastar and Unpoly are cited as alternatives closer to “full reactivity” while still HTML‑centric; Datastar is praised for power/size but partly commercial and (per one comment) weaker on progressive enhancement.
  • Some argue HTMX intentionally pushes you away from mobile‑app‑style UIs toward classic web flows; others see this as a constraint.

Security and Hyperscript

  • Hyperscript is liked as a way to handle client‑side state/DOM changes without separate JS files.
  • Debate centers on CSP: inline or evaluated code can force weaker policies; extensions and nonce‑based approaches are mentioned as mitigations.
  • Consensus: with strict CSP and proper server validation, risk can be managed, but CSP details matter.

Team dynamics, popularity, and meta

  • Multiple reports that teams resist HTMX as “not serious” or unfamiliar, or lack basic understanding of forms/SSR.
  • Others face the inverse: organizations entrenched in React SPAs despite scaling issues.
  • Some say HTMX’s limited scope and growing complexity for large apps explain why it isn’t “ultra popular”; others report medium/large apps working fine when abstractions are designed carefully.
  • One commenter notes more original deep‑dive posts may stand out now because fewer people blog in depth, which might explain repeated HN front‑page appearances.