> merely clicking something like that will make both the server and client use gigabytes of memory until either one or both crash

Curious as to how clicking on an UI object would consume gigabytes of memory, both in frontend and backend?

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.

Sure, you can roll the dice on a handful of big organisational buyers, and you may find that good engineering is what they're after. But there's a whole lot of politics (organisational and other), relationships, and other stuff in play; having a heavily engineered product is not remotely a guarantee of winning that kind of contract.

These 9 bullet points are far from "not difficult to implement" though.

Well, 2 of them are hard, the others are the kind of thing you get if you let a developer take a week or two to solve them at the beginning, but almost impossible to create after the system is built.

So, 3 months of up-front work. It very likely won't break any project/company, but it's enough of a drag that most people will say "fuck it" and not target large enterprises. And, well, there are plenty of other reasons not to target enterprises that the GP isn't talking about, so it may be a good choice.

Having worked at a large enterprise I agree that there are many good reasons not to target 'us'. However far too many companies are rocking up to sales meetings with large enterprises and have no idea about their actual needs and the scale and problems of selling to large enterprises.

Having also sold to large enterprises, you have to be willing to sometimes spend 3-6 month developing a really obscure feature that will only be used by that one customer to get the sale.

Well, you ain't getting that 7+ figure contract for just building easy stuff either.