The gist of what I was saying was that once I had a more complicated experience, the benefits of just fetching a fresh partial each time started to dwindle. The HTML response grew, I needed a bunch of inline handlers to patch over some state issues, as well as the complexity of the template, just started to be too much. Really it was the Alpine part that I was missing. Simple class toggles, easy way to toggle aria attributes, show/hide for elements, and reactive/computed values, were the things I needed to get the results the client wanted.

If I was building a simple search input + results, I would use HTMX all day. These forum people make it work and that seems like a great use case. But it just didn’t fit with a more sophisticated form that had dynamic options plus a large results display and the burden of a slower query to just get the data.

I think dynamically fetching results (ala infinite scroll) would have been more complicated to build. I would have had to add an intersection detection (HTMX 4 has that) to trigger the form/request again, but with an ever increasing chunk offset slice. I also need a way to track that state as well. Considering I had one big HTML response, I don’t think I could have done that efficiently without splitting it anyway. Even if I could "pluck" the results I needed from the HTML response, the penalty of waiting for the response was the factor.

If you have any links to some demos where there is something like that, I would appreciate it.

All that being said, the count of items actually isn't the most relevant part. The most relevant part is the amount of HTML per single result. If you have a sophisticated card component (a title, a description, images, a table of information inside of it or complicated layout) just loading six cards could end up being hundreds of HTML elements.

So even if you lazy loaded elements in chunks, those chunks are still gonna take a while to fetch given the size of the HTML. You also break CTRL-F-ing since those results don’t exist in the DOM until you trigger their fetching code. Same problem as classic pagination.

I would have to completely refactor my entire experience regardless because if I want to lazily load the cards/results gradually, I would have to split up the layout to make it more efficient.

So my approach to shrink the HTML response was to break it up the "live" section to just the right half.