If I wanted to do that I would have added pagination. But that UX also sucks in a different way.

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.

Want to help rather than throw tomatoes?

Wouldn't constantly loading new items into a select form be super annoying? Can HTML even keep a select input open when new items are added?