HTMX is the simplest front-end framework there is: it essentially swaps an HTML node in the DOM with content found at another address. Perhaps, there is no need for anything more complex.
HTMX, and the old that is new again.
HTMX discusses REST, web design, and how to effectively design. I agree with their perspective. The front-end framework movement has let me and others down. Front-end engineers have been building entire new applications within web pages, creating UI nodes, and organizing them, then rendering such pages. I argue that they have been reinventing HTML repeatedly, innumerable times, without reason.
The reason for the SPA framework, it is not a good reason
The SPA paradigm is designed so that users experience a “desktop application” feel, although the necessity of this can be questioned. It also aims to reduce the data exchanged between the front end and the back end. Alternatively, rendering a complete new page for each interaction, in a portal style, can also provide a “desktop application” feel, whatever that might imply. This approach opens the question of minimizing server payloads: I argue that by using compressed streams, significant efficiency can be gained, allowing us to afford server-side rendering of applications into universal HTML.
This is about me, my productivity
When I am making applications, whether for myself or in my capacity as an engineer, I always strive to be as effective as possible. It is part of what being an engineer entails. The separation between front end and back end is artificial. What users experience is a seamless whole, and a client for multiple applications on the back end can also be written as another back end. In that application, one can use HTML, incremental rendering, and easily refresh content while partially loading data. This is what HTMX is about: allowing me to define rendering and interaction in plain HTML, thus avoiding the need to build a new rendering engine.
The new days, that are now old
We would write a “JSON” back end, perhaps prepare an OpenAPI contract with our front end, and they would write the application that loads our JSON and renders it to a new language with new widgets they developed, which would ultimately become a specialized version of HTML.
The old days, that are now new
We could simply have a standard HTML page, utilize partial rendering and AJAX with innerHTML, and, by emitting the
necessary HTML fragment, just swap the part we want to update.
How difficult can that be?
Not so difficult, as one might expect. Here’s an example of an app that produces the same data object for both JSON and HTML consumption. As you can see from the main controller, the same method retrieves the correct data for the rendering layer, which can be customized. I’m confident that I don’t really need two controllers; it should be enough to configure the content negotiator. Maybe next time.