HTMX: apparent simplicity, real complexity

Posted by

  

In recent years, the world of web development seems to swing like a pendulum: first SPAs everywhere, then the return to server-side rendering, now a new promise of simplicity called HTMX. Some consider it a small revolution, others see it as the "right" way to make web in 2025. Me? I'm more skeptical. Much more skeptical.

In this article we will see what HTML is, what it is used for, how to use it, some practical examples, and finally — inevitably — I will explain why, while recognizing its merits, I don't agree with this approach to building truly solid and maintainable software.

🔗 Do you like Techelopment? Check out the site for all the details!

What is HTMLX

HTMX is a JavaScript library (not a framework!) that allows you to extend HTML with special attributes (hx-*) to make HTTP requests (AJAX, fetch, WebSocket, SSE) and update portions of the page without writing explicit JavaScript.

In other words: we're back to writing "smart" HTML that talks directly to the server.

Minimal example:

<button hx-get="/saluto" hx-target="#output">
  Click Me
</button>

<div id="output"></div>

When the user clicks the button, HTML makes a GET request to /saluto and inserts the HTML response into the div#output.

Simple. Very simple.


What is HTMLX for?

HTMX was created to solve a real problem: the excessive complexity of modern SPAs.

For many projects:

  • React / Vue / Angular are overbuilt
  • The boilerplate is huge
  • The JS bundle is growing
  • The logic is scattered between the frontend and backend

HTMX proposes a different philosophy:

  • The server returns to being the center of the logic
  • The frontend is (almost) all HTML
  • Dynamic interactions occur via HTML fragments returned by the backend

It is particularly appreciated in combination with:

  • Classic MVC backends (Django, Rails, Laravel)
  • Typed server-side languages
  • CRUD projects, dashboards, backoffice

How to use HTMLMX

Using HTMLMX revolves around the hx-* attributes. The main ones are:

  • hx-get, hx-post, hx-put, hx-delete
  • hx-target: where to insert the response
  • hx-swap: how to insert the response
  • hx-trigger: when to trigger the request

Example with form:

<form hx-post="/login" hx-target="#message" hx-swap="innerHTML">
  <input name="username">
  <input type="password" name="password">
  <button>Login</button>
</form>

<div id="message"></div>

No JavaScript. No fetch. No framework.

And this is where many begin to fall in love.


Practical examples

Partial loading of a list

<button hx-get="/users" hx-target="#list"> 
  Load users
</button>

<ul id="list"></ul>

The server returns:

<li>Mario</li>
<li>Luigi</li>
<li>Pietro</li>

Infinite scroll

<div hx-get="/feed?page=2"
  hx-trigger="revealed"
  hx-swap="afterend">
</div>

It works. It's elegant. It's quick to write.

And that's exactly the problem.


The awkward part: why it doesn't convince me

Let's get to the point. HTML works. I won't deny it. But my criticism isn't about "it works or not," but rather what kind of software you're pushing to build.

1. Tight coupling between frontend and backend

With HTMLX, the backend returns ready-made HTML. This means:

  • The server knows the details of the UI
  • Markup becomes an implicit contract
  • Changing a view means changing server logic

We're merging presentation and control as if MVC hadn't taught us anything in the last 20 years.

2. Distributed Logic in HTML Attributes

When application behavior is hidden in hx-* attributes scattered throughout the markup:

  • It's hard to refactor
  • It's hard to find logic flows
  • It's hard to debug

The code "isn't where you expect it."

3. Questionable cognitive scalability

At first, the project is small:

"Look how clean it is! Just HTML!"

After a few months:

  • Server-side conditions to decide what HTML to return
  • Duplicate fragments
  • Endpoints created just to update pieces of the DOM

Complexity doesn't go away, it's just moved.

4. Weaker testability

Testing:

  • Well-defined JSON APIs → easy
  • Isolated frontend components → possible
  • Endpoints that return partial HTML with embedded logic → much less

HTMX makes it more difficult to separate layers and test specifically.

5. It's a throwback (with a lick of paint)

Let's be clear: HTMLX is a refined version of what we used to do with:

  • jQuery
  • .load()
  • partial view

Just because it's more elegant today doesn't automatically make it an architectural advance.


When it can make sense

Despite the controversy, HTMLX is not an absolute evil.

It can make sense if:

  • The project is small or medium-sized
  • The team is small
  • The UI is simple
  • The backend is already MVC
  • The expected project duration is limited

In these cases, HTML5 can be pragmatic.

But let's not call it "the right way" to make a modern frontend.


Conclusion

HTMX promises simplicity, and delivers it… in the short term.

But software development isn't a demo, it's a marathon. And in a marathon, the following count:

  • Separation of responsibilities
  • Clear architecture
  • Testability
  • Maintainability over time

HTMX is a tool. Using it everywhere as a universal answer is, in my opinion, a mistake.

Because yes, you can avoid JavaScript today.
But you're just putting off a complexity that will come back to bite you tomorrow, with interest.

And no, another hx-* attribute won't be enough to pay for it.



Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment