Hey, author here! Ask me anything!

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/

▲

yawaramin 2 days ago | parent | next [-]

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.

	▲	bookofcooks a day ago \| parent [-]
		> 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).

▲

exiguus 2 days ago | parent | prev [-]

That was really good reading. Lately, I've often heard the statement 'HTMX is frontend for backend developers.' What do you think of that quote?

	▲	bookofcooks 2 days ago \| parent [-]
		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."