Comments 257
И снова мол по поводу и без… Вроде хорошо начал, отличный разбор, но вот эта говнореклама раздражает.

А почему, собственно, нет? Как по-вашему иначе показывать преимущества инструмента, если не через подобные демонстрации?

Ну посмотрите его предыдущий аккаунт и (особенно) комментарии. Пиар своего продукта = хорошо, спам своего продукта (с элементами other = говно) = не хорошо.

Ну, человеку свойственно исправляться всё-таки, уже не в таких тонах говорит.
Ну а, набрасывать на другие инструменты нужно, потому что везде только хвалебные отзывы о них. React, емнип, тоже стартовал с подобных набросов на Angular

Изменяет. На форумах, возможно, отдельные фанаты всякое писали, но от самой команды React ничего такого не было

Если реклама идёт одним блоком в конце, то её можно спокойно проигнорировать. Ну и как бы если человек проделал такую работу, да ещё и выложил статью, то лично я не обижусь если он в конце добавит абзац с саморекламой.
Автор сделал крутую работу, крутой разбор. В чем проблема, что это он делал на инструменте, которые хочет попиарить?
Зачем в читалке текст поста слева? Непривычно же. Пусть бы был как в оригинале по центру, всё равно же ограничен таким же контейнером

Это буклетный дизайн. Тут 2 страницы: статья и список статей. Одна страница отображается полностью, другая — насколько влезет.

То есть тут сравнивается виртуализация рендеринга в $mol и рендер всего и вся на VueJS?
И делается вывод, что VueJS — плохо?


Вот пример из Реакта, во-первых, есть новый API Concurrent Mode с асинхронным рендерингом, а во-вторых, виртуализацию не нужно писать ручками, вот популярный npm-пакет react-virtualized (vuejs тоже имеет подобное)


Так сравните как работает виртуализация в $mol и в react-virtualized. А то получается как-то несправедливо.

вот популярный npm-пакет react-virtualized

Лучше react-window, она почти в 10 раз меньше и во столько же быстрее. Написан автором react-virtualized как переосмысление виртуализации для Реакта.


А ещё есть такая штука как uni-virtualizer от Polymer, но она пока ещё в разработке, правда.

Ну так сравните.
Автор показал как с помощью его инструмента сделать лучше.
Вы считаете что можно сделать лучше и по другому. Ок… Но автору это зачем?

Дело не в том, что можно сделать лучше по другому, дело в выводах.


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


А результат — автор делает традиционный вывод: мой колхоз — рулит, а все ваши фермеры — тупят.

Интересно, а если сделать виртуальный скролл несколько иначе — в "невидимой" части показывать комментарии единым блоком текста (без кнопок, разделения на хедер-футер и прочей html-разметки), а при попадании конкретного блока с комментариями — "форматировать" его и показывать полноценной разметкой — будет ли профит?


Из плюсов:


  • не надо делать свою систему поиска
  • более friendly для ssr (если вдруг захочется индексировать по комментариям) / no-js браузеров

Из минусов:


  • проблема большого количества dom-узлов не решается, а отодвигается
  • надо колдовать с размерами "неформатированных" блоков, чтобы они были примерно того же размера, что и форматированные, чтобы избежать скачков при промотке

Число DOM элементов уменьшится раза в 2, но скроллинг будет сильно лагать, ибо при изменении DOM будет полный пересчёт стилей и лейаута для 50К элементов.

Число DOM элементов уменьшится раза в 2

вообще, например, для одного этого комментария используется 47 тегов, против предполагаемого одного (можно даже сам комментарий не форматировать, а ведь там тоже могут быть теги).


но скроллинг будет сильно лагать, ибо при изменении DOM будет полный пересчёт стилей и лейаута для 50К элементов

хм, да, тут не поспоришь… разве что как-то зонировать элементы используя абсолютное позиционирование (но это уже кажется переусложнением)

Текст комментария — это развесистый HTML. Например, в первом вашем комментарии 13 элементов в одном только содержимом.


Это уже виртуализация и получится.)

Это уже виртуализация и получится.)
Так предложение и было — сделать виртуализацию, но по-другому.

В принципе было бы круто если бы сделали "супермобильную" без разметки :)

В виртуальном варианте PgUp/PgDown не работает почему-то, а скроллить очень медленно.

Попробуйте кликнуть куда-нибудь в скроллящейся области, тогда эти хоткеи должны начать работать.

Конечно пробовал — не работает — FF-ESR, на последнем FF заработало.

Что-то эта страница на моле активно сопротивляется прокрутке в конец… И поиск работает как-то странно, больше на фильтрацию похоже.


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


И ведь не первый раз я такое вижу, когда сайт на моле рассыпается от простейших действий...

Это потому что со временем накапливается ошибка и если глядеть на ползунок прокрутки слева он все время скачет вверх-вниз из-за накапливания и уменьшения ошибки расчета комментария.

Вообще я снимаю шляпу за рабочее решение по виртуальному скроллингу для контента произвольной высоты для веба без первоначального обсчета и рендеринга всех элементов в дом.
Но разве скролл должен так себя вести? Из-за такого скроллинга нажатия на Home/End/PgUp/PgDn каждый раз приводят к непредсказуемым эффектам… И с кэшами, и без (как автор пишет ниже).

Как минимум — вы перестанете недоумевать почему оно работает так, как работает.

Но я недоумеваю по другому поводу: какого фига оно так работает?

Так работает $mol. Если вы видите, что где-то лагает прокрутка, возможно это $mol


Это единственное, что я усвоил ото всех евангелистов $mol'а

Мы же пытаемся улучшить пользовательский опыт, а не писать код ради кода, так? А пользователя мало интересует что внутри, ему нужно что работало. А оно не работает.
Вообразим, что мы едем на авто и оно дергается. Разве нас интересуют оправдания производителя, почему оно так себя ведет? Нет. Мы хотим просто нормально ехать.

Лёш ну это понятно. Скроллы вообще очень нетривиальная тема. Вторая после layout. Особенно если нужно кастомное поведение.
И никогда ею не была. Еще со времён флеша. Бывает так, что апробированные скрипты от признанных метров в определенных ситуациях ведут себя непредсказуемо. Поэтому так много вариантов. Дмитрий предлагает свой подход. Чем больше будет замечаний тем текущий скрипт будет лучше. Иногда пишешь какому-то автору замечания, а он не реагирует. Дмитрий всегда поясняет что и как. Попробуйте написать Kelvin Luck :)))

В данный момент, Дмитрий не улучшает свой скрипт, а огрызается в комментариях.

Ну почему оно так работает как раз очевидно, ведь:
VueJS — тупит, а $mol — рулит.

Скорее всего вы забыли отключить сетевой кеш и браузеру не пришлось параллельно загружать 8 метров картинок.

Тут дело не только в объёме, но и числе изображений, и ограничении браузера на число одновременных загрузок, и латентности сервера.

У браузера есть ограничение на число коннектов к домену. HTTP/2 поддерживает мультиплексирование запросов. В рамках одного коннекта, можно запрашивать все картинки одновременно, что мы и можем наблюдать в таймлайне.

TTFB вроде не скачет, но, конечно, может. Если отдача файлов идет через nginx или другой адекватный веб-сервер, то у него нет блокировок и жестких ограничений по числу отдаваемых файлов, все ограничено возможностями железа.
У браузера есть ограничение на число коннектов к домену.

Это давно уже решено запросам на поддомены.

Это не решение, а усугубление проблемы, так как при повсеместном HTTPS имеется больший оверхед на соединение.

До HTTP/2 это вполне себе было решение на сайтах где большое количество картинок. И даже сейчас бывают применяются эту технику, т.к. задержки на HTTPS все равно в итоге меньше, чем блокирование в ожидании освобождении потока.

Зачем, если есть HTTP/2? SSL/TLS-handshake большая проблема, сейчас наоборот все пытаются через один домен обработать.
FF 77 + uBlock Origin, от нажатия на ссылку до прекращения загрузки — 14 сек. Windows 7.
Не понимаю какую проблему решает автор поста.
Вообще я телефон использую по прямому назначению — звонить с него.

На мобильном FF открывается где-то минуты 3, периодически напоминая, что сценарий не отвечает и нужно бы закрыть это всё нафиг и забыть клиентский рендеринг как страшный сон. Так же страница частями «пропадает» при прокрутке.

Если поставить галку «Версия для ПК» и убрать «m» из адресной строки — грузится за 35 секунд.
Вообще я телефон использую по прямому назначению — звонить с него.

Хм, а кто, когда и на каких основания решил что вот прямо всегда, для всех и на все времена основное назначение смартфона это с него звонить? :)

P.S. И нельзя ли подать аппеляцию с просьбой пересмотреть этот пункт? :)
Общество пользователей телефона по назначению с вашей аппеляцией не согласно.
ЗЫ. Тоже предпочитаю с телефона только звонить, а если приходиться пользоваться браузером, то пользуюсь десктопными версиями сайтов на мобиле с экраном в 3.5''. Как правило, они намного стабильнее и без наркоманских решений по интерфейсу.
Ну так «общество пользователей телефона по назначению» может телефоны использовать так как им хочется. Смартфоны то здесь причём? :)
Как это при чем? Как это при чем? Я уже несколько лет не могу найти мобилу с хоролей рамой, емкой батарейкой и размером под подстаканник в машине (4'' максимум). Это точно все заговор соцюзеров и ютубвориоров:D
А вы на нас бедных и несчастных еще и аппеляцию подаете:)
Сочувствую. Я вот тоже не могу себе подходящий фитнес-браслет найти, а жена картину в гостинную. Но причём здесь смартфоны?
Ок. Но они скажем ещё и фонарики. И если кто-то тепрь не может найто подходящий фонарик, то опять смартфоны будут виноваты?

То есть я понимаю что ваши запросы в этом плане внезапно стали нишевыми и теперь вам сложно найти решение для ваших хотелок.

Но смартфоны в этом не виноваты. Максимум в этом виноваты производители или даже государство потому что не хотят обеспечивать вот прямо всех их хотелками.
Ок. Поясню свою точку зрения с другой стороны.
В основе своей смартфон — это умный телефон, т.е. основной задачей, исходя из этимологии, является все еще звонилка. Если эта задача перестает быть основной, то это уже КПК (PDA).
Но в названии сейчас смартфон, а в реале это уже КПК с возможностью звонков. И сейчас именно умные звонилки как раз оказались нишевым продуктом. Основной рынок сейчас — это устройство для приложений и браузера, а функции звонков/смс идут уже дополнением.
В 12 году, примерно, мы шутили, что скоро будут звонить по планшетам, шутка оказалась пророческой:)
В основе своей смартфон — это умный телефон, т.е. основной задачей, исходя из этимологии, является все еще звонилка.

В том то и дело что я например с этим несогласен. Основная задача телефона это звонить. Но это не значит что основная задача смартфона это тоже звонить.

И да, на мой взгляд для кучи людей возможность именно «звонить по телефонному номеру» в общем-то является опциональной и не особо то и нужна.
Как раз именно звонить, и изначально так и было. Ориентировочно до 2007 года. С появлением ведроида и яоси, термин стало все больше и больше размываться.
Когда звонить не является основной задачей, то это уже КПК — карманный персональный компьютер. А если точнее, то коммуникатор — кпк с возможностью звонков. Те самые первые смартфоны от коммуникаторов отличались большим уклоном в сторону звонков, в то время как коммуникаторы уходили больше в сторону работы с софтом.
Потом коммуникаторы почти вымерли как класс, т.к. смартфоны распространились на их область применения.
Ныне же смартфоны опять превращаются в коммуникаторы, только этот термин помнят уже лишь динозавры. В итоге 2 разных функциональных группы смартфонов имеют одинаковое название.
Изначально много что было. Но это не значит что оно так и осталось. Вещи меняются.
Вещи меняются, названия только менять забывают. А то написано йух, а это забор.

А вот этой претензии я вообще не понимаю. Есть телефон. Есть мобильник/сотовый/мобильный телефон. Есть смартфон. Три разных названия для трёх разных вещей.

Вы упустили, что текущие смарты уже должны 4-е название иметь (или вернуться к старому кпк или коммунику). От мобильной связи там большинство пользуются только интернетом, т.е. роль телефона там уже вторична.

Не вижу почему это должно быть обязательно так. Для меня смартфон как изначально был "КПК с возможностью коммуникации" так им и остался.


То есть я в какой-то момент сменил два своих гаджета, а именно КПК и мобильник, на один единственный, а именно смартфон. Но при этом КПК я пользовался вовсю, а мобильник мне был скорее навязан окружением. И смартфон для меня в первую очередь это "апгрейд" моего КПК.

Ну та же нокиа времен симбы и прочие одноклассники ее были телефонами, до кпк на той же вин мобайл они конкретно не дотягивали возможностями, хотя разработчики софта старались (первое было у друзей, второе у меня). Первый ведрофон у меня был 1.5 или 1.6. Это все еще в первую очередь телефон был, и лишь позднее они ушли к кпк. Что было потом у меня не помню. Потом был виндофон, этот уже сильно ушел от звонилки к кпк. В связи с рипом виндофонов пришлось вернуться к ведрофонам, к тому моменту они уже окончательно превратились в кпк. А я к тому моменту на телефоне пользовался только звонилкой с смсками, чеклистом, читалкой и изредка браузером, когда нужно что-то посмотреть вот прямо сейчас (на лыжах в 2007-2009 я использовал ровно тоже самое). Все остальное у меня всегда было на компе или ноуте. Только в 19 году у меня на телефоне появились карты дубльгиса, и то только ради более-менее актуальной базы магазинов, которая бывает нужна по праздникам, когда обычно посещаемые магазины или сервисы неожиданно оказываются закрыты.
Так что для меня смартфон — это именно умный телефон. Все остальное лишь дополняет его основную функцию.
Если честно нокиевскими смартфонами я никогда не пользовался как впрочем и КПК на винмобайл. Поэтому мне сложно судить о чём вы говорите. Моим первым смартфоном был HTC(Touch если я не ошибаюсь) и он вполне себе адекватно заменял мой тогдашний КПК(уж извините, но модель не вспомню).

Да и вообще я бы скзала что в понимании большинства людей именно смартфон это что-то без кнопок для набора текста/номера и Nokia 9000 Communicator или тот же Ericsson R380 скорее всего никто смартфоном даже и не назовёт.
Моим первым смартфоном был HTC(Touch если я не ошибаюсь) и он вполне себе адекватно заменял мой тогдашний КПК(уж извините, но модель не вспомню).

Эта линейка как раз из коммуникаторов выросла. Первое в линейке было еще на винмобайл, у меня что-то из более древних HTC было.
Да и вообще я бы скзала что в понимании большинства людей именно смартфон это что-то без кнопок для набора текста/номера

За это спасибо гуглу с яблоком. Та же Nokia N95 — это полноценный смартфон с кучей софта, как и многие более ранние их модели. Ныне же — это считается звонилкой:)

Смартфон как раз был телефоном с дополнительным софтом. А КПК с возможностью мобильных коммуникаций был коммуникатором.

Если эта задача перестает быть основной, то это уже КПК (PDA).

Помнится, девайс, совмещающий функции КПК и телефона пытались обозвать "коммуникатором", но не прижилось.

Оно активно использовалось, но, видимо, кто-то решил, что айфону будет проще взорвать рынок чем айкоммуникатору и даже "айкомму"

Тогда он был еще телефоном, в первую очередь. Так что очень даже адекватное название было.

Т.е. у разрабов хабра мобильная версия тяжелее десктопной. Логика ай-ти ресурса номер один, чо :D


Могли бы просто сss десктопной версии подправить, но видимо захотели новый фреймворк вставить.

Всё жду, что в Firefox на Android вернут Stylus или хотя бы какой-то исполнитель произвольных скриптов, чтобы сидеть на настольном Хабре с телефона с мобильными стилями. Эх, не дождусь ведь!

Только недавно он оттуда пропал же, с последним обновлением, в котором произвольные расширения стало нельзя ставить.
Попробовал в Сафари, реализация на $mol отрендерилась быстрее, но прокрутка можно сказать не работала вообще, и вела себя неадекватно, прыгала, и ползунок прокрутки был не в самом начале. А реализация на VueJS наоборот — рендерилась долго, но прокрутка работала относительно плавно, рендерило походу.
Пробовал демки фреймворка смотреть, под сафари многие компоненты ведут себя не совсем корректно. Например, инпут с ± кнопками вообще не работает.
К сожалению, у меня нет макбука, чтобы это подебажить.
можно попробовать поднять виртуалку с макосью для таких тестов.

А что значит "не работает"? Кнопки не нажимаются? Или не появляются? Клавиатура не вылезает? Не меняется число?

При нажатии на поле появляется + и — с двух сторон поля. При наведении на любой знак, появляется большой коричневый квадрат вокруг, при нажатии на знак ничего не происходит.
тут
Вы просто не умеете виртуализацию готовить )
mixupload.com/styles/deep-house-2020/tracks
Крутите сколько влезет — страница не начнет тормозить, в сафари, хроме, фоксе — все норм.
И да, у меня богомерзкий jquery, ванила и серверсайд-рендеринг. Просто много дебага и скролл можно себе подчинить.

Вот это нормальное решение. Можно даже хранить по одному куску сверху и снизу в кэше. Тогда когда мы приходим к концу скролла мы отображаем из кэша а не по сети, а по сети в этот момент запрашиваем уже следущий кусок. Таким образом если пользователь скролит медленно то он вообще не увидит никаких индикаторов загрузки.

Вот это нормальное решение.

Врождённые проблемы с поиском никуда не денутся.

Вы же не загружаете весь интернет для поиска в гугле. А зачем вам грузить все тысячи комментариев для поиска по ним?

Но многие и не идут в гугл, если хотят что-то найти на странице. Если увидите или сделаете полноценную реализацию Ctrl/Cmd + F — буду благодарен. С подсветкой, с выводом количества совпадений и пр.
С подсветкой, с выводом количества совпадений и пр.

В каждом браузере страны. Только от убирания DOM нод придётся отказаться ))
Ну я не исключаю что можно сделать правильную реализацию через api сайта. Но пока не видел такого (
Реализуйте сперва дерево комментариев, потом поговорим о том кто и что не умеет.

А зачем вам дерево? Просто посчитали один раз смещение по горизонтали и всё. Дальше комментарии идут одним списком, уже тут предлагали.

1. Визуализация может быть разная, не только отступ слева.
2. Высота комментариев недетерминирована.
  1. Может быть, но всё равно в рамках dom можно попробовать обойтись списком.
  2. Это проблема только в древовидном dom. В линейном определить высоту прокрутки можно даже когда высота разная.

Я смотрю тут много теоретиков, которые знают как надо, но никогда сами руками этого не делали.

Или сделают так, что лучше бы и не делали вовсе. Но советы дают легко и непринужденно. Видимо первое что в голову придет. Поэтому я не любил олимпиады по программированию. Вроде и решил задачу, но решение далеко от канонического. На качество нужно время.


PS: К вопросу о «теоретиках» — я в своё время делал виртуализацию ленты документов (очень произвольного размера) на vanilla JS.

JustDont ну покажи решение того, что показывать не надо. Не стесняйся.

Ну а почему прыгает cкролл-бар? Без нашего ведома браузер может поменять шрифты (это не тот случай), и может подгрузить картинки.
Когда подгружаются картинки, то прыгает скролл даже в статическом html. Это не возможно полностью пофиксить. Есть ли у вас другая объективная причина почему оно прыгает?

Кроме редких частных случаев, невозможно узнать высоту контента, пока весь его не отрендеришь.

А что рендеринг асинхронный? Если я удаляю или добавляю елемент сверху для экономии ресурсов, то я заменяю его на соответсвующий margin. То же самое и снизу. Кажется не надо знать всё заранее.

Я тут подумал. Вобщем без того чтобы контролировать scroll bar самому не получится сделать красиво.


Дальше будет критика, но меня просто заинтересовала задача, так что надеюсь конструктивная.


В вашей реализации самое странное это какие-то подергивания. Т.е. я делаю скролл вниз, браузер отрисовывает его ниже и потом он прыгает вверх и сразу вниз. Т.е. вот эти прыжки туда-сюда не понятно зачем нужны. По-идее, мы меняем высоту один раз за обработчик onscroll т.е. прыжок должен быть один. Как это происходит при бесконечной прокрутке например.


Во-вторых, не реализовано запоминание размеров. Т.е. при повторном скролле всё опять дергается.


Демка ngx-virtual-scroller работает плавнее, но возможно из-за того что там распределение рандомных размеров равномерное, а на хабре подругому.


Основная проблема это то что нельзя узнать какая высота изначально. Т.е. как только мы забираем новую пачку комментариев то у нас меняется наше предсказание о том сколько места ещё надо сверху или снизу. Соответственно соотношение место вверху к месту внизу меняется. Решить это можно так: скролл бар должен быть не линейный. Сам указатель скролла мы оставляем на месте, но теперь размеры выше от него и ниже от него умножаем на соответствующий коэффициент. Его учитываем при последующей прокрутке.

  1. Да, реализация не идеальная.
  2. Размеры не запоминаются так как они могут измениться как угодно, когда за ними не следишь. И если увеличение не страшно, то уменьшение может привести к скачкам контента.
  3. В демке ngx-virtual-scroller наблюдаю постоянные скачки контента при рандомных высотах.
  4. Пока скроллбар по середине не особо важны размеры отступов сверху и снизу. Проблемы начинаются, когда скроллбар достигает края. И тут все погрешности начинают стрелять по ногам. Я выбрал вариант с постоянной корректировкой положения по чуть-чуть, чем одной на несколько страниц.
  5. Есть мысль отказаться от браузерного рендеринга и рисовать всё самому — там можно довольно точно всё контролировать. Да и работать это будет раза в 2 быстрее. Но это очень далёкая перспектива.

Размеры меняются если комментарии добавляются или редактируются?


Да уменьшение сверху это проблема. Наверное у нас нет нужного контроля за рендером чтобы обрезать сверху и при этом одновременно перейти на старое место. Т.е. чтобы не было заметно скачка. С другой стороны если просто идём сверху вниз медленно, то такого не происходит. Или я не правильно понимаю причины скачков?


Корректировки это правильно. просто надо чтобы корректировки позиции для рендера и для скроллбара не были связаны. Как я предложил выше. Что думаете?

Они по разным причинам могут меняться. Например, при догрузке шрифта.


Такого не происходит в самом начале. В середине списка скачет даже при медленной промотке. Причины мне не известны.


Скроллбар показывает позицию вьюпорта относительно контента. Они не могут быть не связаны без деградации UX.

Они по разным причинам могут меняться. Например, при догрузке шрифта.

На самом деле это не важно. всё равно для примерной оценки мы используем текущий размер. можно при каждом отображении обновлять кэш.


Скроллбар показывает позицию вьюпорта относительно контента. Они не могут быть не связаны без деградации UX.

UX уже деградирован. потому что если вы хотите перейти на позицию например 20% но не знаете какая реальная высота коментов. Даже приблизительные размеры не знаете, для тех которые пользователь уже видел.


А то что этот индикатор скачет как бешанная лошадь, вот это как по мне проблема UX. То что отображает скроллбар и так и так будет очень приблизительная оценка. Может дойдут руки и я попробую реализовать. Интересно как будет работать.

По сути проблема прыгающего скроллбара сильно преувеличена. На мобилках его вообще зачастую не видно.

ну вот и всё))) на десктопе тоже спрятать, и вообще просто сделать свой индикатор и позицию по номеру комментария определять.

Когда подгружаются картинки, то прыгает скролл даже в статическом html. Это не возможно полностью пофиксить.

Достаточно указать размеры изображения в HTML. Впрочем, Firefox с этим обещал бороться, правда результата я не заметил.
Если вы про конкретно Хабр, то перезагружать все на hsto, а уж договорится с ним и забирать оттуда размеры вполне себе возможно.

Но ведь можно сделать для комментариев 2 панели — в одной скроллится tree комментаторов, в другой их коммент

1. «Разную визуализацию» тоже ничего не мешает представлять через плоский список. Ну и YAGNI.
2. Очень даже детерминирована. Правда, комментарий сначала придётся отрендерить, чтоб таки детерминировать, но это технические тонкости.

PS: К вопросу о «теоретиках» — я в своё время делал виртуализацию ленты документов (очень произвольного размера) на vanilla JS.
JustDont а как быть если элементов 10к, а пользователь быстро листает? Все рендерить в дом для просчета размеров?
Если бы тут были серебряные пули — их бы уже давно все фигачили на сайтики. Увы, их в общем виде нет. Мы для наших задач реализовывали схему «поначалу может работать так себе, но потом хорошо», потому что нам надо было комфортную длительную работу с этим списком сделать — итого наши пункты списка потихоньку в фоне рендерились и замерялись. Через некоторое время замерялись все элементы, и всё начинало отображаться очень гладко, а до этого момента — ну, как повезет, скролл конечно мог вести себя довольно непредсказуемо.

Но принципиально другого решения тут, насколько я вижу, нет. Можно конечно замерять всё на сервере через SSR, чтоб не делать это на клиенте, но это принципиально такая же схема, только ответственность по-другому разнесена.
Вырезаем SSR и делаем смартфонам не из топовых линеек больно.

Нет, спасибо, оставьте, пожалуйста, SSR. Я лучше подожду пока картинки прогрузятся и буду спокойно всё читать.

На моём далеко не топовом смартфоне открытие комментариев в мобильной версии Хабра заняло несколько минут и 1% батареи. Браузерный рендеринг при этом остановился после 8 комментария. Я прождал ещё 2% батареи но так и не дождался продолжения. Ускоренная версия открылась за 10 секунд и летает.

Скролл для элементов с динамической высотой сделать сложно, видимо поэтому он и прыгает :). Но, сказать честно, реализация могла быть и получше. Идея ведь совсем не новая, даже для хабра (см. мою статью про похожую проблему аж 2011 года: https://habr.com/ru/post/111422/)

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

Например mol_number под Сафари просто не работает.

Вы придумали и решаете проблему, значимость которой переоценена. На Хабре мало статей с большим числом комментов, это скорее исключение, чем правило. И оптимизация таких редко встречающихся статей просто не имеет смысла.


Вы предлагаете какое-то жутко переусложненное (тормозящий браузер клиентский рендеринг) решение, на каком-то никому неизвестном JS фреймворке, ломая стандартный функционал браузера (поиск), да еще и с самодельным кешем на Service Worker (страшная бессмысленная технология). Алло, в браузере уже есть кеш, зачем вы предлагаете делать жалкое его подобие, которое только жрет память и замедляет браузер? Всегда можно открыть about:cache или как там и просмотреть кешированную страницу. Без всяких воркеров, JS и потребления памяти, прикиньте?


Самое быстрое и лучшее решение, на мой взгляд — просто отдавать с сервера HTML. Браузер умеет прогрессивно отображать HTML. Вы правы, что картинки стоит сделать лениво загружающимися. Но для отображения HTML нужен еще CSS, и тут разработчикам надо поработать. Надо отказаться от вредной идеи писать все стили в один файл и использовать громоздкие уродливые фреймворки вроде Bootstrap. Нужно выкинуть весь старый CSS код, начать писать для каждого компонента свой файл со стилями CSS, и к странице подключать только используемые на ней компоненты. Тогда объем CSS будет невелик (много ли CSS надо для отображения текстовой статьи? Не более 50 Кб навскидку) и страница будет загружаться быстрее. Увы, на практике почему-то встречается подход "склеиваем вебпаком все в огромный CSS на мегабайт и удивляемся, почему все тормозит".


JS файл, нужный на странице, можно подгрузить асинхронно — он не критичен для отображения статьи, если она правильно сверстана.


Далее, выкиньте веб-шрифты — они не нужны, но замедляют отображения текста. В современных ОС Windows и Mac уже есть хорошие шрифты.


В общем, при моем подходе, для отображения статьи надо всего 2-4 файла — HTML и 1-3 легких CSS файла. Это решение будет грузиться быстро и обладать простой архитектурой, и не потребует разбираться в залежах JS кода.


Также, предлагаю отказаться от метрики "время отображения первого экрана". Какой в ней смысл? Это приводит к нездоровым оптимизациям, когда первый экран грузится быстро, а все, что после него — долго. Это глупая и ненужная метрика, вы же всю статью прочесть хотите, а не первый экран (занятый шапкой и меню)? Последуйте моему совету насчет сокращения объема CSS и эта метрика вам не понадобится.


И что за бредовая идея описывать стили внутри JS кода? CSS справляется с этим намного лучше и не требует тяжелых библиотек для работы, в отличие от JS.


И что это за дурацкое название Maybe(Str)? Это называется Nullable(Str), а ваше название только сбивает с толку. В базе данных мы же пишем IS NOT NULL, а не IS NOT MAYBE. Зачем придумывать новые названия для существующих вещей?


Также, откажитесь от moment.js, это тяжелая переусложненная библиотека, от которой вы будете использовать 5% функционала. Заодно откажитесь от темных тем, бессмысленная трата времени, плюс в браузере есть режим для чтения на такой случай.

"склеиваем вебпаком все в огромный CSS на мегабайт и удивляемся, почему все тормозит".

Интересно, а есть webpack наоборот: вырезать из кучи зависимостей и отдавать только тот CSS и HTML, что нужны?

Есть. Но работает медленно. Чтобы удалить неиспользуемый css нужен готовый html. И при каждом изменении html нужно заново формировать css.

И плюс, для реально больших развесистых комментариев можно спокойно сделать пагинацию, примерно как наши предки сделади лет так пятьсот назад, перейдя с свитка на книги

Да такое впечатление, что все делают эти «бесконечные» страницы просто потому, что могут. Хотя пагинация позволяет отображать страницы намного быстрее, и с точки зрения юзабилити никакой разницы нет, нажать на кнопку «следующая страница» или крутнуть колесико мышки. Управление с клавиатуры? Тоже никакой проблемы, для «следующей страницы» можно добавить шорткат. Для поиска можно рядом с ссылками на страницы «1.2.3...» добавить ссылку «весь тред целиком», пусть желающие смотрят его себе целиком на здоровье.

А это можно решить как и в бесконечном скроле кнопкой сверху "появились новые комментарии, показать?" (в ВК так сделано). Я это к тому, что и при пейджинке и при бесконечно скроллинге добавление новых сущностей сдвигает последовательность.

Как-то можно, наверное. Но вот при пейджнге я думаю, не очень будет удобно по одной кнопке скакать с первой страницы на 50-ю...

А при кролинге от первой к 50-ой переходить удобно? Скролишь и материшься… Потому что при нормально сделанном пейджинге можно ходить как последовательно "назад" и "далее" по страницам, так и задать конкретный номер сразу.

Никаких проблем со скроллингом на Хабре не испытывал, правда нужды перейти на "первые/семнадцатые/последние 5% комментариев" тоже не испытывал: интересует или все комментарии подряд, или непрочитанные, или поиск по ctrl+f как по содержанию, так и по метаинформации типа ника, даты и времени. Хотя вру, иногда не хватает простого способа "перейти в самое начало или самый конец комментариев без обычной клавиатуры"

Проблема отображения комментариев в Хабре (и в косплеящем его в этой части DOU, как минимум), что если страница закрыта (даже случайно, ну ткнули когда не хотели в ссылку) и открыта заново, отметки читанности уже теряются. Поэтому задача всерьёз прочитать комментарии и не терять ни одного (не будем обсуждать, зачем это нужно — ну вот бывает) превращается в слишком зависящую от случайностей. А режима показа комментариев в плоском виде по порядку добавления — не делают принципиально — видимо, слишком гордясь деревом.

Этой проблемы нет, например, в RSDN — там есть и плоский режим с пагинацией (я почти всегда в нём), и дерево (дерево там сделано, с точки зрения современного веба, жутко топорно — для текущего комментария сделан отдельный фрейм, в который каждый раз подгружается вложенная страница с ним; но работает же...)

Да, есть такое. Не часто, но случается. И плоский режим помог бы при таких "форс-мажорах".


Boomburum что думаете?

Так это ортогонально плоскому режиму, всего-то надо метки читаности куда-то чуть более надежно сохранять.
Понравилась аналогия со свитком и книгой (выше) :) Однако в данной аналогии действительно не учитывалось то, что в момент перелистывания на страницах могут появляться новые абзацы. В целом мы не раз обсуждали переработку комментариев, есть концепты решений — если я правильно понял разработчиков, за каменты планируют взяться в начале нового года (до этого времени переписывают Хабр под единую m.версию).

Про Maybe и Nullable это вы зря. Maybe, Just, Some, Either — это целый отдельный, дивный мир.


Да и темная тема — если вдруг привыкнуть, а главное включать ее автоматом, то не такая уж это и пустая затея.

Тут явно есть обратная связь: чем хуже Хабр работает с комментариями, тем меньше статей с комментариями.


Кроме Windows и Mac есть ещё Linux


Причём вообще базы данных в разговоре о фронте? В SQL и JS семантика null разная.

Чистый html с ccs? Но люди же учили фрейморки (иногда вместо языков), тратили свое время и силы. Нет уж! Пусть пользователи мучаются, потому, что я знаю фреймворк.

Maybe, Moment — это просто локальные алиасы:


    const Int = $mol_data_integer
    const Bool = $mol_data_boolean
    const Str = $mol_data_string
    const Maybe = $mol_data_nullable
    const Rec = $mol_data_record
    const List = $mol_data_array
    const Dict = $mol_data_dict

    const Moment = $mol_data_pipe( Str , $mol_time_moment )
решаете проблему, значимость которой переоценена.

Не соглашусь, меня уже не первый год раздражают жуткие лаги при комментировании в популярных топиках. И решению этой проблемы без апгрейда моего железа я бы очень даже обрадовался.

На данный момент жуткие лаги при комментировании возникают не из-за отсутствия виртуализации, а из-за кривого редактора. Если отключить все обработчики нажатия клавиш (keydown, keyup и keypress) — лаги сразу же пропадают.


Только не спрашивайте каким таким образом скорость работы этих обработчиков зависит от числа комментариев...

И решению этой проблемы без апгрейда моего железа я бы очень даже обрадовался.

Переход на Firefox.
Предлагаете мне перейти с FF на FF? Отличное решение, правда проблема остается.;)
Просто у меня не тормозит, а ведь мой процессор это Ryzen 1200, который стоил мне около 3к рублей.
самодельным кешем на Service Worker (страшная бессмысленная технология).

Я её отключил, после того, как однажды зашёл на about:serviceworkers и увидел кучу сайтов, на которые заходил полтора раза год назад. В итоге сломалось только видео в VK, ну да не жалко, youtube-dl как ни странно справляется.

Открываю ваш вариант


  1. На вкладке сеть я вижу что текст статьи уже загрузился но мне его не показывают.
  2. Запрос комментариев на моём дачном глючном интернете показал фигу через несколько минут.

В результате вместо статьи без комментариев вижу фигу с ошибкой сети. К сожалению хабр не позволяет догрузить комментарии кусочками через Range или API(или я не знаю как).

  1. Спасибо, поправил. Сейчас статья и комментарии должны рендериться независимо друг от друга.
  2. Тут уже нужно изменение API, да.
На Хроме на какой-то баг с бегунком для прокрутки, не получается за него нормально схватится, но в остальном в отличии от серверного рендеринга хотя бы полностью дерево рендерит (при полной прокрутке). На лисе всё хорошо. Но Лиса из-за виртуального рендеринга и оригинальную страницу более менее нормально открывает. Насчет времени, всё так — 300мс против примерно 15с на html варианте. Порадовало более менее точное определение положения скрола и нормальный скролл к самомму низу страницы сразу. После прокрутки скролл почти не дергало взад-вперед, может немного и видимо из-за картинок, попавших в подгружаемую часть. По плавности скрол версии с $mol в Firefox был сравним с скроллом html версии в Хроме, немного проигрывая только html версии в Firefox.

Насчет корректности сравнения $mol и Vue.js говорить не берусь, с одной стороны у Vue.js тоже есть реализации виртуального скролла. С другой в $mol виртуальный скролл входит, как я понял, в ядро и доступен «из коробки».

Традиционные замечания по поводу синтаксиса шаблонов, который кроме как в $mol не встречается, и по поводу использования snake_case в языке в котором вся стандартная библиотека и все популярные библиотеки написаны в camelCase, я пожалуй особо расписывать не буду, вам уже писали про них без меня. Это в конце концов ваш выбор как разработчика.
Шустро, в Safari на iPad, а стандартная версия ужасна.

Однако, на MacBook загружается тоже во много раз быстрее, но… Время пролистывания на последний комментарии получилось существенно дольше, чем полная загрузка и пролистывание старой версии.

Вы забыли про блокировщики, в FF 79 полная загрузка занимает 42 с но с uBlock Origin сокращается до 21 с. Читать можно уже через 10 с, но не очень приятно из-за ресайзов от подгрузки картинок.

отключите js, если очень уж хочется комментариев оставьте habr.com и habrcdn.net. Полетит. При этом вы ничего не теряете.

Можно попробовать первоначально загружать комментарии без рендеринга, только текст. (По одному диву на комментарий)
Комментарии, который скоро попадут в область просмотра, заменять на полноценный контент.
Те, которые больше не понадобятся, заменять обратно на текст и сохранить высоту содержимого.
Это решит проблемы с поиском и, по большей части, с прокруткой.

Мне кажется, дело еще в том, что там структура тегов древовидная, тег родительского комментария содержит все дочерние комментарии. Браузеру сложнее это перерисовывать, чем если бы был плоский список, а структура комментариев регулировалась только отступами.

Код исходников уложился в 400 строк, на написание которых требуется не более пары часов

А это прямо ровно засеченное время на реализацию или примерное?

Ну как раз это на мой взгляд не особо-то и принципиально. Я бы скорее спросил сколько времени автор до этого потратил на изучение инструментов и оттачивание навыков, чтобы быть в состоянии решить эту задачу всего за пару часов и уложиться в 400 строк.

Вот я как бы уверен что попробуй я такое повторить и в два часа лично я вот никак не уложусь :)

Тут самые большие усилия требуются лишь на преодоление когнитивного сопротивления при изучении фреймворка. Дальше, в принципе, ничего сложного: архитектура простая, модули маленькие, апи стандартных компонент тривиальные. Тут главное не пытаться приспосабливать его под привычные паттерны разработки, а освоить новые. Собственно в хабрачиталке код простой как пробка. Самая большая сложность была в том как описать консистентную логику сворачиваний/разворачиваний при наличии/отсутствии фильтрации.

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

П.С. И на самом деле может теперь на досуге и взгляну. Хотя в работе мне это вряд ли пригодится в ближайщее время :)

Ну вот у меня есть сомнения, что в 2 часа реально уложиться. Более того. Возникло впечатление, что и сам автор в этот срок не уложился.

Это если я им буду более-менее регулярно пользоваться то разницы нет. А вот если я им и пользуюсь всего единоразово, то… :)

Для единоразовой работы лучше использовать ту технологию, которую вы умеете лучше всего. Изучать что-то новое имеет смысл для повышения эффективности в той работе, которая занимает у вас значительное время.

Т.е. это не результат прямого замера, так? Это просто предположение, сколько это будет занимать у тех, кто этим начнет пользоваться.

Вот тут я время замерял, если вам интересно: https://habr.com/ru/post/491120/#istoriya-uspeha


Там оказалось 2 часа на реализацию и ещё 2 пришлось подевопсить. Проработанные дизайн-макеты уже были. Повторение половины от расписанной там функциональности на высокоуровневом react-based фреймворке заняло неделю работы двух разработчиков.


Ну а если вы настолько прям сомневаетесь, то подписывайтесь на Ютуб канал, чтобы не пропустить скринкаст разработки очередного приложения.

Подскажите зачем используются атрибуты вместо классов? Что это даёт?

Что такое селекторы атрибутов я знаю. У вас в HTML коде куча атрибутов без значения которые используются явно вместо классов. Разве они не раздувают DOM и HTML?


Есть ли смысл использовать атрибуты вместо классов?


Если что у классов есть удобное браузерное API которое позволяет легко их добавлять и удалять.

Разница в скорости незначительна, семантики у классов никакой, гибкость у классов ограничена, 1 апи проще чем 2.

Так какие возможности дают атрибуты по сравнению с классами?


el.hasAttribute (name) > el.classList.contains (name)
el.removeAttribute (name) > el.classList.remove(name)
el.getAttribute (name) > el.classList.contains(name)
el.setAttribute (name, str) > el.classList.add(name)


А есть ещё:
el.classList.toggle(name) — добавить или убрать класс в зависимости нет его или есть в списке соответственно.


el.classList.replace(old_name, new_name) — заменить один класс другим.


Я не говорю что нужно использовать классы вместо атрибутов. Просто не надо использовать атрибуты вместо классов.

Что это даёт?

В случае с веб-компонентами даёт возможность подписываться на изменение любого свойства компонента через attributeChangedCallback, что часто очень пригождается.

Ну если очень нужно отслеживать добавление и удаление элементу класса то можно отслеживать атрибут class. Он будет меняться при добавлении и удалении класса.


Разбиваем по пробелам oldValue и newValue. Чего нет из oldValue в newValue удалено. Чего нет из newValue в oldValue добавлено.

А затем для передачи параметра mask="99.99.9999" вы начнёте городить парсер разбирающий класс mask_99.99.9999. А ещё вдруг окажется, что к таким классам из-за значения в нём теперь не прицепить ничего из css как можно было с именем атрибута. Да и пробелы иногда нужно в значении передавать. Не придумывайте себе проблемы.

Я не призываю использовать классы там где нужно использовать атрибуты.


Автор же использует атрибуты в роли классов. То есть у элементов куча атрибутов с пустыми значениями. И по именам этих атрибутов элементам задаются CSS стили.

Я не призываю использовать классы там где нужно использовать атрибуты.

Да даже если так, зачем создавать себе гемор вот с этим:


Разбиваем по пробелам oldValue и newValue. Чего нет из oldValue в newValue удалено. Чего нет из newValue в oldValue добавлено.

?


Автор же использует атрибуты в роли классов

А можете привести пример когда что-то должно быть именно классом и совсем не смотрится в виде атрибута?

Эм, стилизация отдельно, параметры отдельно? Не пойму о чём спор.

Иван пытается протолкнуть идею, что булевы параметры для стилизации обязательно задавать исключительно через классы и нельзя через атрибуты. Ему объясняют, что стили необходимо привязывать не только к булевым параметрам. А разделение на булевы и не булевы не даёт ничего кроме усложнения на ровном месте.

булевы параметры для стилизации

Эм, стилизация отдельно, параметры отдельно? Повторяюсь, да.
Эм, стилизация отдельно, параметры отдельно?

Зачем отдельно? Ситуация когда на добавление/удаление какого-либо атрибута нужно и в js как-то отреагировать и какие-то стили добавить у меня происходит регулярно. По вашему же получается нужно так:


<x-dropdown class="opened" opened></x-dropdown>
Видимо это новомодное реактивное (или как там) программирование, я такого не понимаю. Для меня есть код, который добавляет этот класс, вот там и нужно реагировать. А менять класс (или атрибут) в одном месте, чтобы в другом через слушатель отреагировать — это дичь какая-то, вот уж точно усложнение ради усложнения.

Если параметры компонента автоматически делать Observable, то да, часто и реактивное программирование находит себе применение:


export class OpalTextInput extends BaseComponent {
    // ...
    @Param(String)
    value: string | null;
    @Param(String)
    startIcon: string | null;
    @Param(String)
    endIcon: string | null;
    @Param(Boolean)
    clearable: boolean;
    @Param(Boolean)
    loading: boolean;

    @Computed
    get btnClearShown() {
        return this.clearable && !this.loading && !!this.value;
    }

    @Computed
    get endIconShown() {
        return !this.loading && !this.btnClearShown;
    }

    // ...
}

Слишком многое "там" может накопиться и рано или поздно что-то забудется добавить или что-то забудется уже ненужное удалить. Особенно если не в одном месте добавляется. Это в целом, а в случае веб-фронта так проще делать полифилы и прочие graceful degradation

Проблема "забудется" решается правильной структурой кода, не должно быть нескольких мест которые управляют одним и тем классом/атрибутом.

Вот как раз с подходом "есть код, который добавляет этот класс, вот там и нужно реагировать" и будет с большой вероятностью много таких мест, потому что класс (читай визуальное отображение) может быть один, а вот реакции (читай поведение) — разными в разных контекстах.

Если реакции должны быть разными — то на изменение класса/атрибута вы их никак не "повесите". А если не должны — то нет никаких проблем не дублировать код.

Повешу. При входе в контекст вешаю слушателей изменения DOM, при выходе снимаю.

В таком случае вам теперь нужно добавлять код в моменты входа в контекст и выхода из него. В два раза больше того, что можно забыть.

Не сложнее, чем отписка от событий объектов или закрытие потоков. И уж точно не сложнее освобождения памяти на С-ях.

Вот что я вижу здесь в инспекторе:


<mol_dimmer id="$my_habrcomment.Root(0).Article().Text([object Text])" mol_html_view_text="" my_habrcomment_article_text="" mol_dimmer="" mol_paragraph="" mol_view="" style="min-height: 72px;">

Как это могло бы выглядеть.


<mol_dimmer id="$my_habrcomment.Root(0).Article().Text([object Text])" class="mol_html_view_text my_habrcomment_article_text mol_dimmer mol_paragraph mol_view" style="min-height: 72px;">

Может даже класс "mol_dimmer" лишний так как элемент и так называется "mol_dimmer".

Каждый атрибут это тоже node() который имеет свои параметры и занимает оперативку.


1: mol_html_view_text=""
baseURI: "https://nin-jin.github.io/habrcomment/#article=423889"
childNodes: NodeList []
firstChild: null
isConnected: false
lastChild: null
localName: "mol_html_view_text"
name: "mol_html_view_text"
namespaceURI: null
nextSibling: null
nodeName: "mol_html_view_text"
nodeType: 2
nodeValue: ""

А класс это уже просто значение атрибута class.

Например на cтранице у меня сейчас отображается только часть комментариев.


Имеем 40КБ текста и 200КБ тегов и атрибутов просто как текст. Элементов 762 и атрибутов 5197. Как то многовато для 19 комментариев отображаемых на странице.

У приведённой страницы есть проблемы с потреблением памяти?

Автор решил проблему памяти держа в DOM только часть документа. Но при этом раздул количество объектов на единицу текста. От чего похоже у меня на планшете его вариант притормаживает больше чем десктопная версия на том же планшете.

Мне кажется дальнейший спор бессмысленнен, вы видете то, что хотите видеть и спорить тут бесполезно. Удачи.

Нода эта форма представления иерархических данных. Она создаётся в результате парсинга различных данных как универсальный объект несущий разный контент — css, html, dsl и т.д. Это основа виртуализации. Нет конечно можно компактно хранить в табличках и на лету динамически парсить в визуализируемый объект, выигрывая в памяти. Тут вопросы организации данных в том или ином фреймворке.

В памяти оно всё хранится в виде структур. Структура атрибута выглядит примерно так:


struct Attr {
    string* namespaceURI;
    string* nodeName;
    string* nodeValue;
    Element* ownerElement;
}

Это на 3 спички больше, чем просто ссылка на строку.

А класс это уже просто значение атрибута class.

Который парсится браузером в объект classList.

Один classList на каждый элемент. И он уже есть даже если вы им не пользуетесь.

А вы посмотрите, что в нём хранится: каждый класс отдельной строкой плюс все классы одной строкой.

Может даже класс "mol_dimmer" лишний так как элемент и так называется "mol_dimmer".

Не лишний. У наследника будет иное имя.

Итого при прокрутке на FF значительно отстаёт от нативной версии, аж скроллбар тормозит. Не, старый добрый HTML рулит.
Проблема существующая и очень важная. Но мне кажется, что истинно правильный путь – отдать эту часть на сторону браузера. Вы об этом сами и пишите. Тут как с флексами – гора хаков и море слёз до тех пор, пока caniuse не позеленел.

У вас хороший велосипед, мне правда нравится, спасибо за него! Но, кмк, все мы будем ездить в скором, надеюсь, будущем на нативной реализации виртуализации DOM.

Браузерная виртуализация сэкономит только на фиолетовой и зелёной части таймлайна:


Чтобы уменьшить жёлтую часть — нужна pull семантика в DOM, то есть необходимо реализовать существенную часть $mol_view на стороне браузера, на что я бы не стал надеяться.

Вы предлагаете Хабру добить полный набор антипаттернов разработки "веб-приложений", чтобы писать статью о том, "как нельзя" можно было на примере одного только m.habr.com?
Это без сомнения похвально, а то я чуть не забыл, что поиск по странице на Хабре все таки почти всегда работает (за исключением 500+ комментариев в мобильном хроме).

Потрогал на FF — грузится да, прекрасно. Но любая быстрая перемотка — перетаскиванием ползунка или еще какими способами — неизбежно оканчивается на пустом экране, на котором лишь спустя 200-500ms появляется контент, причём в точках с большой глубиной веток этот процесс еще и вызывает ощутимые потряхивания контента вверх-вниз, пока там всё отрендерится.

Проблему медленной загрузки это действительно решает, создавая новую проблему примерно той же степени раздражения.

ЗЫ: К слову, если какое-то время назад хабр на множестве комментов был вообще неюзабелен (страница могла тупо зависнуть, переход к непрочитанному переходил куда угодно, но только не к непрочитанному) — то теперь это всё починили, и после всей долгой загрузки страница даже с огромным количеством комментов работает надлежащим образом (но может подтормаживать, да).

Нифига не починили. Когда открываю ссылку на коммент из почты, практически никогда страница не скроллится точно к этому комменту, всё время открывается "ну где-то рядом тут, поищи сам".

Интересно начали, но этот пиар $mol — напрягает.

Что я понял по вашим статьям:
У человека есть свой взгляд на мир, он хочет сделать его лучше(и чтобы другие люди начинали делать лучше), но не умеет доносить это до других людей и не хочет учитывать их мнения.
Если Вы хотите делать это дело продуктивнее — надо слушать других людей, не обязательно быть согласным с ними, но хотя бы не огрызаться.

Пока, для медианного человека в вакууме — это выглядит как попытки сумасшедшего предсказать конец света.
SSR, по большому счету, нужен только для SEO.
Если вам SEO не нужно, можете смело забить на SSR.

Хочу отметить, что тормоза при прокрутке и при наборе комментариев связаны не с размером DOM, а с чрезмерной заскриптованностью. На каждое событие, буть то нажатие кнопки или скролл зачем-то навешаны обработчики. И если отключить JS, то всё будет работать плавно.


Так что моё решение — четвёртое. Надо не отрезать ногу, а лечить пациента. Оставляем HTML/JSON-версию и просто убираем прожорливые обработчики.

Сейчас померил без скриптов, у меня выходит примерно 250мс на каждое смещение скролла. Пересчёт лейаута всё такой же медленный.

UFO landed and left these words here
шрифты нужно точно оставить в прошлом. Там не обязательно нужны двухцветные. Там opacity достаточно при наведении возвращать к 0. Я бы только иконки выводил бекграундами, чем урлами. Мне кажется бекграунды память жрут гараздо меньше при огромном количестве копий.
UFO landed and left these words here
да, верно, там же альфа канал считается, он дожен быть тормознее,

Оптимизация синоним хрупкости. Экономия на спичках даст ровно противоположный эффект: поддерживать и улучшать станет сложнее, баги будут фикситься дольше. Решение проблемы нужно искать в другой плоскости.

UFO landed and left these words here

Мы остались в той же плоскости, чтобы уйти в другую плоскость нужно задавать другие вопросы. Например: почему пользователям нужно грузить все 2500 комментариев при начальной загрузке страницы?
Не стоит вопрос в полном отказе от оптимизации, но любая оптимизация должна быть осмысленной и продуманной.

Например: почему пользователям нужно грузить все 2500 комментариев при начальной загрузке страницы?

Чтобы работал поиск.

А теперь можно пойти дальше и спросить: как можно искать по комментариям кроме рендеринга всего списка? Что можно искать в комментариях? Ну и так далее.

Пожалуйста, только не надо делать свою альтернативу Ctrl/Cmd + F! Возможно я не видел нормальной реализации, но всё что видел — довольно убого.

Автор поста ровно это и сделал, в чем проблема? Если у вас есть желание рендерить сразу 2500 комментов, то другого решения просто нет

Ну в этом и проблема, если честно. В этом треде пытаются подобрать альтернативу реализации автора поста — потому и появилась просьба.

Проблема в том, что автор вместо нормального поиска сделал фильтрацию. Которая не заменяет все сценарии использования поиска.

UFO landed and left these words here
Не знаю как кто, но мне интерфейс Firefox 3.6 кажется идеальным, с последующих версий он только деградировал.

Реализация комментариев в мобильной версии хабра ущербна чуть меньше чем полностью. Она тупо не грузится на мобилках в большинстве случаев, если комментов более чем 200-300. То, что предложил автор — лучше, но тоже криво. Если хотите посмотреть, как сделать нормально комментарии — откройте пикабу и посмотрите. На нем есть посты со многими тысячами комментариев и ничего не лагает. Достигается это засчет того, что комментарии подгружаются по клику, когда появилась необходимость посмотреть очередную ветку комментов. Как веб-разработчик я могу с уверенностью заявить, что, страницу надо проектировать всегда так, чтобы отображалось и грузилось только то, что необходимо пользователю в данный момент + ещё небольшое количество информации. А если внезапно нужен поиск информации, то это должно реализовываться на бекенде, а не тащиться вся бд на клиента и грузить его.

Если хотите посмотреть, как сделать нормально комментарии — откройте пикабу и посмотрите.

А ещё на пикабу не теряется информация о непрочитанных комментариях, если страница не загрузилась или же загрузилась, но пользователь случайно перезагрузил страницу.

Достигается это засчет того, что комментарии подгружаются по клику

У меня палец отвалится кликать. Поэтому я не читаю ничего на пикабу, да и не зареган там.
Barbaresk Как веб-разработчик я могу с уверенностью заявить, что ....
А я как пользователь хочу, чтобы все комментарии загружались сразу, без необходимости совершать какие-то дополнительные действия (в том числе прокручивать страницу). Как это сделать — не мои проблемы. Варианты решений: меньше js, обработчики событий подгружать при попадании в зону видимости (ими редко пользуются) и т.д.

upd: промазал, надо было сюда
Firefox 78
Страница открывается секунд за 5 вместо 12, что конечно хорошо, но незначительно. Ибо я открываю один раз и читаю всё остальное время, а вот тут уже проблемы. Если зажать pgdown, то получается лютый лагодром с моргающим текстом и дёргающимся скролом. Заметно даже если нажать один раз, а не удерживать.
И поиск ужасен. Помимо того что после нажатия каждой кнопки страница виснет секунды на две, так он ещё расположен не в привычном месте, не показывает сколько найдено, нету кнопок назад/вперёд, «подсветить всё» и прочих.

В целом, отрицательное впечатления. Очень много мелких раздражающих деталей типа кривого смещения после сворачивания/разворачивания ветки. Только тёмная тема порадовала.
Ломается не только Сtrl+F,
Похоже ломается еще и сохранение в Evernote/Onenote статьи + комментарии (я же правильно понимаю что варианта с показом ВСЕХ ВООБЩЕ комменариев — больше нет?).
Ломается видимо и поиск запросом вида site:habr.com <ключевые слова которые точно были в комментариях но хочется найти статью и комментарии>
Для мобилок еще ладно, там мало ресурсов и такое решение может иметь смысл но для десктопа — плохо.
Ломается видимо и поиск запросом вида site:habr.com

Нет, выдача для поисковика делается с полным HTML.

Вместо поддержки двух абы как слепленных реализаций для разных девайсов, лучше потратить это время на одну, но толковую и адаптивную

и писал в техподдержку Хабра про это. Мне сказали — на мобильном у-ве сиди на мобильной версии, мы десктопную версию на мобилках не поддерживаем (фейспалм). А самое интересное действительно происходит именно в горячих статьях с 1000-ми комментариев. Приходится выкручиваться.
Очень надеюсь, что разработчики воспримут статью серьезно и перенимут из нее часть технических решений — как минимум пользовательский опыт реально станет лучше

Да уж, у меня типичный ритуал с мобильной версией выглядит так:


  • открываю Хабр
  • переключаюсь на десктопный вид
  • зумлюсь и жму колокольчик, чтобы перейти на страницу уведомлений
  • переключаюсь на мобильный вид
  • жму на общее число комментариев (но не на число новых комментариев!), чтобы перейти на страницу комментариев

А всё потому, что довольно тривиальную страницу уведомлений всё никак не завезут на мобильную версию.

У меня один один. Было бы не плохо позвать разработчиков хабра в тред.

Я тут понял, что неправильно замерял потребление памяти: вместо размера JS heap надо замерять выделенный для вкладки объём. Разница получается ещё более удручающая:


Десктопная версия: 800 MB
Мобильная версия: 1000 MB
Ускоренная универсальная версия: 80 MB


Скорее всего именно этим и объясняется, что на моём телефоне рендерятся лишь несколько первых комментариев — памяти не хватает на всё остальное. Поправил статью.

Говорю же вам, софт кривой. Вот 400. Ваша скушала 115 после того, как я её рандомно помотал во все концы.

Поговорим об этом, когда FF станет доминирующим браузером.
Подождите, пока браузер соберёт мусор — упадёт обратно на 80.

Поговорим об этом, когда FF станет доминирующим браузером.

Он уже доминирует. У меня на компьютере. Всегда можно показать ссылку сверху на установку правильного браузера.
Думаю уже и не поговорим:

Димочка пора уже функциональное программирование подучить и начать заниматься хотя бы йогой, а не только mol)

Only those users with full accounts are able to leave comments. Log in, please.