For large organisations the amount of entries in the dropdown is probably very large. To fill the dropdown would then require significant work on the server, and to build up and show the dropdown would require significant work on the client.
Edit, of course a proper solution would be well-thought out and would not crash, but that solution would also not be using a single dropdown to show all possible values because that is not usable when it is more than 20 entries.
Modern backends and frontends can surely handle way more than 20 entries in a dropdown without sweating.
But in case you do have a LOT of entries that modern hardware cannot handle efficiently, just switch to a selector based on a search box (perhaps with autocomplete), instead of a dropdown.
Since it's an easy modification in the UI, perhaps these startups used a dropdown for simplicity, knowing they can change to a selector search box quickly, if it becomes an issue.
> Modern backends and frontends can surely handle way more than 20 entries in a dropdown without sweating.
I agree. I meant that I as a user will not find it usable enough if I often have to search the correct value in lists of 20 or more.
The discussion of the load on the frontend and backend was about amounts large enough to create problems if the developer wrote naive code, but we did not get in to a specific amount.
because toy apps that use dropdowns like the OP mentioned will do a "SELECT * FROM security_groups" at the backend (requiring RAM for the whole thing to format the response) and then send it down to the frontend which will then spend eternities formatting the list in the DOM as a complete UL/LI of objects that will blow up the front end.
Drop-downs for unconstrained lists are just flat wrong, they become unusable at a mere few hundred entries. Even with just a few thousand, you'll see only a tiny subset of accounts/groups/objects and it'll look like this:
AADEN
AADIT
AADVIK
AAIDEN
AARAV
AARIZ
AARON
AARUSH
AARYAN
AAYAN
AAYDEN
ABDEL
ABDIEL
ABDUL
ABDULLAH
...
The rest of the list will be cut off past the bottom of the screen, or have a tiny down-arrow that will scroll down... one... item... at... a... time.
I would do the "look at the server RAM disappear like a magic trick! ...and now the whole server is gone!" demo to really drive the point home, but that happens around the 200K-1M object level (depending on the software).
About 50% of the time there would be a senior developer there who would just slowly blink at me and suggest the "solution" of cutting down the directory to a more manageable size, like 50 users.
Like... yeah buddy. We'll just delete 99.975% of the user accounts in the directory system because you learned programming from a "4 Dummies" book.
Curious as to how clicking on an UI object would consume gigabytes of memory, both in frontend and backend?