I want to make the intent of this blog post extremely clear (which tragically got lost when I got deep into the writing).
I love HTMX, and I've built entire sites around it. But all over the internet, I've seen HTMX praised as this pristine perfect one-stop-solution that makes all problems simple & easy (or at least... easier than any framework could ever do).
This is a sentiment I have not found to be true in my work, and even one where the author of HTMX spoke out against (although I can't find the link :(
It's not a bad solution (it's actually a very good solution), but in real production sites, you will find yourself scratching your head sometimes. For most applications, I believe it will make ALMOST everything simpler (and lighter) than traditional SPA frameworks.
But for some "parts" of it, it is a little tricker, do read "When Should You Use Hypermedia?" [1];
In the next blog post (where we'll be implementing the "REAL" killer features), I hope to demonstrate that "yes, HTMX can do this, but it's not all sunshine & rainbows."
---
On a completely separate note, one may ask, then, "why use HTMX?" Personally, for me, it's not even about the features of HTMX. It's actually all about rendering HTML in the backend with something like Templ [2] (or any type-safe html templating language).
With Templ (or any type-safe templating language), I get to render UI from the server in a type-safe language (Golang) accessing properties that I KNOW exist in my data model. As in, the application literally won't compile & run if I reference a property in the UI that doesn't exist or is of the incorrect type.
You don't get that with a middle-man API communication layer maintained between frontend and backend.
All I need now is reactivity, and htmx was the answer. Hope you understand!
Looking at the solution you ended up with, I feel like it's actually fairly reasonable in terms of implementation complexity compared to the feature it is delivering. I have a hard time believing that a pure SPA approach would be simpler to implement. Certainly a SPA would deliver a much more bloated JS payload to the client, which really doesn't seem like a good tradeoff for basically filling out a form and uploading a couple of files.
> I have a hard time believing that a pure SPA approach would be simpler to implement.
IF you used a pure SPA approach with client-side validation for each step, and server-side validation only done at the last step, I believe it would be simpler.
However, let's say you introduce anything slightly more complicated. Like say you do server-side validation with each step, now you have to somehow persist that "validated data". In that case, the implementation in the article is indeed simpler (or at least not as complicated as a traditional SPA).
I've found for state machine on the front end which uses mostly data that is already on the front end that using a lib like VanJS can be very nice and useful. Using the correct paradigm for the problem is nice. This would be over kill for the problem mentioned in this post though.
Honestly, I think the frontend for backend developers has always been those simple Multi-Page Applications. I know they're not the hottest new thing, but they've been around, they work, and they've had time to integrate deeply into langauages & browsers (think PHP for example).
Maybe it's more accurate to say, "HTMX is frontend for backend developers who want a SPA."
Yes, going from SPA-like libs to hyper text libs is definitely a change in how you use your mind and approach problems. It's like going from OO to Functional-style programming. It really messes with the brain. But eventually you learn to love both paradigms and see the good and both and then you start using both patterns in your code, which really messes with other devs as they see both patterns being used.
I've been programming on personal projects with html-form (my own lib that is a radically paired down version of HTMX with a focus on using native form controls, which makes it so you don't need hydration like you do in HTMX).
So, some thoughts on your problem.
One note. Many people mention OOB. But there is also hx-select, which can be quite handy.
I think there are multiple different approaches that are possible, that I can think of, depending on your needs.
Use eventing. On the server create an event that will be called on the front end by HTMX. When this is called have some vanilla JS that updates the class on your location in the form.
Send all the forms down and have them only visible based on CSS or using an input element is checked or not or using JS. That would be pretty straight forward.
If the form passes then replace all the body contents or main element. If it doesn't just update the form and add any user information. Or send an event back which causes a popup to tell the user what their issue is. Or send an even that causes some text to show.
Also, you can also use CSS and native HTML form validation that will show text underneath an input (or above the input) that tells the user what the the input requires. Modern CSS has a pseudo selector which only turns on when the input is invalid[1].
This is simple enough that a straight up MPA could be used with page animations between pages using view transitions[2].
Similar to one of the solutions above, but using data-action style of programming.[3]
I want to make the intent of this blog post extremely clear (which tragically got lost when I got deep into the writing).
I love HTMX, and I've built entire sites around it. But all over the internet, I've seen HTMX praised as this pristine perfect one-stop-solution that makes all problems simple & easy (or at least... easier than any framework could ever do).
This is a sentiment I have not found to be true in my work, and even one where the author of HTMX spoke out against (although I can't find the link :(
It's not a bad solution (it's actually a very good solution), but in real production sites, you will find yourself scratching your head sometimes. For most applications, I believe it will make ALMOST everything simpler (and lighter) than traditional SPA frameworks.
But for some "parts" of it, it is a little tricker, do read "When Should You Use Hypermedia?" [1];
In the next blog post (where we'll be implementing the "REAL" killer features), I hope to demonstrate that "yes, HTMX can do this, but it's not all sunshine & rainbows."
---
On a completely separate note, one may ask, then, "why use HTMX?" Personally, for me, it's not even about the features of HTMX. It's actually all about rendering HTML in the backend with something like Templ [2] (or any type-safe html templating language).
With Templ (or any type-safe templating language), I get to render UI from the server in a type-safe language (Golang) accessing properties that I KNOW exist in my data model. As in, the application literally won't compile & run if I reference a property in the UI that doesn't exist or is of the incorrect type.
You don't get that with a middle-man API communication layer maintained between frontend and backend.
All I need now is reactivity, and htmx was the answer. Hope you understand!
[1] https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-h...
[2] https://templ.guide/