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!

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.

Why is every developer trying to make things complicated?

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.

In datastar the "Out Of Band" updates is a first class notion.

[1] https://data-star.dev

This blogpost affirms it

Why not use cookies?

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 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/