Comments 170
Вот что такое реактивный подход в однопоточном js программировании?
И на мой взгляд если действительно понимать о чем идет речь, то за подобный объем можно четыре раза рассказать ИСЧЕРПЫВАЮЩЕ что это такое.
Что-то http://toys.hyoo.ru/
безбожно тормозит при скролинге. Какая-то анти-реклама $mol
А вы не за скроллбар дёргайте.
А зачем тогда он нужен-то?
А тут он и не нужен, собственно. На мобилках он и не показывается.
Надо тогда и на десктопе тоже его не показывать.
Лучше объясните, что там вообще такого накручено, что дерганье за скролбар приводит к зависанию сайта. И зачем.
Если б ещё был безкостыльный способ его скрыть.
Там просто более 9000 товаров. Если вы захотели странного и умотали в самый конец списка, то получаете рендеринг всех товаров.
Нет, у меня повисла вкладка при попытке сдвинуть ползунок скролбара.
А думаете ему будет удобнее 50 раз кликнуть на "следующую страницу"?
Очевидно, пользователь сперва применит какие-то фильтры, а потом, когда товаров останется ~несколько сотен, уже и будет просматривать.
Выходит, что:
1. в том случае, когда у вас 9к товаров, виртуальный скролл не нужен, потому что пользователь все равно не будет скроллить
2. а когда товаров несколько сотен — виртуальный скролл не нужен, потому что их можно подгрузить целиком
В итоге получается что какая-то ненужная (в данном конкретном случае, я не говорю, что виртуальный скролл вообще никогда не нужен) фича.
Ну и еще на десктопах меня лично виртуальный скролл всегда бесит — с ним, по очевидным причинам, не работает поиск
Эта фича позволяет быстро показать страницу, не парясь по поводу количества найденных фильтром товаров.
А браузерный поиск не нужен, если есть соответствующий фильтр по тексту.
То есть вы сперва выдумали проблему (зачем-то решили показывать пользователю 9к товаров), а потом ее героически преодолели, не показывая их сразу, а показывая по-немногу.
> А браузерный поиск не нужен, если есть соответствующий фильтр по тексту.
Я когда захочу что-то найти на странице, то точно не стану искать какой-то там фильтр по тексту, а нажму ctrl+f. И когда поиск ничего не найдет — то в первую очередь подумаю, что на странице просто и нет соответствующих данных, а не то, что они не подгружены из-за виртуального скролла.
то в первую очередь подумаю, что на странице просто и нет соответствующих данных
Вот-вот. С точки зрения обычного пользователя все товары на странице есть, вот же они, можно пальцем в экран ткнуть и показать. Откуда пользователю знать что тут какая-то тормо-магия применена :)
Пользователь не слепой, чтобы не увидеть огромное поле поиска. Мало кто знает про комбинацию ctrl+f, а на мобилке нативный поиск ещё сложнее отыскать.
Пользователь плевать хотел на ваше огромное поле поиска. Пользователь привык что такие поля работают из рук вон плохо и вообще меняют выборку (чего пользователь хочет не всегда). А ещё пользователь привык к нативному поиску. И да, на мобильных девайсах пользователи тоже пользуются встроенным поиском.
Видимо у нас с вами разные пользователи. Наши пользователи знать не знают про браузерный поиск по странице. Даже я, программист, предпочитаю поиск от разработчиков приложения, а не браузера, так как он работает куда более адекватно. Разработчики приложения куда лучше знают по каким полям (не обязательно видимым) нужно искать и как это делать.
А что там до слепоты — чтобы это поле увидеть, надо еще нажать 32-пиксельную белую кнопку на белом фоне заныканную в самый угол экрана. Скажу честно — если бы я заранее не знал, что на вашей странице есть фильтры, я бы их не обнаружил.
Мой опыт подсказывает, что это весьма реальная проблема, так как разработчики обычно тестируют приложение на малом объёме данных, а в реале оказывается их куда больше и всё начинает тупить.
И как паджинация поможет вам "искать по странице нативными средствами"? Или что вы предлагаете? Рендерить все 10000 товаров пару минут, чтобы нативный поиск работал?
И как паджинация поможет вам "искать по странице нативными средствами"?
facepalm.jpg. Элементарно, Ватсон. Пользователь видя постраничную навигацию понимает в каком диапазоне будет работать нативный поиск. Он понимает, что поиск затронет только текущую страницу. И пожелай он искать среди всех страниц, как раз пойдёт искать ваше "огромное поле поиска" (по сути от безысходности). Это будет очевидный интерфейс. И тормозить он тоже не будет.
Зачастую постраничная навигация находится внизу страницы, так что ничего пользователь не видит.
Давайте все-таки сравнивать с лучшими образцами, а не с худшими?
Если важно именно показать пользователю существование других страниц кроме первой — то постраничная навигация обязательно дублируется и сверху, и снизу.
P.S.: http://toys.hyoo.ru — вывалился в ошибку сценария через минуту игры с фильтрами (браузер FireFox 53.0.3).
Текст ошибки вы, конечно, не приведёте?
Похоже, исполняемый на этой странице сценарий занят или не отвечает. Вы можете остановить его сейчас, открыть сценарий в отладчике или позволить сценарию продолжить свою работу.
Сценарий: http://toys.hyoo.ru/-/web.js:675
При нажатии на подождать, сайт все равно не отвечает, ну а при остановке, все фильтры умирают)
не парясь по поводу количества найденных фильтром товаров
Ваш пример полное тому опровержение. Даже на сильном desktop-компьютере это работает очень медленно и отъедает очень много памяти.
А браузерный поиск не нужен, если есть соответствующий фильтр по тексту.
Не забудьте об этом пользователю написать в большой красной панели, чтобы он знал, что поиск ему не нужен. Пользователь то не в курсе. Он видит большую scroll-область, скроллит и видит на экране элементы. Ему и в голову не придёт, что их нет на самом деле. В случае какой-нибудь ужасной infinitive-ленты это хотя бы очевидно, т.к. и скролл меняет своё поведение по мере загрузки, и анимации loader-ов отображаются.
Вы кейсы не перемешивайте. Память съедается лишь при дорендеривании, что лучше, чем рендерить всё сразу.
Я зашёл на страницу, зыркаю на картинки и ищу чего бы мне купить. Игрушки всякие, ищу что-то интересно. Плавно кручу колесо и получаю все вышеописанные прелести. И да, когда я искал подарок на 8 марта я именно так и делал. Какие такие кейсы я перемешиваю?
Если я зашёл на вашу страницу и не стал скроллить вниз, то либо я нашёл что искал сразу (маловероятно, но бывает), либо я вообще оказался здесь зря. Это единственные use-case-ы которые представляют для вас интерес?
Поэкспериментировав с div'ми и эффектами, можно добиться того, что UX будет примерно как при бесконечном скролле, при этом не нужно хранить в несчастном дереве весь каталог.
Скорее всего вы умотали вниз, а потом перезагрузили страницу — он рендерит до того же места. Правда смещение скролла не восстанавливается. Пока что красивого решения этой проблемы не придумали. Есть костыль с проверкой изменений в дереве, но он тормозит. Ну и есть вариант вообще отказаться от фичи с восстановлением скролла при перезагрузке.
Думаю тут вообще не надо восстанавливать позицию скролла.
В сколько страниц? Пока не отрендеришь — и не узнаешь.
Если немного разные, то можно примерно прикинуть среднее. На больших скроллах ошибка будет незаметна.
Если сильно разные, то можно делать анализ предположительно занимаемого места еще на сервере, и просто добавлять этот параметр в ответ сервера, наряду с названием, ценой и т.п. Ошибка на больших скроллах будет незаметна, а маленькие можно просто рендерить как есть.
В сафари сразу же начинает ужасно тормозить при скроле. Даже когда не в самом конце списка товаров. И нет, скроллбар я не трогаю.
Подозреваю, что это из-за отсутствия поддержки пассивных обработчиков событий, из-за чего скроллинг выполняется не в отдельном потоке. Какая у вас версия Сафари и Оси? Лучше сразу писать в задачу: https://github.com/eigenmethod/mol/issues/225
Эх, промахнулся веткой(
Тормоза в сафари, версии: MacOS Sierra 10.12.5 (16F73), Safari 10.1.1 (12603.2.4).
В issue тоже отписался.
Треугольник, кстати, не тормозит. А так вообще замечал за сафари подобные тормоза, причём хром и фф не тормозили на тех местах.
Ваша реализация вирт. скролла безумно тормозит при попытке проскроллить на величину превышающую высоту экрана. Коль скоро вы его так всюду пиарите, дык доведите до ума. Этим сейчас в дэсктопном браузере просто невозможно пользоваться. $$('[my_toys_catalog_toy_card]').length === 3793
— WTF? Это вы называете виртуальным скроллом? Да сделать нормальный виртуальный скролл для элементов произвольной высоты задача не простая, у меня недели 2 ушло (правда там задача в стократ сложнее, чем просто список), но это же не повод в продакшн выдавать вот такую дичь.
Это и не "вирт скролл". Виртскролл тут: http://mol.js.org/#demo=mol_grid_demo
Да не суть важно как вы это называете. Главное, что в таком виде, такому подходу место разве что на свалке. А вы его ещё и пиарите, эксцентричные бенчмарки рисуете, которые меряют каких-то никому не интересных попугаев, зато "из коробки". Но, дайте угадаю, это всё потому, что за вами нет гигантской корпорации вроде Google или Facebook-а :)
У каждого подхода есть преимущества и ограничения. Данный наиболее безопасный — можно рендерить любые компоненты, как угодно меняющие свои размеры, и в реалистичных пользовательских сценариях он показывает хорошую производительность. Скроллить больше, чем на высоту экрана за раз — не реалистичный сценарий.
У каждого подхода есть преимущества и ограничения
Заинтриговали. А какие?
Скроллить больше, чем на высоту экрана за раз — не реалистичный сценарий.
Я машинально это сделал только открыв страницу. Так поступают многие. Да я даже эту страницу на хабре так скроллю. Так же в 100 крат быстрее.
Возможность динамически менять размеры элементов любым способом, например.
Боюсь люди, которые приходят в интернет-магазин поскроллить страницу, а не выбрать товар — не являются его целевой аудиторией.
Что мы имеем по факту:
- на малом количестве элементов ― выигрыш по производительностью ничтожен, но при этом ещё и сломан нативный поиск по странице (что, кстати, совершенно неочевидно для пользователя)
- на большом количестве элементов ― всё тупо дико тормозит и отжирает ОЗУ
Идём дальше, наш пользователь пришёл на страницу интернет магазина и хочет что-то купить. Следуя вашей логике, он либо покупает что-то сверху, либо закрывает страницу? А если не закрывает, но ищет (и скроллит разумеется), то пусть тогда у него всё тормозит? Я вот вспоминаю, как пользуюсь интернет-магазинами, дык я зачастую нахожу что-нибудь на 5-6 странице того же алиэкспресса, яндекс-маркета и десятка других магазинов. Может полчаса уйти прежде чем найду искомое.
Но наиболее странным мне тут кажется не то, что вы произвели на свет нечто странное, а то, что вы пытаетесь своё детище защитить тем, что мол пользователи не правильные, не правильно скроллят, не правильно браузером пользуются, про целевые аудитории рассуждаете. Какой ужас. Наверное теперь всякий раз, когда я буду натыкаться на жутко-тормозящее поделие в сети, я буду вспоминать вас, и вашу риторику про целевую аудиторию, про нереалистичные сценарии и прочее. На мой взгляд эта ваша презентация это Epic Fail.
О том и речь. 5-6 страница — это обычно порядка сотни-полутора товаров (и нет, рендерится эта сотня на хилых китайских тапках далеко не мгновенно). Если пользователь ничего не нашёл, то зачастую он бросает это дело — либо уходит, либо берётся за фильтры. Именно поэтому до рендеринга овер 9000 товаров никто не доходит. А тормозит в примере магазина при огромном числе отрендеренного из-за обновления каждого товара каждую секунду, добавленного опять же для примера, ибо реально товары не так часто обновляются.
Очень жаль, что вы не слышите о чём я говорю. Вот смотрите:
toy_cards() {
return this.toys_sorted().map( toy => this.Toy_card( toy.id() ) )
}
Это — весь код рендеинга карточек. Эквивалентный код на Реакте или любом другом фреймворке будет безбожно тормозить.А ведь именно такого рода код пилится в 99% случаев, потому что "он проще" и "да у нас не будет тут много данных" и "на моём i7 всё и так быстро рендерится" и "прикручивание виртуального скролла — отдельная задача, на которую нет времени". Ленивый рендеринг позволяет работать быстро в 90% кейсов даже если данных много, а программист не запаривался над оптимизацией.
Эквивалентный код на Реакте или любом другом фреймворке будет безбожно тормозить
Вы упорно игнорируете тот факт, что никто (в здравом рассудке) не будет рендерить 9000 элементов на React-е разом. Тут либо виртуальный скроллинг задействуют (что вряд ли, т.к. тут много скользких моментов), либо какую-нибудь навигацию влепят.
Вы же зачем то заставляете свой фреймворк их рендерить. И так как нормальный виртуальный скроллинг вы не осилили, мы получили жутко тормозную вакханалию. Как яркий пример того, что нет никаких серебрянных пуль и типовых решений, которые можно тупо взять и юзать, без мозгов.
Т.е. резюмируя: ленивый рендеринг хорош тогда, когда его готовят с умом. А не это нечто.
это обычно порядка сотни-полутора товаров
Тут вам нужно пол статьи снести и большими красными буквами написать: моё решение имеет смысл если в вашем списке от 50 до 150 товаров. При больших масштабах он дико тормозит, при меньших просто не имеет смысла. Но даже при количестве 50-150 элементов вы получите неочевидный мёртвый поиск. Вива кривым ленивым решениям.
И последнее. Вы делаете очень много сильных предположений о том, как ведут себя пользователи, и как себя не ведут. И, по моему мнению, практически всегда ошибаетесь. Хотя бы потому, что пользователи очень разные. Это касается не только этого топика, а вообще мои наблюдения.
А вы упорно игнорируете тот факт, что когда разрабатывают приложения данных обычно сильно меньше. А в проде у конкретных пользователей их может оказаться внезапно много. Я эту проблему не из пальца высосал, а взял из конкретных проектов.
Ленивый рендеринг хорош, как оптимизация по умолчанию, которая в 90% случаев даёт хороший результат, не требуя дополнительных телодвижений. Если нужно оперативно работать со всеми 9000 элементами, то в этом случае нужно применять уже виртуальный скролл.
Вы придумали кривой велосипед и упорно пытаетесь всем доказать, что он не настолько кривой, не всегда кривой, иногда не кривой, и вообще если действовать строго по инструкции и жать "как надо", то даже ещё ничего. Смешно же :)
- Простое решение вашей проблемы: оставляете ленивый рендреринг, но лимитируете его неким N, за пределами которого начинается постраничная навигация. Тогда эти ваши, взятые с потолка, 90% пользователей останутся при ленивом рендеринге, а более дотошные юзера хотя бы смогут более-менее нормально пользоваться сайтом.
- Сделать что-то вроде как в VK комментарии. Когда постраничная навигация бегает сама, по мере скроллинга, заодно можно url менять. Думаю сделать это хорошо не тривиально, но и не так сложно, как сделать крутой вирт.скролл.
А так, вся эта ситуация, мне напоминает низкие дверные проёмы. В вашем случае по верхней части ещё свисает оголённый 220 вольт провод.
А вы упорно игнорируете тот факт, что когда разрабатывают приложения данных обычно сильно меньше.
Кстати говоря, за всю свою практику, ни разу не сталкивался с подобными проблемами. Надо же хоть иногда мозг включать. По умолчанию всегда есть какая-нибудь навигация. Если же её нет, то у заказчика дотошно выясняются допустимые объёмы данных. Вот ни разу не было, чтобы я постфактум что-нибудь прикручивал. Может быть проблема где-то в другом месте?
В продуктовой разработке у вас нет ТЗ, только статистика, собираемая пост-фактум. Но даже в заказной всё не так радужно с ТЗ, к сожалению.
А что для того, чтобы догадаться сделать в списке пагинацию нужно ТЗ? :)
Вы не поверите, но чтобы предположить, что в списке может быть более 50 элементов — нужно ТЗ.
Нет, хороший разработчик должен делать такой предположение для любого списка, где более двух элементов (правило "раз — два — много")
Где же паджинация в списке тегов у поста и в списке ответов на мой комментарий?
А я и не говорил, что пагинация обязательна. Я говорил, что надо рассмотреть предположение.
В данном случае, пагинация оказалась не нужна.
Вот так оно и работает — рассматривается предположение, делается вывод о ненужности, а потом опа, всё тупит, надо экстренно вкручивать пагинацию, чтобы не рендерить всё, когда пользователь зашёл за данными из топа.
Скажите, а как бы вы поступили с тэгами?
Да особо никак, а что?
"Особо никак" — это как? Вы бы стали добавлять им пагинацию, виртуализовать скролл или использовать ленивую загрузку для списка тэгов?
Я бы оставил дефолтный ленивый рендеринг, пока не потребовалось бы что-то большее.
То есть ваш фреймворк подписывается на событие скролла на абсолютно любом списке?
То есть любой сайт на $mol, где есть хоть один список, будет тормозить?
Кажется, ваш фреймворк еще хуже чем я думал до этого...
Нет, есть компонент $mol_scroll который реализует скроллящуюся область и провайдит информацию о видимой области в контекст. Все компоненты внутри могут получать эту информацию через контекст и использовать её при рендеринге.
Уже реализовано несколько раскладок:
$mol_list — для вертикальных списков
$mol_row — для горизонтальных с переносом
$mol_grid — для таблиц с фиксированной высотой строк.
$mol_float — плавающий за скроллингом блок
Также любой компонент может дать подсказку касательно своего минимального размера.
У меря на планшете скроллинг не тормозит.
А ещё предлагаю посмотреть на потребление памяти страницы у меня хром на маке показывает 430 мегабайт.
Описания и картинки не уникальные потому, что это просто наколеночный пример, а не реальный интернет магазин. И нет, описания нет смысла грузить для всех товаров сразу — пусть грузится при открытии подробностей о товаре. Причём АПИ модели при этом ни коим образом не изменится.
P.S. Про картинки, например, в магазинах одежды их по 5 в среднем.
Ага, я-то пороха не нюхал :-)
Какая разница сколько у товара картинок?
Путь к картинке лучше генерировать по шаблону из её идентификатора.
(примеры взял с реальных сайтов)
А есть ещё ситуации когда изображения отдаются с отдельного домена или сервера и тогда там ещё схему и хост приходиться добавлять к каждой картинке.
Или ваш фреймворк подходит только для специально написанного бэкенда?
Если вы выбрали бэкенд, который генерирует такие огромные имена и не позволяет настроить правило их формирования, то да, вам придётся их грузить. И нет, не нужно их грузить сразу для всех товаров — лишь по требованию.
Зачем к каждой картинке добавлять одну и ту же схему и хост? Их можно вынести в отдельную константу.
Следующая версия 16.0 уже использует его под капотом. Правда пока в режиме совместимости чтоб сильно не ломать.
Вообще-то я упоминаю fiber в главе про "треугольник серпинского на Реакте" и подчёркиваю, что это не решает проблему, а лишь размазывает её по кадрам приводя к визуальным артефактам. Можете сами попробовать открыть все реализации и подвигать мышью над кружочками. Файбер перестанет обновлять их содержимое, решив, что это "низкоприоритетное изменение", однако в зависимости от бизнес задачи низкоприоритетным может оказаться как-раз изменение размеров треугольника. Короче, fiber — адский костыль, который преподносят как манну небесную. Я пробовал реализовывать размазывание вычислений по кадрам (причём не только рендеринга, а всех вычислений), но из-за подобных визуальных артефактов отказался.
Зная как они реализованы, не представляю, как оно может у вас не проявляться.
Кому-то сейчас покажется, что я что-то цитирую… ан нет, я копирую стиль в котором написана статья
и он ни капельки не ...
раздражает.
А это не статья, а текстовая расшифровка доклада. Хотите статью про ОРП — вот же она: https://habrahabr.ru/post/317360/
Вся реализация это грустная история о том, как инженер, не дружащий с UX, запилил решение, избавляющее юзера от проблем, которые на самом деле у него никогда не существовали. А само решение это просто ад для любого юзера, вследствие чего статья кажется нулевой с точки зрения полезности (если даже не вредной для неокрепших умов новичков).
Не напомните, что там у гугла на 100 странице? То, что вам дали скроллинг на 10000 товаров вовсе не означает, что нужно мотать его до конца. Так же как наличие 100 страниц в выдаче никого не заставляет идти до последней. Если пользователь не нашёл нужного в первой сотне товаров, то скорее всего он воспользуется фильтром и будет прав. Именно этот кейс мы поощряем, показывая ему панель с возможностью конкретизировать выборку.
С такой философией тупо лимитируйте выборку. В google зайдя на 100-страницу я не столкнусь в тем, что он отожрал 1 GiB памяти и всё страшно тормозит. Скажем когда я первый раз прикручивал SphinxSearch я лимитировал результаты 100-ей элементов. Вот что угодно можно на странице жать — она не зависнет. Даже если случайно куда-нибудь не туда ткнуть. В вашем случае достаточно просто ползунок дёрнуть. И дёрнут. Это обычный паттерн поведения пользователя ― бегло осмотреть что ему предложено. Сделайте на худой конец тогда уж "overflow-y: hidden", коли уж система столь уязвима.
overflow:hidden вообще запретит прокрутку. Это не решение. Если хотите — можете лимитировать выборку любым числом. Надеюсь не надо показывать как работать с функцией slice?
overflow:hidden вообще запретит прокрутку
хоспади, приделайте свой собственный. Всяко лучше, чем сейчас ;)
Надеюсь не надо показывать как работать с функцией slice?
Дык я то умею. Мои интерфейсы не тормозят, ни у 90%, ни у 10%. И током не бьются тоже.
Боюсь свой собственный не сможет скроллироваться в отдельном треде, как нативный. Вы, как истинный профессионал, у которого ничего никогда не тормозит, наверняка это знаете и просто проверяете меня, подкидывая заведомо гиблую идею.
- Про отдельный тред вы пишете ввиду того, что заранее ожидаете таких тормозов, что это должно играть значимую роль? :)
- Прошлый раз я прицепил отдельный
<div/>
с нативным скролл-баром, отслеживая в нёмonScroll
.
Потому, что мы не знаем сколько у пользователя памяти и как далеко он хочет домотать. Ну ограничим мы каким-то числом, а пользователю надо на 1 больше. В итоге он не получит своего, хотя разница в 1 погоды не сделает.
Так он все равно не домотает, докуда хочет, зачем предоставлять возможность, которую нельзя использовать? Или вы полагаете, что кто-то правда будет 5 минут крутить?..
Вы знаете, это как на сайт повесить кнопку, при клике на которую она будет вешать вкладку. Можно, конечно. Но зачем?
А почему вы предполагаете, что он хочет пренепременно в самый конец огромного списка?
Одно дело, если бы оно работало — бог с ним, пусть, но оно ведь тормозит и виснет.
Нет, мы не предполагаем это. Мы допускаем такую возможность.
Если вы считаете, что никто не будет смотреть 100ю страницу — просто не выводите ее. Нет нужды вешать браузер ради мифической "красоты" решения.
А есть смысл пользователю что-то запрещать, если ему очень надо?
Есть смысл делать сайт, который работает.
Не стоит выдавать ограничение некоторых вымышленных сценариев за "ничего не работает". В том же ЯМаркете тоже можно накликать 100500 элементов. И что? А ничего, никто так далеко не листает.
Не получится за 1 клик никак. Как минимум — надо хватануть и игнорируя тормоза довести курсор до самого низа.
Боюсь вы, в данном случае, не репрезентативны, так как ваша цель потестить реализацию, а не найти товар.
Edit: окей, я по привычке сначала нажатым колесиком попробовал. После того, как не вышло, потянулся к ползунку.
Да уж, хабр уже не тот, автор пишет о реактивном мемойзе с возможностью прерывания, а люди обсуждают или нужно юзеру 9к записей на странице. Да, демо для десктопа не удачное, но не в этом же суть.
Но автор пытается продать нам свое решение, а не просто теорию
Автор продаёт сферический ОРП, а примеры приводит на $mol_mem, так как остальные реализации ОРП поддерживают не все из описанных возможностей ОРП. У меня была мысль сделать некоторые примеры, например, на MobX. Но от этой идеи пришлось отказаться, чтобы не объяснять синтаксис каждой библиотеки, ибо время доклада не резиновое. И так пришлось урезать темы про логику работы ОРП-алгоритмов и про неидемпотентные реактивные задачи.
Посмотрите на примеры для библиотеки react-virtualized.
Вот вам виртуальный скролл на моле: http://mol.js.org/#demo=mol_grid_demo
Я уже устал повторять, что виртуальный скролл имеет свои ограничения, что не позволяет использовать его везде. А ленивый рендеринг является не аналогом виртуального скролла, а аналогом "рендеринга вообще всего за раз".
Как можно говорить что vdom в react-е работает медленнее, чем моловское обновление DOM, если на примерах видно, что это не так?
В докладе я привожу в пример треугольник серпинского, там нет никакого ленивого рендеринга.
Я уменьшил число товаров до 1000 (вся номенклатура средненького магазина) и сделал более редкое обновление числа отзывов. Надеюсь теперь мы сможем обсудить сам доклад, а не только лишь иллюстрацию к нему слепленную за пару вечеров?
Автору спасибо за статью, невольно позавидовал вашему легкому слогу. Сейчас работаю над статьей по другой RP-библиотеке, решил добавить в нее(статью) некоторые из ваших примеров, чтобы можно было параллельно сравнить подходы… Так что, полемика будет, но чуть позже.
Появилось видео с выступления:
Ответы на вопросы с 30 минуты.
Объектное Реактивное Программирование