Собеседовался я как-то в эту компанию на должность senior frontend developer. Предложили оффер ниже рыночной + только 1/5 от общей суммы окладная часть. + HR через "слово" занималась обесцениванием опыта кандидата. Не верю я, что с такими подходами, данная компания может развивать настоящий IT. Видимо студенты на ваши хакатоны только ходят.
Чего уж там говорить, по себе знаю, как в 2025 найти (не найти) работу senior frontend developer'ом. Более 300 откликов Карл, 5-6 собесов, причем мне на одном из них HR заявила открыто, что компании сейчас пытаются просто остаться "на плаву". Я спросил, используют ли они AI для найма, было сказано, что да, но пока не в полной мере. Что ж будет, когда полностью переведут процесс на AI... Но и фактор экономический естественно сильно влияет. Был оффер в ВТБ (странные ребята, высокие ожидания, странный процесс найма, HR каждым словом пытается обесценить твой опыт и ЗП ниже рыночной предлагает, да ещё и 1/5 только официальная окладная часть, остальное премии видимо...). Мрак одним словом.
AI это хороший помощник, но с плохо обученными моделями и процессами может выдавать обратный эффект, собственно так же как и человек.
На оптимизацию заведена задача https://github.com/djonnyx/ng-virtual-list/issues/362 по реализации многопоточного режима. После реализации будет понятно, на сколько это поможет в данной ситуации. Дело в том, что это общая "проблема" виртуализированных списков, на небольших объемах элементов решается увеличением буффера. В данном примере хотел продемонстрировать с каким ресурсопотреблением будет визуализироваться большой объем подгруженных сообщений. В реальности как вы правильно подметили должна быть реализована lazy подгрузка чанков сообщений.
С включенным appendOnly, присутствует возможность создавать группы со sticky лэйаутом. При последующих скроллах, элементы остаются в списке визуализации даже если они выходят за рамки видимой и буферной области, что значительно увеличивает потребление ресурсов "железа". При скролле с помощью передвижения "ползунка", наблюдаются лаги и проседание производительности.
С выключенным appendOnly, не присутствует возможность создавать группы со sticky лэйаутом. При последующих скроллах, элементы удаляются из списка визуализации, что ни как не влияет на излишнее потребление ресурсов "железа", как в предыдущем примере. При скролле наблюдаются дёрганияб флики и не корректные репозиции при адаптивных по высоте элементах.
ng-virtual-list
ng-virtual-list удовлетворяет прохождению всех условий тестирования.
cdk-virtual-scroll-viewport (*ngVirtualFor) не подходит для решения задач, когда необходимы динамические по высоте элементы и требуется отрендерить очень большие списки, да так чтобы всё отрабатывало плавно и без проседания производительности в виде лагов.
У ng-virtual-list стабильность работы и производительность выше чем у cdk-virtual-scroll-viewport
P.S. Честно не проверял, работает ли scrollToIndex корректно при адаптивных по высоте контента элементах у cdk-virtual-scroll-viewport. Но могу утверждать про ng-virtual-list, что scrollToItem работает должным образом!
Видимо @aw350me имел ввиду, что каждый обработчик кнопки (trigger) регистрируется в массиве "слушателей", тем самым давая нагрузку на общую производительность списков. Про картинки наверное подобная история, только дающая дополнительную нагрузку на RAM и CPU. В случае с виртуализированными списками, триггеры и обработчики изображений лимитируется и не требуют вертикального масштабирования за счёт ресурсов "железа".
Сделал небольшой бенчмарк для сравнения. Выборка 100 000 элементов.
К каждому из решений приведены ссылки на демо. Можете убедиться сами в колоссальном различии потребления ресурсов!
Результат:
Инициализация ng-virtual-list списка (на моей машине) заняла ~3 секунды.
Инициализация обычного HTML списка (на моей машине) заняла ~20 секунд.
Нагрузка на CPU у ng-virtual-list меньше в ~10 в раз по сравнению со стандартными HTML списками.
Нагрузка на RAM у ng-virtual-list меньше ~10 в раз по сравнению со стандартными HTML списками.
Под инициализацией списка подразумевается общее время до отображения списка. Оно складывается из генерации коллекции случайными данными и построениями объектов экранной области.
Если себе и своему опыту цену не знать, то идите за копейки работать.
Собеседовался я как-то в эту компанию на должность senior frontend developer. Предложили оффер ниже рыночной + только 1/5 от общей суммы окладная часть. + HR через "слово" занималась обесцениванием опыта кандидата. Не верю я, что с такими подходами, данная компания может развивать настоящий IT. Видимо студенты на ваши хакатоны только ходят.
Чего уж там говорить, по себе знаю, как в 2025
найти(не найти) работу senior frontend developer'ом. Более 300 откликов Карл, 5-6 собесов, причем мне на одном из них HR заявила открыто, что компании сейчас пытаются просто остаться "на плаву". Я спросил, используют ли они AI для найма, было сказано, что да, но пока не в полной мере. Что ж будет, когда полностью переведут процесс на AI... Но и фактор экономический естественно сильно влияет. Был оффер в ВТБ (странные ребята, высокие ожидания, странный процесс найма, HR каждым словом пытается обесценить твой опыт и ЗП ниже рыночной предлагает, да ещё и 1/5 только официальная окладная часть, остальное премии видимо...). Мрак одним словом.AI это хороший помощник, но с плохо обученными моделями и процессами может выдавать обратный эффект, собственно так же как и человек.
Изучил момент с критическим падением FPS. Можно ознакомиться настройки буфера для высокого FPS.
В демо поменял настройки буфера на оптимальные. Теперь не должно быть критического падения FPS
Реализовал API для работы с lazy подгрузкой элементов списка.
Переработал демо, в котором так же реализован флоу lazy подгрузки элементов.
На оптимизацию заведена задача https://github.com/djonnyx/ng-virtual-list/issues/362 по реализации многопоточного режима. После реализации будет понятно, на сколько это поможет в данной ситуации. Дело в том, что это общая "проблема" виртуализированных списков, на небольших объемах элементов решается увеличением буффера. В данном примере хотел продемонстрировать с каким ресурсопотреблением будет визуализироваться большой объем подгруженных сообщений. В реальности как вы правильно подметили должна быть реализована lazy подгрузка чанков сообщений.
@domix32 спасибо за замечание!
Завел дефекты касающиеся работы в FF https://github.com/djonnyx/ng-virtual-list/issues/476 и https://github.com/djonnyx/ng-virtual-list/issues/475
Постараюсь в кратчайшие сроки изучить возможные решения проблем.
Если нашли дефект или уязвимость, можете завести bug issue https://github.com/djonnyx/ng-virtual-list/issues
Погнали,
Условия тестирования:
cdk-virtual-scroll-viewport (*ngVirtualFor)
При одном варианте использовался appendOnly, в другом без него. Оба варианта не удовлетворяют прохождение условий.
appendOnly="true"https://benchmark-cdk-virtual-scroll-viewport-appendonly.eugene-grebennikov.pro/
С включенным appendOnly, присутствует возможность создавать группы со sticky лэйаутом. При последующих скроллах, элементы остаются в списке визуализации даже если они выходят за рамки видимой и буферной области, что значительно увеличивает потребление ресурсов "железа". При скролле с помощью передвижения "ползунка", наблюдаются лаги и проседание производительности.
appendOnly="false"https://benchmark-cdk-virtual-scroll-viewport.eugene-grebennikov.pro/
С выключенным appendOnly, не присутствует возможность создавать группы со sticky лэйаутом. При последующих скроллах, элементы удаляются из списка визуализации, что ни как не влияет на излишнее потребление ресурсов "железа", как в предыдущем примере. При скролле наблюдаются дёрганияб флики и не корректные репозиции при адаптивных по высоте элементах.
ng-virtual-list
ng-virtual-list удовлетворяет прохождению всех условий тестирования.
https://benchmark-ng-virtual-list.eugene-grebennikov.pro/
P.S. Честно не проверял, работает ли scrollToIndex корректно при адаптивных по высоте контента элементах у cdk-virtual-scroll-viewport. Но могу утверждать про ng-virtual-list, что scrollToItem работает должным образом!
Видимо @aw350me имел ввиду, что каждый обработчик кнопки (trigger) регистрируется в массиве "слушателей", тем самым давая нагрузку на общую производительность списков. Про картинки наверное подобная история, только дающая дополнительную нагрузку на RAM и CPU. В случае с виртуализированными списками, триггеры и обработчики изображений лимитируется и не требуют вертикального масштабирования за счёт ресурсов "железа".
Поправка: выборка в тестах составила 200 000 элементов, а не 100 000 как написано в комментарии выше.
Сделал небольшой бенчмарк для сравнения. Выборка 100 000 элементов.
К каждому из решений приведены ссылки на демо. Можете убедиться сами в колоссальном различии потребления ресурсов!
Результат:
Инициализация ng-virtual-list списка (на моей машине) заняла ~3 секунды.
Инициализация обычного HTML списка (на моей машине) заняла ~20 секунд.
Нагрузка на CPU у ng-virtual-list меньше в ~10 в раз по сравнению со стандартными HTML списками.
Нагрузка на RAM у ng-virtual-list меньше ~10 в раз по сравнению со стандартными HTML списками.
Virtual list (ng-virtual-list):
https://benchmark-virtual-list.eugene-grebennikov.pro/
Simple HTML list:
https://benchmark-simple-list.eugene-grebennikov.pro/
Итог:
Решайте сами для кого и в каких случаях данная технология интересна или не интересна. Тесты и цифры говорят сами за себя.
P.S.: Тест не является чистым. Т.к. в примере со стандартным HTML списком не использовал sticky layout для групп (решил не добивать окончательно).