Меня, бывает, спрашивают о том, как что-то реализовать, когда элементов очень много.

Например:

На странице отображены 100 000 товаров и у каждого есть кнопки действий. Как указать обработчик событий для этих кнопок так, чтобы не множить функции? Постраничного листания нет, подгрузки при прокрутке тоже.

или

На странице отображаются 5 000 товаров с партиями, остатками, необходимо изменять эти данные. Что бы вы стали делать, если бы страница стала тормозить? Как бы вы искали источник проблемы?

Да никак бы я не искал источник проблемы. Потому, что источник уже найден — это вывод на экран тысяч экземпляров данных.

В этом нет никакой необходимости. Никакой человек не может управлять данными, когда их тысячи. Нашему мозгу уже и 30 штук — довольно много. Правильное решение: сделать так, чтобы на фронтенде не отображались, не хранились, и не обрабатывались тысячи элементов. Тогда и не нужно будет решать эти надуманные задачи.

Простой ответ: чем меньше, тем лучше.

Есть давнее противостояние между Виндоус и МакОС. В Виндоус настроек больше и часто это считается свободой, а в МакОС — меньше, зато там дизайн лучше. То же самое с Андроидом и АйОС. И это неспроста.

Дизайн лучше не когда он красивее, а когда лучше решает задачу. А это значит что дизайнер в эту задачу вникает вместо пользователя и с учётом своих знаний о проектировании, удобстве, распространённых ошибках, придумывает лучший способ решения и проверяет, вправду ли он хорош. Когда дизайнер работать не хочет, не хочет вникать в задачу, он придумывает настройки, чтобы эту задачу решил за него пользователь, и подаёт это под соусом «настраиваемого интерфейса».

Когда времени на решение задачи мало, мало опыта или тяжело узнать, как на самом деле будет использоваться интерфейс, можно оставить какие-то настройки, но долг останется. А значит, нужно будет проследить за пользователем, узнать как он пользуется программой и оставить такой вариант, который пользователь выбирает, проанализировав, почему он так делает.

Например, в системах управления данными всегда есть таблицы: список клиентов, документов, отчётов, счетов. В этих сущностях всегда много полей, десятки и сотни. Часто заказчик прямо требует возможности фильтровать по каждому из полей, и возможности выбирать, какие столбцы будут отображены вручную. Подобное решение понятно заказчику, потому, что контроль переходит к нему, но ужасно для неопытных пользователей (попробуй настрой, как тебе нужно, и пойми, как тебе нужно), трудоёмко (очень трудоёмко!) со стороны реализации, и является решением в общем виде, поэтому мало отличается от предоставления доступа к БД напрямую.