React vs HTMX: Why we chose HTMX?

When should you choose HTMX over React and vice versa? I recently faced that choice at work. I thought it might be helpful for you to discuss why we chose HTMX in this case.

What were the problems were we were facing?

Let’s set the context. I work at EcoTree, an e-commerce website. Since I didn’t create the company, I inherited a backend stack using PHP (and a framework called Symphony).

Now, there is a customer area where you can manage everything you’ve purchased and create gifts to send out. That functionality requires a intricate interactions and a polished user experience, so we used React to code it.

This part of the website is behind a authentication gate. It is not intended to be indexed by search engines. This means it does not matter as much that it takes a second or two to load.

However, we do want Google to index and rank the rest of the website. For SEO purposes, page speed counts. We want the website to load as fast as possible. Therefore we render the page server side. We use Symfony’s templating engine (Twig). Most of the content on the page is static.

However, this is an e-commerce website, so each page displays the basket.

And when the user adds or removes articles from the basket, we want the basket’s counter and content updated to be updated.

Currently, this relies on an ancient jQuery library called SimpleCart that is no longer supported. That library stores data on the user’s browser using local storage.

However, this means that if the client doesn’t go through with the purchase, we don’t know about it. We can’t let the user know the article they intended to purchase is about to be sold out. Because we don’t know what the user has added to their cart.

We can’t detect in the data if there is a problem in the user experience between adding articles to the cart and checking out. Because we don’t know which users have added articles to their cart.

This means we need to must move the data to the server.

We explored three ways to do this.

The first was to update the page using the server side rendering.  When an item is added or removed from the basket, we could request a new page and have the server

refresh the page completely.

However, that would produce an uncomfortable user experience, with a white page flash on every interaction. We don’t want that. We want the user experience to be as smooth as possible.

The second option is to wire everything up with React and use it to interact with a server-side API. That might allow us to produce the user experience we want.

However, it has two problems.

The first is that, in my experience, React apps tend to get bloated. We add this library and that library, and before you know it, you have a big bundle of JavaScript to download.

That slows down the page and hurts our SEO and conversion rate.

The bundle size could be solved with a lot of discipline, but there is another problem.

Let’s take a look at a generic landing page.

We have our content, and then, in the middle of the page, we have a section that shows articles you can buy.

Three things should happen when we add an article to the cart.

• We want a popup to appear asking you if you want to checkout or continue your purchase

• We want the counter badge on the cart icon to update

• We want the content of the cart dropdown to be updated.

We have UI components in completely different places on the page that need to be connected together. This same structure is repeated across different pages.

Plugging all of these together with React would be complicated.

That is why, even though we already use React elsewhere, we decided to use HTMX for this functionality.

It allows us to connect our different user interface elements and update the display based on server-side logic. Using HTMX, we wire the click on the add to cart button to send a message to the server, and then use the response to update part of the interface (here, the cart and dropdown).

HTMX allows us to connect different interface elements in a static page, based on the server state,  without reloading the page.

So in short HTMX was a better solution for us than React (or than other frontend frameworks) for :

• managing interface updates based on server side (i.e. significant) state
• when connecting different UI elements
• that are split out over a mainly static page

However it is worth nothing here that HTMX is not suited to managing transient or pure UI state. For example we don’t use HTMX to manage whether the cart dropdown is open or not.

This also means that complex interfaces, where the user needs immediate feedback, where interactivity is more important than security, would be more difficult to implement in a pure HTMX context.

Which is why, in the React vs HTMX debate, we’ve actually chosen both, depending on the use case.

Let me know what you think, and what you’re intending to chose or to learn. And read on if you’re interested in learning more about HTMX or about React.