htmx

htmx lets an ordinary server-rendered page do the things people expect a modern interface to do — update in place, load on demand, submit without a reload — using HTML attributes rather than a client-side application.

Why we still choose it

Because the standard alternative is enormous. A single-page front end means a second codebase, a second build pipeline, a second set of dependencies to patch, an API layer that exists only to serve it, and often a second team. For the interfaces most organisations actually need — forms, tables, dashboards, admin screens — that is a great deal of machinery bought for a small amount of interactivity.

With htmx the server keeps rendering HTML, as it already does for Rails, and a handful of attributes say which fragment to replace and when. One language, one deployment, one thing to reason about.

Where it fits

Internal tools, admin interfaces, customer portals, search-as-you-type, progressive forms — anywhere the interaction is meaningful but the application is not fundamentally a client-side one.

The honest limit

If you are building something genuinely application-shaped — a collaborative editor, a drawing tool, an interface holding a lot of client-side state — htmx is the wrong tool and we will say so. It also asks your back end to think in fragments rather than pages, which is a small but real design shift. And the ecosystem is modest: fewer components off the shelf, more written by you.