Is htmx for my use-case/am I expecting too much?

[yatesco]

Hi there. I've played around with htmx and whilst I am hugely impressed with it, I have run into a few difficulties. I fully expect "it's me, not you" and any bugs are between the chair and keyboard, so I want to check my assumptions.

Essentially, I want all rendering done on the server and when anything happens I want to replace the entire page. I'm not using hx-select and my hx-target for everything is the top most div and hx-swap=outerHTML".

For the most part, this works perfectly, but there are a few gotchas. To be explicit, I am only using hx-post, hx-target and hx-swap, on 1.8.0, and I'm not using IDs or configuring the global htmx JS object.

Scroll position on nested divs with overflow:auto

When refreshing, the scroll position is lost. It works fine for top level elements that are scrollable, but not for nested elements. If I use hx-source`hx-target` to select and refresh just the scrollable element then it does preserve scrolling.
(#1009)

Preserving state of elements

Refreshes don't preserve the state of detail elements, which seems like an oversight? (#1004)

Refreshing multiple parts of the page from the same source document

It seems like an obvious thing to be able to update multiple parts of my page from the new page. This might be more efficient than replacing the entire page, particularly given the issue with scrollable elements. So whilst I can say hx-target=".mainElement" hx-source=".mainElement" I need to another full page request to update the footer. It would be delicious ;-) to be able to do something like hx-replace=".mainElement" hx-replace=".footer" for example.

If the scrollable issue wasn't around then this wouldn't be so important.

As I say, I'm really impressed with it, and the safety and elegance of server side HTML is fantastic, but I'm tripping over a few bits that are making it more painful than I expected, and I wanted to check that I've not misunderstood HTMX.

Thanks all :-)

[David-Guillot]

Hi @yatesco ,

Here is my opinion (and as you seem unsure about your understanding of htmx, let me be talkative on the concepts):

• Your first two issues are actually the same: it's about managing UI elements state, which is not the primary feature of htmx (managing application state through HATEOAS being its primary feature). Managing UI elements state is the primary feature of Javascript-powered SPA frameworks, but using that approach comes with an insane cost on managing application state, and that's unacceptable for most products/teams because application state is so much more critical for the product just to work. In htmx world, UI elements state management can be achieved, but might sometimes feel hacky (like my advice at Preserving client side state, specifically `details` #1004 😇 ), and will sometimes require additional complexity, like when changing the way HTML fragments are swapped (see this extension)
• You're not expecting too much: you want a rich web UI (featuring fine-tuned UI elements state management) with server-side templating (for decent and pragmatic application state management), that's what many of us want, and that's precisely htmx's promise. It doesn't mean htmx is 100% there yet, because its early development focused on application state management, but it can be (because HATEOAS and fine-tuned UI elements state management are not incompatible), and it will be, for sure, especially if people like you keep using it, pushing it to its limits, and asking the right questions 😉. The fact that @1cg is actively working on a new way to swap HTML fragments into the DOM illustrates the need of a finer swapping mechanism that would allow better UI elements state management
• A quick note about your third issue, the multiple parts of the page stuff: when you need sophisticated features, be ready to write specific code. What you want is completely doable with current htmx version, by having two different templates for the same page: one that serves the entire page as an HTML document (you already have this one), the other that serves a collection of hx-swap-oob fragments to be injected into the DOM where their IDs are found ; what do you think about that?

Hope my answer is clear and useful 🤓

[yatesco]

thank you David - this is an excellent reply, as always. So I'm understanding that yes, I'm in the right place, but I've arrived a little early, which is fine :-). I'm going to test my hypothesis by experimenting with pure diffing tools like morphdom, million/morph, snabby etc., and see exactly how good the experience can get. I'll be back!

Thanks again.

[yatesco]

BTW - https://github.com/tbranyen/diffhtml is pretty flawless in terms of speed, retaining input focus, and retaining scroll positions. Pressures on, so my most expedient route might be to go with this and find a replacement for htmx's "on change post value to the server".

If I get time (which unfortunately almost guarantee's it won't happen :-() I'll look at providing an extension ala morphdom.

Thanks!

[yatesco]

Just an FYI - diffhtml is working really well. I need to call htmx.process(document.body) after it has merged the DOMs, but that's all.

[1cg]

https://github.com/bigskysoftware/idiomorph/blob/main/src/idiomorph.js

[yatesco]

thanks @1cg. Do you know how long before we can try this out?

[1cg]

I would guess end of september

sorry, have a lot going on, so this is a weekends-and-evenings project