Except these aren't pages. They're slides in a carousel. There's no data to load. The markup isn't substantively changing. But instead of just translating an element, if a user clicks on the next button, we make an http request to a server, wait for the server to receive it, wait for it to generate a snippet of html, wait to get it back, and then drop it in. That's a pretty laggy UI. And as a result of that replacement, you lose the focused element and any possibility for animation.
What happens when you click quickly? Does the UI just freeze until it eventually loads... some slide? What if you want a touch carousel using scroll-snap? How do you destroy and replace the entire section without interrupting the user?
If you want to have a purely client-side carousel then this is outside the domain of htmx :shrug: You implement the carousel on the client-side. Use whatever library you like. Personally I think web components are a great complementary fit with htmx. But here you've just moved the goalpost. What you said earlier:
> No more state!...Just use htmx, everything becomes so simple!...None of that goes away, of course, it just moves to a different repo.
With a purely client-side component, the state is managed purely on the client side, and the server would not touch it anyway. So it didn't have duplication of state to begin with, and htmx is solving (among other things) the duplication of state problem. So again–this example is not relevant to htmx.
What happens when you click quickly? Does the UI just freeze until it eventually loads... some slide? What if you want a touch carousel using scroll-snap? How do you destroy and replace the entire section without interrupting the user?