htmx

htmx lets an ordinary server-rendered page do what people expect of a modern interface (update in place, load on demand, submit without a reload) using HTML attributes instead of a client-side application.

Why we still choose it

The usual alternative is a single-page front end, and that is a lot to take on: 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. Most organisations need forms, tables, dashboards and admin screens, and for those it is a great deal of machinery for a small amount of interactivity.

With htmx the server keeps rendering HTML, as it already does for Rails, and a few attributes say which fragment to replace and when. There is one language and one deployment to look after.

Where it fits

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

Where it falls short

For something that really is application-shaped, such as a collaborative editor, a drawing tool or 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 change in design. The selection of ready-made components is modest, so you will write more of them yourself.