htmx: the unexpected ally of modern backend

For some years, a library has made its way almost silently, revolutionizing the way we understand the interaction between browser and server. Today, the web front-end is dominated by frameworks like React, Angular, Vue, Svelte, but there is a new actor and it is absolutely protagonist, especially for next-generation applications.

It is called htmx, and it was released in 2020. Today it has over 45k stars on GitHub and just a couple of years ago it was ranked second among the fastest-growing front-end frameworks. But what makes htmx so interesting, especially for those developing serverless applications?

htmx is a JavaScript library that allows leveraging modern browser functionalities directly from HTML, without writing JavaScript code. It is a sort of ‘enhancement’ of the markup language, which remains at the center of the architecture. And here comes one of its strongest aspects: adherence to the classic REST model, in which HTML itself represents the application state.

With a few lines of code, this library allows interacting with the server through dynamic HTTP requests, using simply HTML attributes. Without writing JavaScript. Without configuring a client router. Without creating a ‘state manager’. Just HTML, but enhanced.

In htmx, any DOM element can send a request, and any event can be used as a trigger. You are not limited to classic clicks or submits. It is possible to react to a mouse enter, a scroll, or set automatic polling. And you are not bound to GET or POST: you can also use PUT, PATCH, DELETE.

The underlying idea is to extend the ‘hypermedia’ behavior of HTML, recovering the concept that the Web was born with: every interaction is a state transition guided by hypertexts. You do not return JSON data to interpret; you return HTML directly to insert into the page.

This philosophy marries surprisingly well with serverless architectures because each endpoint is an autonomous function, often deployed on platforms like Vercel or AWS Lambda.

Being able to build a user interface entirely based on pieces of HTML means reducing infrastructural complexity, improving response times, and having an application that can scale linearly with traffic.

Let’s see an example: suppose we want to show a list of heroes following the click of a button. With htmx it is enough to write:

<button hx-get="/heroes" hx-target="#hero-list"> Load Heroes!</button>

<div id="hero-list"></div>

When the user clicks the button, a GET request is sent, a fetch, to the /heroes endpoint. The server responds with an HTML fragment, such as:

<ul>
  <li>Ranieri</li>
  <li>Marco</li>
  <li>Hero 1</li>
  <li>Hero 2</li>
  <li>Hero n</li>
</ul>

htmx takes care of inserting it automatically inside the div with ID hero-list, replacing the previous content. The effect is immediate, reactive, and extremely simple to implement. There is no need to build the markup on the client side: the server does it, which remains at the center of the application.

Those coming from React or Vue might ask: and the state? And animations? And routing? All things possible, but to be approached from a different perspective. For example, htmx natively supports CSS transitions, using the hx-swap attribute and a small delay called ‘settle’. If a replaced element keeps the same ID and changes class, you can get a smooth transition without a line of JS.

A more dynamic example? Consider an automatic polling that updates every two seconds a section with the latest notifications:

<div hx-get="/notifications" hx-trigger="every 2s" hx-target="#alerts"></div>

<div id="alerts"></div>

In a serverless context, this is pure gold.

On the server side, you can return an updated HTML fragment every time there are new notifications, without maintaining WebSocket connections and without persistent infrastructures.

Moreover, htmx supports features like browser history management (hx-push-url), integration with custom events (hx-on:), loading indicators (htmx-indicator), request synchronization (hx-sync), and targeted element selection (hx-select). All using only HTML attributes, with a minimal learning curve.

Another advantage, often underestimated, is accessibility. Applications built with htmx are, by default, more accessible. Links remain links and forms remain forms. With the hx-boost attribute, you can transform all links and forms into AJAX requests, but keeping the traditional behavior as fallback.

Obviously, it is not the right tool for every project. If you need a hyper-interactive interface, with intensive client-side state management, complex components, and real-time updates on a large scale, you are probably better off looking elsewhere. But if the heart of the application is server-centric, and what you need is a dynamic but linear frontend, htmx can drastically reduce complexity.

It is worth clarifying, though, that htmx is not an SSR framework.

SSR (Server-Side Rendering) indicates a mechanism in which the entire page (or part of it) is generated by the server and then sent to the browser, typically in response to an initial request or navigation. htmx does not generate HTML itself, nor does it handle server-side rendering. It is rather an HTML orchestration mechanism on the client side: it allows the client to send HTTP requests via HTML attributes, and to insert HTML fragments returned by the server directly into the DOM. htmx relies on a back-end that generates HTML, so it uses SSR responses (HTML fragments generated by the server) instead of REST/JSON APIs. The typical architecture with htmx is server-driven: the client (htmx) asks, the server responds with ready-to-inject markup. This is very similar to SSR, but happens incrementally and dynamically, without reloading the entire page. htmx is not an SSR rendering engine like Next.js can be, but it is complementary to an SSR back-end.

In short, htmx offers a rare possibility in the current landscape: building modern web apps without giving up the original simplicity of the Web.

And for those developing in serverless environments, it is a concrete opportunity to do much more, but with less.