[cpill]

try passing state around the component hierarchy and see how simple it is. HTMX makes it easy but centralising the state in one place ie the server. try coming back to your code base in a year or two and see how simple it seems then :D

[robertoandred]

Except when your state appears in many parts of the page, HTMX makes it hard to keep everything updated.

[xvinci]

Fully ack. But this can actually be turned into something good imho: I try to challenge all layers (Analysis, UI / UX design) on simplicity: "Do we really need X parts of the page all be affected / updated by something? How could we design it differently with locality in mind? Can we simplify the state somehow?" -> I think that the resulting solutions are often simpler, cheaper, and work just as well.

[sethammons]

agreed: htmx is good for "swap out this one element and its children". It is not good for "and these other related elements need to update"

[wild_egg]

> It is not good for "and these other related elements need to update"

That seems a bit backwards, no? Why can't those other elements manage their own updates? You can have the server respond with an `HX-Trigger` header to dispatch an event and any elements that care about that event can listen for it. Far simpler than trying to coordinate surgical DOM updates in a single HTTP request.

Events form the backbone of the browser environment and leaning into that model makes a lot of things much easier

[yawaramin]

To a certain extent, it works, but there's definitely a point of complexity that you can hit in the app at which it becomes painful. Those are the kinds of apps where htmx is just not a good fit.

[n144q]

Not any more complicated than passing parameters to a function.

If that is actually the case, there is an issue with your component design.

[wg0]

You pull the state up. Props down.