Tag: web architecture

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 an evergreen frontend architecture link because URL state is not just routing trivia. It affects sharing, refresh behavior, deep links, browser history, analytics, support, and whether a product feels native to the web.

The caveat is that not every bit of state belongs in the URL. The discipline is deciding which state is part of the user's task context.

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.

This is a useful frontend architecture link because it pushes beyond taste and asks what tradeoffs teams inherit when React becomes the default answer.

It belongs next to the React runtime links, not against them. Better engineering judgment comes from understanding both why a tool works and where it costs too much.