Seeking Insights on HTMX: Advantages and Limitations Discussed in 'Modern Frontends with HTMX

[Albert Attard]

Good morning everyone.

I'm reaching out to discuss the book "Modern Frontends with HTMX."

After watching several videos on HTMX, I found the technology quite intriguing.  My exploration into HTMX has been limited, partly due to a scarcity of in-depth resources, so I was thrilled to discover your book on the subject.  Thank you for contributing this valuable resource to the community.

I have a couple of questions that I hope you might shed some light on:

Could you outline the primary advantages of using HTMX over other frontend frameworks? I'm interested in understanding what makes HTMX stand out in specific scenarios or use cases.

Are there situations where HTMX might not be the optimal choice, and more traditional or alternative frameworks could provide better solutions? I'd appreciate insights into any limitations or considerations when deciding whether HTMX is the right tool for a project.

Thank you in advance for your time and insights.

[Frank Delporte]

Consider htmx as a server-first approach. The server generates HTML output, gives it to the client (via HTTP request or WebSocket), and the client "swaps" one or more existing HTML elements with the new HTML it received from the server.

So that's the biggest difference compared to the approach we now use with most frameworks where API JSON is received from the server, and it needs to be handled on client side into a HTML structure.

[Tim Moores]

Frank,

since you mention swapping the contents of one element with another, is HTMX an SPA approach?

[Frank Delporte]

Yes indeed, mainly SPA-approach. Or you swap elements on one page, and leave other buttons as links to new pages that again can have swaps with htmx for certain elements.
As always with software... it depends (on your use-case)

[Albert Attard]

Hello folks,

First off, I'd like to express my gratitude for your insights so far.

To my understanding, HTML has been the preferred format for data exchange between the server and the client when using HTMX.  For instance, if there's a need to display a list of items to the user, the server would typically format this information into HTML and send it over as such.

I'm curious to gather your thoughts on this matter, especially in the context of how JSON has changed the interaction between the backend and frontend.  With JSON, the backend doesn't need to concern itself with how the data will be presented.  The same dataset (e.g., a JSON array of items) could be rendered in various ways by the frontend, such as an HTML list, table, or a collection of DIVs.  This separation seems to suggest a more decoupled architecture, where the backend is agnostic of the frontend's presentation logic.

Sending data as HTML, on the other hand, implies a tighter coupling between the backend and frontend, as the backend pre-defines the presentation format.  I'm eager to understand your perspectives on this approach.  Does the advantage of using HTML for data exchange outweigh the flexibility and separation offered by JSON, or are there specific scenarios where one is clearly preferable over the other?

I look forward to your thoughts and insights on this topic.

[Frank Delporte]

Indeed the coupling is very strict, as in your example, the server returns a full ul-li-list or a single li-element to add to an existing ul-list. So full formatted HTML indeed.
But be honest, in how many cases in your application is the exact same JSON-data used for different HTML-output?
As in all cases, htmx is no replacement for all JSON or other data formats between client and server, but it can definitely simplify the client side in specific use cases.
I see htmx as a perfect technology for a UI where certain elements need to be swapped with others, or items need to be added or removed from a list or table.

[Wim Deblauwe]

Hi,

About HTML as data exchange format:

"Sending data as HTML, on the other hand, implies a tighter coupling between the backend and frontend, as the backend pre-defines the presentation format. "

In fact, the inverse is true. With a JSON format, your frontend needs to be built for the data that is sent as you are missing a lot of information in most JSON Data API's (usually called REST APIs). There is no information on the other endpoints you can call for example. So in most cases, there is some out-of-band knowledge needed on the (JavaScript) frontend to make everything work.

With HTML, the full interaction is part of the HTML. There can be buttons and links in the HTML that allow further interaction, without the need of the client to know this. It just renders the HTML and everything works. There is no need to update 2 applications in lock-step.

This also avoids problems around versioning the REST API. The server just returns the new "version"/html in case of server-side rendering and the browser renders it. With a Single Page Application, you need to make sure the frontend is updated to deal with the updated REST API.

regards,

Wim

[Albert Attard]

Thank you all for your insightful contributions.

I've been following our discussion closely and am now convinced to give HTMX a try.  It's clear there are numerous advantages to be explored, and I'm eager to see these benefits in action within my own projects.

Diving deeper into a specific aspect of our conversation—versioning.  As we all know, managing versions in any distributed system can present its own set of challenges.  I'm curious if anyone here has personal anecdotes or experiences dealing with versioning, especially within the context of HTMX.

To illustrate, let's consider a hypothetical scenario: a large application is deployed across hundreds of pods or containers, utilizing a ramped slow rollout strategy.  This process might take around 15 minutes to complete, during which users could be interacting with different versions of the application.  How have you navigated similar situations, or what strategies might you recommend to mitigate potential issues arising from such a scenario?

I'm looking forward to hearing more of your stories and suggestions.  Your willingness to share has been invaluable, and I'm thankful for the knowledge exchange we've had so far.

[Wim Deblauwe]

Interesting question that maybe warrants its own topic on the forum here.

For a non-rolling rollout case, htmx is easier regarding versioning. The server just sends the updated HTML to the browser. There is no chance that the old JavaScript application cannot talk to the updated server.

Although, in all honesty, there are scenario's thinkable that your browser loads a page, and before htmx does a request to fetch an html snippet to swap, the server is updated and that call is either not possible anymore, or the returned html is not structured in a way that makes sense for the html that is already in the browser. In that case, the user will have to do a page refresh or you could always send a version number with all htmx requests and the server could check that. If it notices the version is different, it can force the browser to do a full-page refresh using the HX-Refresh header.

However, for rolling rollouts, I am not sure, I have never had to work with them.

[Albert Attard]

Thank you all for sharing your thoughts.  This has been very insightful.