> 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).
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."
> To avoid the cost of updating the entire page, htmx only fetches a parent element and all of its children, but this runs into the problem that you must choose the common parent element for all the elements you want to update.
Not exactly, you can use Out-Of-Band updates, which means the server can arbitrarily choose to update specific elements outside the parent.
> So the author reaches the conclusion that htmx is not meant to be used for SPA style apps. It's meant to add a little bit of interactivity to otherwise static HTML.
Can you clarify where I seemed to have come to this conclusion, as this is not what I intended to express.
Now, how I specifically embed SolidJS, its pretty simple, I have my entrypoint files for specific pages:
assets/admin-edit-book.tsx
assets/admin-edit-song.tsx
assets/single-worship.tsx
assets/worship-edit.tsx
Then I have a 30-line build script that invokes esbuild along with esbuild-plugin-solid (to compile JSX to plain-old html, no fancy virtual dom) to compile the scripts into javascript.
I can share the build script if you'd like. It helps that SolidJS is so self-contained that it makes such a setup trivial.
> For the step update, you can use Out Of Band update
I did mention using OOB, but I preferred swapping the entire Stepper because the logic on the backend was just a little bit cleaner, and the Stepper didn't include anything else anyways.
> I usually solve the second problem by simply saving the state of the individual input fields, you only need a user session.
I believe this is exactly what I did in the article, no?
Yes, this was what I wanted to get across with the article (although I utterly failed to do so). I think I would stick to HTMX for other reasons (which I've made clear in my top-level comment on this thread), but I now I see it an occasional tool to use for something simple and not long-term.
> 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.
Or you can create a large session object (which stores all the state) on the server, and have a sessionId in the URL (although I'd prefer a cookie) to associate the user with that large session object.
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!
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).