Tag: htmx

Alex Edwards turns the usual "use HTMX with server-rendered HTML" advice into a practical Go shape: a renderer that knows when to return a full page or a partial, embedded assets, explicit Vary: HX-Request handling, and response rules for history, redirects, and errors. That structure is the real resource here. The point is not less JavaScript as an aesthetic victory; it is keeping requests, templates, and browser navigation understandable as one system.

The Hacker News conversation supplies the boundary conditions. This stack can be fast to build, easy to ship, and a very good fit for forms, search, CRUD, and page-oriented workflows. But once many fragments share state and coordinate complex interactions, the local simplicity can turn into a hard-to-follow interaction graph. HTMX works best when the application can stay close to the web's request-and-response model, not when it is asked to disguise a client application with a different set of needs.

This is worth keeping because it questions the default assumption that app-like experiences require a full client-side framework. That is a healthy pressure test for product architecture.

The useful takeaway is not "always use htmx." It is that interaction patterns should fit the job, the team, and the maintenance cost.