I built my latest SaaS (https://clarohq.com) using HTMX, backed by Django. I really enjoy the process because HTMX allows reactivity using swaps and plain Javascript events instead of server side state management, useeffect, and API endpoints.
However, it's difficult to get things right. I spent way too much time on some basic features that I could have shipped quicker if I used React.
The issue with React though, is that you end up with a ton of dependencies, which makes your app harder to maintain in the long-term. For example, I have to use a third-party library called react-hook-form to build forms, when I can do the same thing using plain HTML and a few AlpineJS directives if I need dynamic fields.
I'm not sure if I'll ever build an app using HTMX again but we need more people to write about it so that we can nail down patterns for quickly building server rendered reactive UIs.
I read through this and I don't get it. Recreating an entire form on the backend and swapping it with the current one, and then missing the update of the label status?
Then solving this by recreating the entire stepper html at each step, with the added complexity that if it contains something you want to keep "it's a nightmare"?
Then having to create a temporary server-side session to store data that somehow the browser can't keep between two clicks?
HTMX is indeed simple and lean, but unfortunately that doesn't mean solving common frontend problems with HTMX is simple either. After a decade of frontend dev and being tired of react/vue/etc, I tried HTMX, wanting for something leaner, but IMHO it has big problems, and I am back to react/vue.
The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare.
The other is that the code of components is split in two, the part that is rendered on the first time, and the endpoint that returns the updated result. You need a lot of discipline to prevent it from turning that into a mess.
The final nail on the coffin for me was that the thing I wanted to avoid by picking HTMX; making a rest api to separate the frontend and the backend, was actually a good thing to have. After a while I was missing the clean and unbreakable separation of the back and front. Making the rest api was very quickly done, and the frontend was quicker to write as a result. So HTMX ended up slower than react / vue. Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
These kinds of write-ups are so key to driving adoption of a new technology. I'm still not super interested in HTMX but this write-up has done a lot of the work already toward nudging me that way. Well done!
Yes, as I remember it it was a 'back to simplicity' of the early web idea. Rediscover the power of hypermedia. I don't know HTMX well, but am following Datastar [0] which was inspired by it, and their selling points are Simplicity and Performance and take it some steps further than HTMX. The approach does shift logic / complexity towards the backend though.
In DS, with SSE you can paint different parts of the page with ease. So in this case, it can update <form> and <label> separately. So instead of one update the backend fires 2. There is not separate marker or indicator for OOB.
I think it is best seen in examples on DS website.
Every time I attempt to use HTMX and backend-rendered templates because it's "simpler", in the end I always end up doing JSON APIs and something like Svelte. Because all the "simplicity" explodes in complexity 5 seconds later, and it's very user-hostile with the constant reloads.
This implementation is unnecessary complicated. For the step update, you can use Out Of Band update: https://htmx.org/attributes/hx-swap-oob/ which works in a way that you can send multiple HTML fragments which can be anywhere on the page and HTML swaps them out. Good for notifications, step update, breadcrumb update, menu highlight, etc...
I usually solve the second problem by simply saving the state of the individual input fields, you only need a user session.
Depending your use-case, you might need to be transactional, but you can still do this saving everything as "partial" and close the "transaction" (whatever it might mean in the given context) at the last step. Much-much simpler than sending form data over and over.
> I originally planned to make a simple non-functional uploader, then progressively bring it from "it works™" to "high-quality production-grade Uploader with S3 Presigned, Multipart, Accelerated Uploads, along with Auto-Saving and Non-Linear Navigation
Why is every developer trying to make things complicated?
They could have done all that in one long form with JS for client side progressive enhancement (show/ hide different parts) and that would probably be much easier.
However, it's difficult to get things right. I spent way too much time on some basic features that I could have shipped quicker if I used React.
The issue with React though, is that you end up with a ton of dependencies, which makes your app harder to maintain in the long-term. For example, I have to use a third-party library called react-hook-form to build forms, when I can do the same thing using plain HTML and a few AlpineJS directives if I need dynamic fields.
I'm not sure if I'll ever build an app using HTMX again but we need more people to write about it so that we can nail down patterns for quickly building server rendered reactive UIs.
Then solving this by recreating the entire stepper html at each step, with the added complexity that if it contains something you want to keep "it's a nightmare"?
Then having to create a temporary server-side session to store data that somehow the browser can't keep between two clicks?
Etc.. it's write web apps like it's 1999.
The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare.
The other is that the code of components is split in two, the part that is rendered on the first time, and the endpoint that returns the updated result. You need a lot of discipline to prevent it from turning that into a mess.
The final nail on the coffin for me was that the thing I wanted to avoid by picking HTMX; making a rest api to separate the frontend and the backend, was actually a good thing to have. After a while I was missing the clean and unbreakable separation of the back and front. Making the rest api was very quickly done, and the frontend was quicker to write as a result. So HTMX ended up slower than react / vue. Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
[0] https://data-star.dev
In datastar the "Out Of Band" updates is a first class notion.
[1] https://data-star.dev
[0] https://htmx.org/attributes/hx-swap-oob/
I think it is best seen in examples on DS website.
This blogpost affirms it
Why not use cookies?
I usually solve the second problem by simply saving the state of the individual input fields, you only need a user session. Depending your use-case, you might need to be transactional, but you can still do this saving everything as "partial" and close the "transaction" (whatever it might mean in the given context) at the last step. Much-much simpler than sending form data over and over.
Why is every developer trying to make things complicated?
I think at least some of these issues can be avoided with a different UI/UX to avoid passing temporal/unsaved data between screens.
looking forward to the next instalment!