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 if you’re interested in
learning more about HTMX or about React, well, I’ve got just the video
for you ! I’ll see you there.
