3 ms·

> 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

> 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?

TacoSteemers 5y ago
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.
- rmbyrro 5y ago
  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.
  - TacoSteemers 5y ago
    > 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.
rswail 5y ago
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.
- jiggawatts 5y ago
  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.

TacoSteemers 5y ago

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.

rmbyrro 5y ago
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.
- TacoSteemers 5y ago
  > 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.

rswail 5y ago

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.

jiggawatts 5y ago
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.