Comments 147
Ну, теперь осталось что-то с трекером сделать 🙂 А то какой-то он загадочный иногда: "Ну, вроде 1, но я не уверен".
Классные комментарии, что их нельзя редактировать до провеки
Мне кажется, или новые комментарии из-за ленивой загрузки уже не индексируются поисковиками?
Я слишком устал писать багрепорты, чтобы оформлять багрепорт ещё и на хабр, но ваши комментарии и редактор - это слёзы и боль. Половина кнопок редактирования не работает (например, из абзаца нельзя прейти в предыдущий абзац стрелочками), вторая половина активно саботирует сделанное. Любоё форматирование сводит редактор с ума (как мне снять pre с последнего пробела после "форматирование"?)
Безумие и чистой воды хаос.
Привет, а напишите что у вас за ОС/Браузер?
Debian/FF.
Только не говорите, что у вас оно работает.
А версия ОС/ФФ какая? Мы поддерживаем 2 последних мажорных версии браузеров
В смысле две? FF релизится каждые 4 недели. Вот у меня FF 90 - он уже не поддерживается что ли??
Да, мы тестируем релизы только на 2-х последних версиях. В случае с ФФ это связанно с тем, что один и тот же код не работает одинаково в двух разных версиях ФФ.
Эх ну дела!
Сайт для программистов (ну ок, не только, но тем не менее!), который работает только в последних версиях некоторых браузеров. Ну вы даете..
Ну я всё же позволю себе заметить, что мы поддерживаем все популярные браузеры (список тут). При этом мы не игнорируем обращения пользователей, если их браузер не обновлён до самой последней версии, однако гарантировать стабильную версию работы в старых билдах мы не можем.
Но вот в статье
developer.mozilla.org/en-US/docs/Web/CSS/contain-intrinsic-size
developer.mozilla.org/en-US/docs/Web/CSS/content-visibility
мало того что экспериментально, так ещё и работает только в браузерах на движке хрома.
У Firefox есть ESR ветка браузера с долговременной поддержкой (для организаций и для тех кому не нужны ежемесячные эксперименты и нововведения) wiki.mozilla.org/Release_Management/Calendar
В Linux в Debian ветке сейчас какая-то пауза возникла с обновлением ESR ветки с 78 на 91. Обычные версии обновляются.
Хром прекращает обновлять версии для вин7 с 15 января, дальше там будут только дыры в безопасности закрывать в течение года.
Мало того, что в тихаря делается новая версия хабра которая не понравилась большинству (уже были статьи по этому поводу), так и с комментариями из крайности в крайность.
Мне нравится старая версия хабра, она работает со всеми браузерами: и старыми и новыми, и выглядит приятнее чем «мобильный» вариант новой версии.
На ютубе комментарии подгружаются по мере прокрутки страницы, опять же на многих сайтах есть сортировка по дате, по «лайкам» и пр. Зачем вообще показывать сразу все комментарии?
Мне нравится старая версия хабра, она работает со всеми браузерами: и старыми и новыми, и выглядит приятнее чем «мобильный» вариант новой версии.Неистово двачую! В старой версии еще и форма отправки комментариев нормальная, не кастрированная и работающая даже в довольно древнем по современным меркам Firefox ESR 52. Надеюсь, что хотя бы её вернут, поскольку с чтением справиться всё же проще (некоторые сайты и так уже приходится читать через view source), чем с отправкой.
В старой версии еще и форма отправки комментариев нормальная
Сижу на старой версии. В ней что-то сломали. Причём не так давно. Может с месяц. Вроде всё работает, работает… Но в какой-то момент (когда пишешь большой комментарий) она начинает себя очень неадекватно вести. Курсор стоит в одном месте, печатает в другом, стирает куски текста. В общем какие-то аномалии. Уже несколько раз натыкался на такое и вынужденно писал комментарий в редакторе, а потом переносил этот текст в эту вот textarea.
Мне нравится старая версия хабра, она работает со всеми браузерами: и старыми и новыми, и выглядит приятнее чем «мобильный» вариант новой версии.
У меня старенький планшет просто раскалялся при открытии страницы с большим количеством комментов в старой версии, и индикатор батареи начинал считать минуты. Причем жор CPU продолжался все время, пока открыта страница, даже когда она полностью загрузилась. Речь о страницах с >1000 комментов.
Вы сейчас говорите про старую мобильную версию, а не про старую десктопную, которая работала везде и без особых проблем.
Мобильная была адом, да.
Так ведь у FF есть две актуальные ветки - обычная и ESR. Например в Debian поставляется по-умолчанию esr-версия, возможно, что и в других дистрибутивах тоже такое практикуется. Почему бы не протестировать и в ней? Тем более, что в обновлениях там только бэкпортят обновления безопасности, так что вряд ли поддержка потребует много усилий
«Так вы слона не продадите!» ©
К сожалению, с FF действительно все еще есть проблемы. Мы работаем над этим, но это не простая история.
В Firefox 52.9.0 картинки размытые. Это чинится?
зы. Оюъясните почему исходники сайтов не прогоняют через обфускатор для уменьшения объема? Нафиг по сети гонять все эти пробелы с табами?
Раньше при открытии статьи всегда было видно сколько у нее комментариев - во всплывающей строке они были. Сейчас там только счетчик закладок (зачем?) и количество просмотров (хм, тоже спорная метрика). По мне - так комментарии полезнее всего были там. Перейти сразу в комментарии тоже нельзя. Особенно на мобильном - приходится как-то скроллить все.
"Ленивая" загрузка - тоже зло. Открываешь несколько страниц в соседних табах, чтобы потом прочитать - но они не загрузили ни картинки, ни комментарии. Приходится открывать страницу и быстро скроллить ее, чтобы все загрузить. Сайт не для читателя, а для админов бэкенда, чтобы им полегче было?
Про счетчик непрочитанных вам уже говорили много раз - верните старый. Пока есть хотя бы один, не отмеченный прочитанным, комментарием - не обновишь их (кроме как всю страницу). Мало того что он часто глючит и не переводит дальше, так еще и и часто не в то место переносит.
Трекер - у меня он никогда не сбрасывается. То есть сначала он показывает что есть новые комментарии, я на них перехожу, их читаю, а потом отдельно отмечаю в трекере что все, погасни уже.
На vc.ru прикольное обновление комментариев есть кстати, можно от туда взять
Да, «ленивая загрузка» это то, за что руки бы поотрывал.
Особенно если инет не стабильный. Может быть в центре Москвы с гигабитным 5G на новеньком макбуке сайт и нормально работает. Но для обычных людей он стал сильно тормознее...
> заботы об accessibility. Семантическая разметка, aria, конференции о важности инклюзивности,
что касается accessibility, то и её сломали новой версией. говорю вам как незрячий читатель хабра.
Я все жду, когда же бесконечная лента будет? Давно пора уже.
Открыл случайную статью с некогда флагманского устройства, и уж не знаю, связана ли такая работа сайта с комментариями, но по-моему это прям за гранью:
Фризы по 5 секунд, разливающаяся при скролле страница
На протяжении всего теста пытаюсь проскроллить страницу. В конце можно увидеть, что проблема явно ни как не связана с устройством, к тому же на других сайтах такого поведения не наблюдал.
Позиция скролла — что бы вы не говорили — не восстанавливается после возврата в половине случаев.
Справедливости ради, когда я попадаю в имя юзера, перехожу в его профиль и возвращаюсь обратно, над его ником появляется вот такая бесполезная штука:
Какую проблему вы решили? Ради чего это всё?
Тут я рассказывал про эти проблемы год назад: Вырезаем SSR и ускоряем Хабр в 10 раз:
Кроме того, на мобильном ff нажатие на число непрочитанных не срабатывает если не нажимать НАД числом (на сантиметр выше).
Не работает выделение в окне редактора комментария.
Ну из из того что писал в поддержку, но было полностью проигнорировано, отвалились хоткеи (t, f). Это просто пушной зверёк какой удар по юзабилити.
Уточню, за срабатывания кнопки перехода на следующий непрочитанный комментарий плавает в зависимости от позиции скролла: то она прямо на цифре, то упрощает на сантиметр вверх. Приходится постоянно скроллить туда-сюда чтобы нечаянно не ткнуть в минус под комментарием или кнопку "ответить" (в зависимости от текущего уровня в дереве). Это даже не ужас, а настоящий ужас-ужас.
Тем более если старую версию сайта планируете в скором будущем убрать.
Разумеется, никаких Google Webcomponents.
Вы уверены, что понимаете о чем пишете? По моему, нет.
Custom Elements и Shadow DOM - поддерживаются во всех современных браузерах. Давно.
Скажем так... Современный браузер должен поддерживать современные веб стандарты. Если не поддерживает - это не современный браузер и его место на обочине. И если количество пользователей этого браузера теряется за погрешностью - тут даже говорить не о чем.
Хромиум никак не может быть новым IE так как, в отличие от IE, он кросс-платформенный и open source. Разница огромна, хотя в целом - да, такая монополия не очень хорошая штука (я бы, скорее, новым IE назвал Safari).
Но это все мало относится к вашему изначальному комментарию, где вы Web Components назвали "Google Webcomponents", при том, что это стандарт, принятый консорциумом и к созданию которого, помимо Гугла, приложил руку много кто еще, например Mozilla, MIT и т. д. Web Components - однозначно в списке лучшего, что случилось с веб-стандартами за последнее время, наряду с ESM, CSS custom properties и т. д. Их можно и НУЖНО использовать, именно для того, чтобы ваши гибридные приложения работали без тормозов.
Прибить гвоздями ваше реактивное приложение к нереактивному дому, который является хостовыми объектами, работа с которыми толком не оптимизируется jit-компилятором, - это худшее, что можно было придумать.
Про open source — ну, попробуйте форкнуть и поддерживать независимый браузерный движок, не будучи Гуглом…
В вебе эффективно осталось 1.5 движка
Ещё webkit. На десктопах 10%, а на mobile куда больше (все браузеры на iOS под капотом используют его). И нет, webkit не blink, они уже очень сильно разошлись.
Так стандарты же не гугл разрабатывает.
Если гугл перестанет поддерживать, не найдется других компаний? линукс же разрабатывают много компаний и вообще сейчас blink не только google разрабатывает, вон Google, Facebook, Microsoft, Opera Software, Adobe, Intel, IBM, Samsung коммитят.
Трекер теперь показывает погоду, вместо откликов на комментируемую статью и откликов на твой комментарий.
Редактор стал хуже, хоть и не критично.
Открываем по клику на комментарии - статью не видим, открываем статью - вместо плашки с новыми комментариями - плашка с рейтингом статьи или ничего.
Один негатив, писать тут больше не хочется. Нововведения ради нововведений?
Это с ПК, Вин10, последняя Опера.
Сказ о том, как 13 человек в течении полугода убирали постраничную навигацию в комментариях ;)
Воу, давайте протестируем. На почту пришло уведомление о новом комментарии в статье, которую я когда-то прочитал. Тыкаем по ссылке: https://habr.com/ru/post/423889/#comment_22820664
Всего через 7 секунд мы уже видим.. начало статьи, которую мы уже давно прочитали. Не плохо! На 20 секунде мы уже видим нужный комментарий. И у нас есть целых 3 секунды, чтобы его прочитать. После чего страница начнёт дёргаться, очистится, и ещё через 4 секунды начнёт рендериться с самого начала. Следующие 20 секунд мы можем любоваться, как полтора гигабайта памяти утекают в неизвестность. И да, если не успели дочитать тот комментарий - придётся его теперь поискать самостоятельно с самого начала. Вы же запомнили, как он выглядел?
Хех, ладно, откроем и мою прошлогоднюю демку: https://nin-jin.github.io/habrcomment/#!article=423889/comment=22820664
Там, конечно, нет гидратации, нет кеширования, нет стриминга, нет серверного рендеринга. Запилена она за 1 вечер командой из 1 программиста и 1 котика. В общем, не удивительно, что с ней приходится ждать аж целых 4 секунды, чтобы попасть к нужному комментарию. Скорость может быть и выше, но ощущение скорости совсем не то!
Воу, давайте протестируем. Жмём по ссылке на комментарий из вашей прошлогодней демки, и… очень быстро открывается статья, которую наверняка кто-то давно прочитал, и всё. До комментария надо очень долго скролить. Кстати, а до которого надо скролить?
Я уже молчу о том, что на телефоне вёрстка комментариев выглядит ужасно. Наверно котик лапками верстал.
По Ctrl-F текст коммента, который не во viewport не ищется. Так-то понятно, что виртуальный скролл будет работать шустрее. Плюс, сам скроллбар не работает как системный. И непонятно, будет ли работать индексация поисковиками комментов в вашей версии.
Так что это хоть и быстрый, но всё-таки не равнозначный аналог.
Странно, у меня и ищется, и скроллбар системный. А поисковикам в любом случае надо отдавать отдельную легковесную версию без скриптов, стилей, лишних тегов и всяких сайдбаров.
Тут я рассказывал, как это всё работает: Автоматическая виртуализация рендеринга произвольной вёрстки.
У меня поиск вообще работает очень странно. Перешёл по ссылке, открывается последний коммент. Набираю слово "фаз". На моменте "фа" меня перекидывает почти наверх в статью. Если вставить слово "фаз" находясь на самом комменте - всё ищется. Если вставить слово, находясь в статье - не ищется. Если вставить слово "фаз" в поиск, находясь на последнем комменте, потом удалить букву "з" и потыкать в стрелки перехода к следующему/предыдущему слову, то последний коммент пропадёт из поиска. Завтра может запишу скринкаст всего этого. Если что, смотрю в хроме.
На моменте "фа" меня перекидывает почти наверх в статью.
Это потому что по мнению nin-jin поиск нужно начинать не с текущей позиции, а сначала. Ещё по его мнению на скролл-баре не нужны индикаторы найденного, горячие клавиши годятся те, которое работают у него и т.д… Этакий подход — реализовать то чем пользуюсь сам. Удобно же… ну nin-jin-у удобно.
У нас тогда был спор про то, что виртуальный скроллинг штука конечно хорошая, но уж больно сложно сделать его хорошо, не ломая пользовательские привычки и устоявшиеся паттерны применения. Что даже в одном только поиске по странице есть множество нюансов. В поведении скролл-бара множество нюансов. В том о чём 0xd34df00d писал есть множество нюансов. Там куда не плюнь можно целую статью про UX писать.
Теперь когда я вижу очередной (9999-й) комментарий про то как $mol доминирует над всеми фреймворками, и как мощны его лапищи крут его виртуальный скроллинг "по умолчанию", и как убоги все остальные решения, я вспоминаю саму философию этих решений — "правильно так, как я привык и как мне нравится, а аргументы в свою пользу я всегда найду". И желание что-то оспаривать пропадает :-)
Кажется я догадался в чём дело. Скорее всего запускался нативный поиск вместо кастомного. Я добавил костыль, чтобы всегда запускался кастомный. Попробуйте теперь.
в chrome скроллбар не системный. И зачем цвет сколлбара такой темный сделан?
Странно, у меня и ищется
Ищется только то, что видно на экране.
Думаю стоит сделать уточнения почему нельзя сравнивать эти два абсолютно разных подхода. Вот какие ограничения у нас были при решении проблемы долгой загрузки комментариев:
Наше решение желательно должно было работать на Vue, т.к. весь проект уже был написан на нём и Vue себя очень хорошо зарекомендовал. Единственное проблемное место с которым мы столкнулись это отрисовка и гидратация очень больших списков (и тем более деревьев). Именно эту конкретную проблему мы и хотели решить, желательно не переписывая при этом весь проект на другой стек технологий, ведь всё остальное нас вполне устраивало. Мы рассматривали другие решения которые бы могли помочь с этой проблемой, но только как запасной вариант, если ничего не поможет. Как потом выяснилось — это вполне реально сделать на Vue.
Взаимодействие с комментариями не должно деградировать. Это значит что мы не можем использовать кастомный скролл или виртуализацию DOM. Последнее не подходит для текста, т.к. там нет поиска и есть проблемы с выделением текста. К тому же оно совершенно не подходит для индексации поисковиками. Это одно из первых решений которое мы отбросили.
Пример со ссылкой на комментарий из другой статьи на самом деле баг который мы починим. Она не должна открываться в режиме SPA. Спасибо что обратили на это внимание.
У меня просто нужно 20 с ждать чтобы к комментарию перешло, это долго, считаю.
На старой версии Chrome 86 (Cent Browser) вообще не переходит к комментарию.
Браузер
______ ,,
,.-"` | ,-` |
.^ || |
/ ,-*^| || |
; / | || ;-*```^*.
; ; | |;,-*` \
| | | ,-*` ,-"""\ \
| \ ,-"` ,-^`| \ |
\ `^^ ,-;| | ; |
*; ,-*` || | / ;;
`^^`` | || | ,^ /
| || `^^` ,^
| _,"| _,-"
-*` ****"""``
qutebrowser v2.4.0
Git commit:
Backend: QtWebEngine 5.15.7, based on Chromium 87.0.4280.144
Qt: 5.15.2
CPython: 3.9.9
PyQt: 5.15.6
sip: 6.1.0.dev2104271705
colorama: 0.4.4
jinja2: 3.0.3
pygments: 2.10.0
yaml: 5.4.1
adblock: 0.5.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebEngine: 5.15.5
PyQt5.QtWebKitWidgets: yes
pdf.js: 2.11.338 (/usr/share/pdf.js/build/pdf.js)
sqlite: 3.37.0
QtNetwork SSL: OpenSSL 1.1.1l 24 Aug 2021
Style: QStyleSheetStyle
Platform plugin: xcb
OpenGL: X.Org, 3.1 Mesa 21.2.5
Platform: Linux-5.15.6-2-MANJARO-x86_64-with-glibc2.33, 64bit
Linux distribution: Manjaro Linux (manjaro)
Frozen: False
Imported from /usr/lib/python3.9/site-packages/qutebrowser
Using Python from /usr/bin/python3
Qt library executable path: /usr/lib/qt/libexec, data path: /usr/share/qt
Paths:
cache: /home/oxyd/.cache/qutebrowser
config: /home/oxyd/.config/qutebrowser
data: /home/oxyd/.local/share/qutebrowser
runtime: /run/user/1000/qutebrowser
system data: /usr/share/qutebrowser
Autoconfig loaded: no
Config.py: /home/oxyd/.config/qutebrowser/config.py has been loaded
Uptime: 0:29:41Система
OS: Manjaro Linux x86_64
Kernel: 5.15.6-2-MANJARO
Resolution: 1366x768
CPU: AMD E-450 APU (2) @ 1.650GHz
GPU: AMD ATI Radeon HD 6320
Memory: 4897MiB / 5537MiB
Мне в целом все нравится в плане улучшения работы комментариев, часто читаю с телефона, грузится все намного шустрее. LGTM 👍
В любом случае, спасибо вам.
Пару раз нужно было удалить коммент и не смог.
Это запрещенная опция или я не там искал?
Например:
Опубликованные комментарии уже нельзя удалить.
Никогда не понимал в чем проблема вывести большое количество элементов на странице, почему-то веб разработчик часто просто говорят, что так не делается. У нас была задача выводить дерево Active Directory на миллион пользователей, особых проблем не возникло, просто сделали ленивую загрузку с загрузкой блоками по 1000 и в DOM создаются только те элементы которые реально отображаются в данный момент, при прокрутке перерисовывается их содержимое и если надо подгружаются недостающие данные.
прокрутке перерисовывается их содержимое и если надо подгружаются недостающие данные.
Это называется виртуальный скроллинг. Он ультимативно быстрый. Но в нём безумное количество подводных камней. nin-jin про многие из них писал в одной из своих статей (рекомендую к прочтению). И я думаю это была только половина.
Теперь ждем статью как вы убивали трекер. Может кто-то обьяснит наконец, в чем теперь его логика и зачем надо было уродовать ценнейший элемент вашего сайта?
Согласен. Я не выдержал новой версии и вернулся на старую в первую очередь из-за трекера. Теперь всё жду того дня, когда старую версию убьют и всё сразу станет очень плохо :)
Мне вот что непонятно: захожу на коммерческий ресурс, приносящий прибыль и на мне тестируют какие-то нововведения. И так везде.
Это как если бы сотрудники Yamaha ночью прокрались ко мне домой, поменяли местами струны на гитаре и оставили записку: ну что, расслабился, пе_рила, разучил пару песен, привык, а мы тебе сюрприз приготовили, что б жизнь малиной не казалась! А разработчики цифровых продуктов, судя по всему, уснуть без этого не могут.
Спасибо. Наконец-то на мобилке можно нормально открыть комментарии и не ждать несколько минут, пока загрузятся.
Немного не по теме. Было бы круто, если бы картинки в статьях сразу грузились. Бывает, открываешь несколько статей во вкладках, спускаешься в метро, где не ловит интернет, начинаешь читать - все статьи без картинок. Доезжаешь до следующей станции, обновляешь страницу и скполлишь до конца. Если повезёт, все картинки успеют подгрузиться.
Почитайте мою последнюю статью здесь на хабре, я там описал проблемы со скролом и то как их решал.
№1. Проверка возврата скролла:
Скролю до 300го комментария, визуально запоминаю позицию скролла и смещение контента.
Нажимаю на рубрику в меню (All streams)
Нажимаю на кнопку вернуться назад
Итог: скрол не вернулся в то место на котором был.
№2 При обновлении страницы скролл возвращается не в том место в котором был
Вообще если бы я бы решал эту проблему, то я бы по другому бы все сделал. Поскольку я так понимаю у вас задача показать все комментарии на первом экране, то я бы начал с того что облегчил бы верстку по максимуму. SVG и картинки из первого показа должны быть убраны. Я бы так же убрал заглушки для картинок - они тоже жрут ресурсы. Блок под комментарием тоже бы скрыл но оставил бы под него место, поскольку он фикс-высота то его можно и потом через js показать. Ну и посмотрел бы насколько бы быстро загружалась бы подобная страница с такими комментариями, если скажим их 1000 штук. Собственно эта страница была бы эталоном скорости, максимум который можно получить. Т.е. эталон вообще не использует JS: только css и html.
Ну а после того как был показан первый экран, уже можно интерактивные элементы развешивать по DOM. Опять же зачем показывать картинку если я до нее не доскролил? Можно и не показывать. Даже интерактивные кнопки под комментарием можно рендерить только тогда когда они в видемой зоне скролла окажутся. Опять же тут проблема гидрации начинает подтягиваться все равно, и здесь в любом случае подвисание всего и вся если гидрировать все и сразу. А делать гидрацию только видимой обласит наверно сложно. Незнаю на сколько подходит для этих задач Vue js, к сожелению не разу его так и не попробовал, зато могу сказать про React. Ну собственно те проблемы что вы описали с перерендером всех комментариев при обновлении рейтинга я в tolstoycomments тоже испытал и на React. Я тоже эксперементировал с кол-во комментариев на страницы и адекватной скоростью их рендера. В итоге я пришел к выводу что больше 130 каментов на странице не показываю. Т.е. прокрутка вверх/вних скрывать каменты снизу/сверху. Конечно у нас виджет и подход немного другой. Проблема с восстановлением скролла решена частично. Проблемы с прокруткой скролла и смещенеим тоже решена частично. Олаживать работу скролла эта конечно очень не простое занятие.
По React могу сказать что как только я отказался от классовых компонентов и переписал все на чистые функции, скорость заметно выпросла. Конечно я думаю что я просто в первый раз код был написан просто не очень удачно и в этом была проблема:) Ну и да, нужно следить за тем чтобы не делать лишних рендеров если по факту ничего в компоненте не поменялось.
Интересно, можно ли организовать подгрузку комментариев кусками? Чтоб сначала загружался чисто текст статьи, а затем в фоне подгружались комменты штук скажем по 100. Так по идее можно было бы и заморозки интерфейса избежать и комментарии вывести сразу все, а не только видимую пользователем область.
В старом интерфейсе эти клавиши искали следующий/предыдущий непрочитанный комментарий от текущей позиции скролла. Теперь позиция скролла не учитывается.
Юзкейс: вы открыли статью и нажали j, чтобы перейти на первый непрочитанный комментарий. За ним идет большая непрочитанная ветка дискуссии, которую вы просматриваете скроллом. Ветка заканчивается. Вы снова нажимаете j, чтобы промотать до следующего непрочитанного комментария, от которого начинается следующая ветка.
Так было раньше. В новом интерфейсе нажатие j перекинет вас назад, на второй комментарий ветки, который вы уже давно прочитали.
У вас с картинками в комментах проблемы
https://habr.com/ru/company/beeline/blog/194000/comments/#comment_23690742
Загружаемые фотки на компе отображаются нормально, а у вас почему-то повернулись на 90 градусов. Причем если по фотке кликнуть, то она отображается в правильной ориентации, но с неверными пропорциями. Самое интересное, что сразу после создания комментария фотки в нем отображались корректно, проблему заметил только после повторного захода на страницу.
Немного странно видеть картинку в формате png размером 2.5 мегабайта в статье про оптимизацию...
В целом, присоединяюсь к большинству комментариев на тему "раньше было лучше". Особенно про счётчик непрочитанных комментариев.
Осталось только убрать форму комментариев с самого низа (70 комментариев крутить уже не весело)
На новой версии, статья с несколькими сотнями комментариев, изначально полностью с комментариями прогружается значительно дольше старой. Выделение текста на странице работает шустрее, но так же отжирает ядро.
Хабр стал одностраничным приложением (SPA, Single Page Application)
Интересено, кто и по какой причине принял такое решение?
Ведь основная ценность хабра (его хлеб) - это контент. Да ещё и в самом выгодном формате - текстовом. Основной пользовательский сценарий - это чтение. Основная фича - это индексация этого контента (включая комментарии) для потомков.
Вместо того чтобы сделать серверную пагинацию комментариев (как на старых форумах да) и сохранить классические удобные паттерны взаимодействия с браузером - вы перевели проект на spa, наворотили костылей стриминг-рендеринги и прочие "фичи". Положа руку на сердце - попахивает разводом бизнеса на деньги. Хотя если цель была освоить бюджет, и сделать себя незаменимыми - то тогда отлично)
SPA - это про приложения.. там где богатый пользовательский интерактив.. онлайн-фотошопы, онлайн-эксели, игры, личные кабинеты, многошаговые формы-визарды, админки, и т.д.
" с возможностью показать все комментарии по клику на кнопку."
О!, уже почти пагинация..)
Пагинация хорошо работает для плоских списков, но комментарии Хабра это деревья с большой вложенностью. Не очень представляю как такую структуру можно пагинировать. Буду благодарен если покажите примеры такой пагинации.
Жж. Пагинация, дерево, тыщщи комментариев.
Но в целом xenforo удобнее по пользовательскому опыту
Хранить плоский индекс дерева
<section>
<article>
<div class="indent_l-1">
[Комментарий 1]
</div>
</article>
<div class="children">
<section>...</section>
<section>...</section>
<section>
<article>
<div class="indent_l-2">
[Комментарий 4]
</div>
</article>
<div class="children">
<section>...</section>
<section>...</section>
<section>
<article>
<div class="indent_l-3">
[Комментарий 7]
</div>
</article>
<div class="children">
<section>...</section>
<section>...</section>
<section>...</section>
</div>
</section>
</div>
</section>
</div>
</section>
Вместо того, чтобы выглядеть вот так:
<section class="indent_l-1">
<article>
<div>
[Комментарий 1]
</div>
</article>
</section>
<section class="indent_l-2">...</section>
<section class="indent_l-2">...</section>
<section class="indent_l-2">
<article>
<div>
[Комментарий 4]
</div>
</article>
</section>
<section class="indent_l-3">...</section>
<section class="indent_l-3">...</section>
<section class="indent_l-3">
<article>
<div>
[Комментарий 7]
</div>
</article>
</section>
<section class="indent_l-4">...</section>
<section class="indent_l-4">...</section>
<section class="indent_l-4">...</section>
В итоге если дочерних комментов под каким-то комментом штук 100, браузер не может ничего отрисовать пока не загрузит и не определит размеры всех вложенных комментов. У каждого из которых такая же структура. Плоский список отрисовывался бы гораздо быстрее. Вложенность тут ну вот совершенно ни к чему, все взаимосвязи можно отслеживать через JS и атрибуты level/id/parent_id.
Мы делали замеры и сравнивали разметку в виде дерева, и виде плоского списка. По производительности никакой разницы мы не отметили. Вывод о том что пока не загрузились дочерние комментарии браузер не может отрендерить родителя неверен, иначе бы у нас не работал стриминг. В то же время у плоского списка есть недостатоки: данные нужно постоянно нормализовывать, а для работы сворачивания нужно будет перерисовывать вообще все комментарии, чего очень хотелось бы избежать (об этом рассказано в секции про функциональные компоненты).
По производительности никакой разницы мы не отметили
Проверил в Chrome. По времени разницы действительно нет, по памяти вроде как с деревом в 2 раза больше.
Но список в обоих случаях рендерится за 1-2 секунды (используется просто запись в innerHTML), значит замедление в десятки секунд дает Vue. Может напишете статью, где расскажете, что и как меряли, покажете примеры кода? Было бы интересно почитать.
(function () {
$('.tm-comments-wrapper__inner').innerHTML = '';
$('.tm-comments-wrapper__inner').setAttribute('elementtiming', 'comment-list');
$('.tm-height-limiter__expand')?.remove();
let selector = $;
setTimeout(function () { render(selector); }, 3000);
async function render($) {
let articleId = window.location.href.split('/')[7];
console.log('request start');
let commentList = await fetch('/kek/v2/articles/' + articleId + '/comments/split/guest?fl=ru&hl=ru').then(response => response.json());
console.log('request stop');
$('.tm-comments-wrapper__comments-count').innerText = commentList.commentIds.length;
let t1 = performance.now();
let m1 = window?.performance?.memory?.usedJSHeapSize ?? 0;
let html = renderTreeComments(commentList);
// let html = renderFlatComments(commentList);
let t2 = performance.now();
let m2 = window?.performance?.memory?.usedJSHeapSize ?? 0;
console.log('generate html', (t2 - t1).toFixed(2), 'memory', m2 - m1);
let resizeObserver = new ResizeObserver(function (entries) {
let t3 = performance.now();
let m3 = window?.performance?.memory?.usedJSHeapSize ?? 0;
console.log('render time', (t3 - t2).toFixed(2), 'memory', m3 - m2);
this.unobserve(entries[0].target);
});
resizeObserver.observe($('.tm-comments-wrapper__inner'));
$('.tm-comments-wrapper__inner').innerHTML = html;
}
function renderTreeComments(commentList)
{
return commentList.threads.map(id => renderComment(commentList.commentRefs[id], commentList.commentRefs)).join('\n');
}
function renderFlatComments(commentList)
{
return commentList.commentIds.map(id => renderCommentBody(commentList.commentRefs[id])).join('\n');
}
function renderComment(comment, commentRefs)
{
let innerHtml = comment.children.map(id => renderComment(commentRefs[id], commentRefs)).join('\n');
let html = `
<section class="tm-comment-thread">
${ renderCommentBody(comment) }
<div class="tm-comment-thread__children" style="display:;">
${ innerHtml }
</div>
</section>
`;
return html;
}
function renderCommentBody(comment)
{
let html = `
<article class="tm-comment-thread__comment">
<a name="comment_${ comment.id }" class="tm-comment-thread__target"></a>
<button class="tm-comment-thread__breadcrumbs tm-comment-thread__indent_b_l-${ comment.level <= 10 ? comment.level : '10' }">
<div class="tm-comment-thread__circle"></div>
</button>
<div data-comment-body="${ comment.id }" class="tm-comment-thread__indent_l-${ comment.level <= 10 ? comment.level : '10' }">
<div data-gallery-root="" class="tm-comment">
<header data-comment-header="" tabindex="-1" class="tm-comment__header">
<div class="tm-comment__header-inner">
<span class="tm-user-info tm-comment__user-info">
<a href="/ru/users/${ comment.author?.alias }/" title="${ comment.author?.alias }" class="tm-user-info__userpic">
<div class="tm-entity-image">
<svg height="24" width="24" class="tm-svg-img tm-image-placeholder tm-image-placeholder_blue">
<use xlink:href="/img/megazord-v24.4a410f80.svg#placeholder-user"></use>
</svg>
</div>
</a>
<span class="tm-user-info__user">
<a href="/ru/users/${ comment.author?.alias }/" class="tm-user-info__username">${ comment.author?.alias }</a>
<a href="#comment_${ comment.id }" class="tm-comment-thread__comment-link">${ comment.timePublished?.replace('T', ' ')?.replace('+00:00', '') }</a>
</span>
</span>
</div>
<div class="tm-comment__buttons"></div>
</header>
<div class="tm-comment__body-content tm-comment__body-content_v2">${ comment.message }</div>
</div>
<div class="tm-comment-footer">
<div class="tm-votes-meter tm-comment-footer__votes-meter">
<svg height="24" width="24" class="tm-svg-img tm-votes-meter__icon tm-votes-meter__icon_appearance-comment">
<title>Всего голосов ${ comment.votesCount }: ↑${ (comment.votesCount + comment.score)/2 } и ↓${ (comment.votesCount - comment.score)/2 }</title>
<use xlink:href="/img/megazord-v24.4a410f80.svg#counter-rating"></use>
</svg>
<span title="Всего голосов 4: ↑${ (comment.votesCount + comment.score)/2 } и ↓${ (comment.votesCount - comment.score)/2 }" class="tm-votes-meter__value tm-votes-meter__value${ comment.score > 0 ? '_positive' : (comment.score < 0 ? '_negative' : '') } tm-votes-meter__value_appearance-comment tm-votes-meter__value_rating">${ (comment.score > 0 ? '+' : (comment.score < 0 ? '-' : '')) + comment.score }</span>
</div>
<button type="button" class="tm-comment-thread__button">Ответить</button>
<button title="Добавить в закладки" type="button" class="bookmarks-button tm-comment-footer__button tm-comment-footer__button_with-icon">
<span title="Добавить в закладки" class="tm-svg-icon__wrapper bookmarks-button__icon">
<svg height="24" width="24" class="tm-svg-img tm-svg-icon">
<title>Добавить в закладки</title>
<use xlink:href="/img/megazord-v24.4a410f80.svg#counter-favorite"></use>
</svg>
</span>
</button>
<button data-comment-popup="${ comment.id }" class="tm-comment__button tm-comment__button_with-icon">
<svg height="16" width="16" class="tm-svg-img tm-comment__icon tm-comment__icon_dots">
<title>Ещё</title>
<use xlink:href="/img/megazord-v24.4a410f80.svg#dots"></use>
</svg>
</button>
</div>
</div>
</article>
`;
return html;
}
})();Ленивая загрузка на мой вкус - бич хабра. Взаимодействие с этим сайтом неторопливое, отложенное. Загрузил 2-3 вкладки, спустился в метро, и 30 минут читаешь. Вместо этого ни картинок, ни комментариев.
Я потому приложением не пользовался, что невозможно там обеспечить самый удобный вариант взаимодействия - пооткрывать во вкладках статьи и в течение недели их из этой очереди поглощать.
Что касается самих комментариев - радует, что они хотя бы стали загружаться. Но вообще уже столько было хороших некривых реализаций на несколько голов выше оригинала, что хочется чтоб уже наконец дали сторонним разработчикам API для логина и рейтинга, и не заставляли есть кактус.
Мне не нравится, что оно тормозит на мобильниках, загружается либо лениво, либо никак. И судя по всему, как тут уже несколько раз сказали, это не проблема механизма рендера, а проблема огромного DOM.
Мне не нравится, что для комментирования надо прокрутить ленту в конец
Что кэш работает очень странно. Я не очень много сайтов посещаю с мобильника, но пока что хабр - единственный, который тратит время и на повторную загрузку, и на то, чтобы после нее ещё раз обновить страницу, потому что на ней лента недельной давности.
Ещё в режиме энергосбережения есть такая байда, что при блокировки экрана чистится кэш браузера. И при разблокировке он загружается заново. В этом случае можно не рассчитывать найти окно просмотра на том же месте, где остановился. А комментарии, если их больше пары десятков - уже листать не могу.
Казалось бы, это, наверное страшные неразрешимые проблемы, которые задают дихотомию: или сайт грузится, или ленив.
Но нет, форумы xenforo лишены всех этих проблем! Отличный редактор, шустрая мобильная версия, якоря всегда на месте.
Давайте вы перенесете бд хабра на движок xenforo? Всем станет хорошо 😉
А можно ещё вернуть работающий редактор комментариев, который не будет дропать несколько параграфов текста в комментарии при переходе между этими самыми параграфами тапом? Или последний мобильный фф теперь тоже не поддерживается из-за малой аудитории?
То сидишь набираешь на мобильнике комментарий, вставляешь цитаты, а тут хабр решает что ты не этого хотел и десять минут идут в /dev/null
Прислали мне тут сообщение об опечатке, открываю редактор и 3 минуты наблюдаю такую картину..
Таки стоит порадоваться что не удалилось 2/3 статьи при скролле или случайном клике. И сохранилось (автосохранение же удобно, да).
Ну я нарвался в редакторе комментариев, когда он где-то протерял стейт при скролле и удалил всё при выборе параграфа. Веткой выше ругался.
Кто сказал что в редакторе статьи не влетишь на подобную штуку ткнув в один из параграфов пока стейт ещё где-то не доехал? С виду редактор тот же. Автосохранение в редакторе статей когда-то было, iirc.
Привет. Спасибо за демонстрацию, разберёмся. Единственное - не получилось воспроизвести все наблюдаемые на видео ошибки, не могли бы вы уточнить версии ОС и браузера?
На видео же нет ошибок, только тормоза.
'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36'
Не работает просто автокомплит. Пока не напишешь полностью тег, только тогда по полному совпадению он появляется в автокомплите. Плюс выпадающий список автокомплита находится по z-index под некоторыми элементами формы редактирования.
Не тот сервис назвали «Дзен»... Я залип, на эти две с копейками минуты.
Толку от этого SPA? В основном же люди читают статью, а переключаются редко между статьями. Разве новые статьи большинство не в новых вкладках открывает?
Что на ПК (https://linux-hardware.org/?probe=fd350b52da, Chromium/Firefox), что на смартфоне (Fennec F-Droid) комментарии работают тормознуто. Например, сейчас ПК немного нагружен, например, открытым дико тормозным vk.com, несколько секунд ждал прогрузки комментариев, когда докрутил до них. FPS в форме комментария, в которую пишу прямо сейчас, низкий. Раньше такой фигни не было, работало быстро, ыбло приятно пользоваться, теперь - нет, отвратительно даже.
Как мы ускоряли комментарии Хабра
...
Вы когда-нибудь открывали в старом дизайне Хабра пост с большим числом комментариев? Страничка даже с тысячей сообщений грузится шустро, на ней без серьёзных задержек работает форма для ответа, кнопки голосования и закладок. Но когда мы начали переход на новую версию Хабра, стало понятно, что добиться такой же скорости будет непросто.
То есть вы их не ускоряли. Они и так работали быстро, без задержек и без проблем. Потому вы все это сломали, а потом героически боролись с проблемами, которые сами себе создали. И, судя по комментариям к этой статье, поломали и до сих пор не починили базовый функционал.
Этому есть несколько причин. Во-первых, Хабр стал одностраничным приложением (SPA, Single Page Application) на Vue, то есть теперь переходы между страницами рисуются на клиенте с помощью JS вместо классического серверного рендеринга (Server-Side Rendering, SSR).
...
серверный рендеринг — операция дорогая.
авигация по сайту в режиме SPA (без перезагрузки страницы) оставляла желать лучшего. Если у вас медленный смартфон, то вы имели шанс вообще не увидеть комментарии: память кончалась быстрее, чем успевали отработать скрипты и рендеринг.
Ну то есть когда оно было в SSR в старой версии, все работало густро, без задержек и т.п. Придумали себе «модномолодежно» Vue, и перестало работать всё. Почему вы этим гордитесь и еще целые статьи выкатываете про это?
Наша задача подразумевала максимальные улучшения ценой минимальных усилий.
...
Чтобы создать ощущение, что комментарии рисуются быстрее, с определённого порога нужно переключаться на исключительно серверный рендеринг.
всю разметку с сервера необходимо «гидрировать» на клиенте, иными словами ... ленивая гидрация
Предотвращение избыточной перерисовки
Ленивый рендеринг
[только для Хрома] Content Visibility
стриминг-рендеринг... проблему мы решили путём долгого и скрупулёзного изучения исходников Vue... Внедрение стриминг-рендера для комментариев не прошло безболезненно..
Странное у вас понимание «минимальных усилий» для того, чтобы оно хоть как-то было похоже по работе на то, что у вас уже было.
Поэтому при переходе на новую версию сайта было важно сделать работу с комментами не хуже, чем было.
В итоге:
счечик не работает
открытые в нескольих табах страницы не грузят контент
accessibility сломан
используются экспериментальные фичи, которые работают только в хроме, на остальных пользователей насрать
<вписать свое>
Зато 13 человек полгода пилили модно-молодёжно.
А можно вопрос?
А зачем нужно рисовать в html пользователю сразу все over9000 комментариев и ждать от браузера что он быстро все отрисует?
Вы не костыль убрали/заменили/модифицировали, а просто взяли молоток потяжелее и еще прочнее вбили винтовую сваю :)
Вместо того чтобы использовать virtual list, вы взяли lazy hydration, который придуман для другого.
Lazy hydration нужен чтобы легкие оптимизированные страницы грузились еще быстрее.
Для поисковых систем не важно сколько страниц с гет параметрами они проиндексируют. Разбейте комменты на чанки с гет параметрами, а при помощи SPA предоставьте пользователю бесконечный скролл по комментам.
Не забивайте отверткой гвозди и все вам спасибо скажут
Если я правильно поняла, вы рендерите всё подряд с учётом прокрутки. То есть, с одной стороны, у камента есть место в логическом дереве, с другой - в лейауте. И рендеринг вы связали больше как раз с лейаутом (а место в дереве даёт только стилевой класс для сдвига вправо).
Давайте обсудим это решение как таковое?
Т.е., при выборе "грузим в рамках прокрутки / по уровням дерева" выбор варианта с прокруткой, он наилучший ли?
Загрузку "по уровням дерева" я бы видела так.
Начну с описания комментариев под этой статьёй. Давайте закроем все ветки, посмотрим, где чего сколько. Сейчас мы видим одну ветку на 27 комментариев, одну на 24 и две ветки по 15 комментариев. Ещё есть одна на 8 и одна на 7 комментариев. Остальное - веточки по 1-2-3 комментария (именно до трёх включительно).
Подозреваю, что так оно примерно везде на хабре - есть размытое облако веток по 1-2-3 камента, и есть длинные ветки, которых самих немного, но в них сосредоточена треть / половина и более всей массы каментов. Возможно, нужное среднее по каждому посту стоит считать отдельно. Что для очередного поста считать "короткими ветками", а что - "длинными".
Для поисковых ботов я сделала бы отдельные страницы, типа "статья + длинная ветка каментов, одна штука + ссылка на основную страницу статьи". А "основную страницу статьи" я пилила бы в два этапа. Первым этапом грузила бы ветки от одного до трёх каментов ("три" тут пока от балды, просто "мелкий ограничитель сверху"), а более длинные ветки грузила бы в виде "первый камент ветки + картинка про то, что тут есть ещё, что читать". Под этой картинкой бы фоном бы запускала, скажем, догрузку джейсона конкретно под эту ветку, допустим async mounted().
Это отдельное обращение к серверу - тут бы их в данный момент было 6 (для веток в 7,8,15,15,24 и 27 комментариев, см. выше). Подозреваю, что редко где это было бы сильно выше. Ну то есть не сто явно - вряд ли есть пост, где сразу сто длинных веток. Или, опять же, эти конкретные полтора поста за всю историю хабра - когда кому-то не лень их читать - у них именно сотня длинных веток. Но в целом их вряд ли сто уников в секунду грузят в течение года. Хотя такое можно использовать для дедоса, ну... ну тогда с этими надо отдельно. Собственно, в вашем нынешнем решении тоже есть некий водораздел по числу комментариев.
Итак, длинные ветки мы грузим фоном, и прячем их под картинки "тут есть ещё что читать". Юзеру не составит труда тычком раскрыть эти длинные ветки, поскольку их мало. При этом автозагрузка таких веток в фоне отдельными несколькими запросами успеет обеспечить их полную загрузку для чтения в метро (см. тут выше пользовательский сценарий "открыть пять страниц на входе в метро в надежде прочесть их оффлайн в вагоне").
Добавлю, что у меня основной пользовательский сценарий на хабре - чтение дома с компьютера, и неплохой компьютер. Но я сейчас попробовала посмотреть ещё, как дела на странице https://habr.com/ru/company/habr/blog/595067/ (выбрала потому, что там сейчас каментов 400 без малого - хотела сравнить, как там с распределением по веткам - примерно так же), и на компьютер мой четырёхъядерный, хоть и не дорогой, крутилка зарузки наверху вкладки крутилась минуту, наверное. Точно я время не засекала, просто по ощущениям "она долго крутилась".
Короче говоря, мне кажется, тут бы должны быть три (да, три) разных шага:
запуск загрузки тела статьи при переходе по ссылке,
запуск загрузки джейсона каментов по async mounted() сама статья, этот джейсон причём ветки короткие содержит полностью, а ветки длинные содержит в виде "начало ветки + указание, что есть ещё, что грузить",
запуск загрузки джейсонов длинных веток по async mounted() начальных комментов веток, в которых указано "есть ещё, что грузить".
Да, ну и "число добавившихся сообщений" на этих ветках стоит отдельно указывать тоже, поветочно. Новые можно до кучи подсвечивать.
ЗЫ про некоторые технологии узнала из вашей статьи, и я не ставлю их под вопрос сами по себе - мой комментарий о том, насколько они показаны в данном случае. Я интересуюсь лишь тем, нельзя ли использовать особенности структуры местных деревьев для разбивки загрузки на части, способные выполняться фоном, и не менять при этом лейаут.
Как мы ускоряли комментарии Хабра