Для этой ситуации можно держать только TextNode на нужных позициях в DOM. Думаю не должно тормозить даже для десятков мегабайт текста (но это не точно). Один мегабайт точно не тормозит.
Да, можно попытаться выкрутиться таким компромиссом.
а не решают проблему на корню.
Ну прямо на корню это в обозревателях должны решать — они сами должны выкидывать невидимое и отбрасывать все неиспользуемые стили при первой загрузке, оптимизируя их так чтобы не вычислять сложные правила каждый раз при перерисовке. В свежей лисе похоже так и работает (либо просто очень быстро работает), а вот в хроме нет.
Ещё минус динамической области видимости в невозможности пользователю сохранить страницу целиком. Нужно костылять спец. кнопку по которой всё дерево сгенерируется для удобства сохранения (кто об этом позаботится? только энтузиасты).
В движке в том числе. В хороших движках многие подсистемы выносятся в отдельные потоки, и игровую логику при желании можно раскинуть по ядрам (ясное дело что не всё параллелится, но хватает задач где можно раскидать нагрузку).
Они наверное в лисе сидят (в ней не тормозит ни прокрутка ни поле ввода) и посмотреть в хроме (подвержены все на blink) им судя по всему лень (не в их компетенции).
Да стандартная ситуация когда некомпетентные люди отфутболивают.
P.S. Вы так или иначе придёте к удалению лишнего из DOM, поэтому мне непонятно ваше категорическое «Нет», с отмеркой сколько нужно вешать в граммах.
И сколько предлагаете держать в «буфере» комментариев? всего сотню? (на сотне наверное не тормозит?) А знаете что при динамической видимой области перестаёт полноценно работать поиск по CTRL+F? То есть тут уже встают две задачи сделать динамическую область видимости (задача сама по себе не простая) и ещё эмуляцию поиска (который будет искать и в невидимых комментариях). А технический долг в виде перегруженной каскадной таблице стилей никуда не исчезнет.
Так-то я за динамическую область видимости, но только когда в ней есть потребность.
Решение проблемы в данном случае заключается в удалении из DOM лишних комментариев, невидимых на странице
Нет, решение для поле ввода заключается в чистке неиспользуемых стилей и возможно рефакторинга переусложнённых селекторов (их хватает неоптимальных), а прокрутка и вовсе чинится так.
Динамический viewport нужен только когда у вас реально много данных на странице (начиная с десятка тысяч, или даже больше), а тут на момент написания этого комментария всего 1369 комментариев.
Можно еще при прокрутке всей странице задавать mouse-events:none;
Да, это тоже можно, но в данном случае не обязательно, достаточно обойтись стилями выше и тормоза при прокрутке сразу уходят.
А вот тормоза с полем ввода без рефакторинга не избежать, ибо проблема даже не в количестве тормозных селекторов (а их реально много), а в самом по себе огромном количестве селекторов (даже те селекторы которые не используются на странице всё равно добавляют тормозов).
Кстати я отписал таки в тп хабра, цитирую ответ: «Вы можете привести пример ресурса на котором статьи с 1300 комментариев загружаются на ваш компьютер без задержек?»
Я конечно могу быть не прав, извините, но меня чуть не вывернуло от такого ответа от тп именно хабра.
Почему комментарии так безбожно тормозят? Неужели отрендерить 1000 комментов это такая сложная задача? Почему когда я их прокручиваю (хром, винда), оно тормозит так будто биткоины майнит и почему когда я прокручиваю огромный RFC всё летает?
Я ответил тут почему.
Вкратце: на хабре очень много не оптимальных стилей.
Хотите секрет? Это всё CSS (СТИЛИ) виноваты. Грохните их dr.habracdn.net/habrcom/styles/1537449801/main.bundle.css и всё станет в сто раз шустрее. Можно через F12 во вкладке Source открыть и потереть содержимое этого файла или перейти через Elements на него в стилях элемента какого-нибудь.
Это не новая проблема. Частенько всякие там кривые нормализаторы (сброс стилей) сильно так тормозов добавляют (но в данном случае проблема глубже). Уже не в первый раз вижу такое на сайтах.
Для статистики:
Ай, поторопился, в статье это уже указано.
Если так дальше пойдёт в нём может появиться потребность.
Я для себя тоже решил что GraphQL что-то не то и решил пока своё простое query-api сделать.
Ну прямо на корню это в обозревателях должны решать — они сами должны выкидывать невидимое и отбрасывать все неиспользуемые стили при первой загрузке, оптимизируя их так чтобы не вычислять сложные правила каждый раз при перерисовке. В свежей лисе похоже так и работает (либо просто очень быстро работает), а вот в хроме нет.
Ещё минус динамической области видимости в невозможности пользователю сохранить страницу целиком. Нужно костылять спец. кнопку по которой всё дерево сгенерируется для удобства сохранения (кто об этом позаботится? только энтузиасты).
Да стандартная ситуация когда некомпетентные люди отфутболивают.
Так-то я за динамическую область видимости, но только когда в ней есть потребность.
Динамический viewport нужен только когда у вас реально много данных на странице (начиная с десятка тысяч, или даже больше), а тут на момент написания этого комментария всего 1369 комментариев.
А вот тормоза с полем ввода без рефакторинга не избежать, ибо проблема даже не в количестве тормозных селекторов (а их реально много), а в самом по себе огромном количестве селекторов (даже те селекторы которые не используются на странице всё равно добавляют тормозов).
«Круто», что тут ещё сказать.
deniskin, это норм?
По большей части чтобы устранить тормоза прокрутки наберите в консоле (через F12):
C полем ввода сложнее, я пока не понял какие стили гробят.
Вкратце: на хабре очень много не оптимальных стилей.
Это не новая проблема. Частенько всякие там кривые нормализаторы (сброс стилей) сильно так тормозов добавляют (но в данном случае проблема глубже). Уже не в первый раз вижу такое на сайтах.