У меня вопрос по поводу прокрутки: на Android есть такая вещь, как RecyclerView Создание динамических списков с помощью RecyclerView | Android Developers. Она переиспользует компоненты, вместо того чтобы добавлять всё новые и новые элементы во время прокрутки. Кажется, что Discourse так не делает? Почему? Используется ли какая-то другая стратегия? У меня сложилось смутное впечатление, что система пользовательских виджетов vdom была создана именно для решения этой проблемы (бесконечного роста списка элементов DOM), но, честно говоря, я всё ещё не понимаю, как это решает проблему. 
Может, кто-нибудь сможет пролить свет на этот вопрос? 
Мы загружаем по 20 постов за раз, используя то, что называется «виртуальной прокруткой».
Что происходит со старыми элементами DOM? Если я продолжаю прокрутку, я представляю, что в дерево DOM добавляется всё больше и больше элементов. Удаляются ли они когда-нибудь?
Нет, мы оставляем их на месте. У нас есть логика «маскировки», которая заменяет элементы на плейсхолдер, когда вы находитесь очень далеко от области просмотра, а когда вы приближаетесь к элементу, мы «раскрываем» его, перерисовывая. Порог для этой магии довольно высок.
@sam Можете ли вы дать ссылку на статью, в которой сравнивается этот метод с повторным использованием компонентов? Мне было бы интересно прочитать об этом подробнее. Как вы пришли к этому решению? Думаю, что A tour of how the Widget (Virtual DOM) code in Discourse works также связана с этим.
Я не думаю, что у нас есть такая статья, но могу ошибаться. Возможно, @eviltrout помнит, документировали ли мы некоторые из наших решений, касающихся скрытия постов. Не уверен.
Увы, прошло так много времени, что я не помню.
Кажется, мы так и не провели полный анализ компонентов переработки. Маскировка стала большим успехом и решила наши проблемы того времени.
@eviltrout Я видел этот пост: We finally did something about Android Performance | Evil Trout Inc.
После многих лет ожидания прорыва в производительности Android или Ember мы решили, что пришло время применить ядерный вариант: мы заменили движок рендеринга Ember для нашего самого распространённого представления на кастомный рендерер на основе виртуального DOM.
Получается, что система vdom/widget в Discourse была создана как ответ на проблемы с производительностью в Android.
Этот коммит, вносящий функцию cloaking, кажется, появился после внедрения системы vdom/widget:
Связаны ли cloaking и система vdom/widget каким-то образом? Кажется, что обе они направлены на решение проблем с производительностью. Повторное использование компонентов значительно сократило бы количество элементов DOM, поэтому, вероятно, система вроде vdom/widget была бы не нужна, верно?
До vdom у нас уже было скрытие, но мы переписали его заново, когда обнаружили, что оно нужно и там.
Переработка компонентов должна снизить потребление памяти и улучшить производительность на больших темах, но это не ускорит время рендеринга, которое виджеты значительно увеличивают.
Нельзя недооценивать тот факт, что все проблемы производительности связаны с компромиссами. Я считаю, что Ember поступает правильно, фокусируясь на приложениях, которые хорошо организованы и масштабируются по мере добавления новых функций. Для подавляющего большинства представлений в вашем приложении накладные расходы фреймворка вас не беспокоят. Однако, если вы рендерите множество вложенных компонентов с большим количеством привязок, ситуация может стать патологической.
Хотя Discourse может выглядеть простым на первый взгляд, каждый пост рендерится с использованием довольно большого количества компонентов. У нас много динамических кнопок, ссылок и эффектов, применяемых при каждом рендеринге поста, при этом задействовано более 150 атрибутов.
Я видел это в блоге @eviltrout. Похоже, что в целом производительность Ember не является проблемой, но только в конкретном случае тем Discourse, верно? Темы Discourse представляют собой очень длинный список компонентов (постов), внутри которых находится множество других компонентов (кнопка ответа, кнопка лайка и т. д.). Именно это приводит к снижению производительности рендеринга.
vdom/widgets немного смягчают эту проблему, делая процесс рендеринга менее затратным. Но в какой-то момент количество элементов DOM становится настолько большим, что их необходимо уменьшать, скрывая их (cloaking).
Переиспользование компонентов позволяет избежать этой проблемы полностью, оставляя на экране фиксированное количество элементов DOM, которые переиспользуются по мере прокрутки пользователем контента.
Поправьте меня, если я что-то неправильно охарактеризовал.
Спасибо,
Spirobel 