[oellegaard]

We recently moved an old page from plain html and everything generates by the backend to react and we had a drop down take several seconds to open with a thousand or so items in it. Was like 100ms to open the entire page before.

It was suggested to only display the first 100 items and let the user type in 3 characters until it started rendering.

Unfortunately this is the reality for many these days.

Of course instead we just fixed the shitty react code and it rendered instantly.

[compacct27]

Yup. Common. With all the performance blogs focused on time to first paint and the like, React introduced a whole new category that looks a lot like this

[werdnapk]

So use a server side rending framework such as Turbo. I've tried so many client side frameworks (what the kids tend to demand these days) and they're all slow with lots of data... except for Turbo.

[drewcoo]

A select with thousands of options sounds like terrible UX.

If the new frameworks make the problem blindingly obvious so that someone can actually justify fixing it, all the more reason to use those frameworks.

[Klonoar]

I can’t believe I’m arguing this, but: it actually might be fine UX?

As long as they’re sorted and I can jump with the keyboard, that bare-ass drop-down is probably going to “just work” with default behavior. Anything further and we don’t know the intended use case for the element itself, but on the surface… it could be fine.

[YurgenJurgensen]

There's another condition for that: That you can predict the first few characters of what you want to select. This is rarely true of thousand-item dropdowns; you generally find yourself having to iterate through a bunch of hypothetical naming schemes. Sure, this could be averted with rigorous enforcement of some naming convention, but if you have the discipline to do that, you're probably not making thousand-item dropdowns.