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

Пришел к такому выводу:

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

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

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

Так вот. Например кто-то наконец решился и пишет пост о том, что в компании Рога и Копыта применили технологию XYZ, которая сейчас не самая популярная, но дает экономию и скорость производства фич. В этот момент пост и автор начинают уходить в минус, его комменты тоже минусуют, часто его закидывают фразами типа: к вам никто работать не придет, почему не применили современное ПО и т.п. Но почему я ни разу не видел вопросы про расчет экономики внедрения и пр.? Видимо просто прогеры защищают свои интересы и никого не слушают Но нам с вами бабосики платят не за код, а за решение проблем бизнеса и если пишется пост о том, что ускорили в 10 раз выпуск фич и интерфейс, то это же круто! Учитесь, меняйте мировоззрение, вдруг это то, что и вам надо. И какая разница, что там например хранимые в БД? Или, о ужас! Нет ORM и все написали на галимых, но быстрых sql запросах, которые вам не нравятся просто потому, что вы их не понимаете как не понимаете еще многое, но сейчас же принято sql ругать. Видимо обидно просто, что не посоветовались с вами?

Короче, я к чему люди не должны бояться высказывать свое мнение про бизнес на Хабре. В комментах очень много желчи, это не очень-то достойно такого правильного ресурса как Хабр. Нормальных постов тут просто не будет (будут на медиуме или еще где) или будут под копирку по линии партии типа прогер должен учиться за счет работодателя, прогер должен иметь рабочее время на саморазвитие, прогрею должен иметь большую ЗП. Ну камон, это же просто смешно! (кроме последнего, конечно)

Биореактор

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

Всё изменилось в тот день, когда задница в красном белье вышла на главную. Тут многие подозревали, что мы планировали продавать изделие Гель thermo intensive через Хабр. Сразу скажу, что это попахивает идиотизмом, потому что нужен он девушкам, а на Хабре их очень и очень мало, судя по статистике (14 % мальчиков, 1 % девочек и 83 % репликантов).

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

И тут ПОНЕСЛОСЬ! Через час после начала публикации заказы начали сыпаться нон-стопом. Отмечу, что через час: это потому, что ровно за этот час вы зачем-то разобрали всё то, что было на Озоне и на Вайлдберриз со скидкой. За 20 минут заказов пришло больше, чем наш товарный остаток.

Делов-то, можно же пойти и сварить ещё партию. Просто надо подвинуть график загрузки реакторов! Оказалось, что сырья, точнее, одного из компонентов, у нас тоже не было.



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

Поэтому к тому, что мужикам с Хабра может понадобиться антицеллюлитное средство, никто не был готов в принципе. До этого мы рассказывали про такую же запускающуюся Интенсив-регенерацию очень наукоёмкую разработку, и тогда никакого вала заказов не было.

Добавьте, что это середина ковида и весь отдел продаж сидит по домам.

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

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

Отдел продаж утром начал биться в истерике. В каждом заказе, кроме нашего изделия со столь попавшим в тему проектным названием, было что-то ещё. Было обидно терять столько прибыли, просто уходящей из рук. Они начали составлять очередь, чтобы отправить сразу, как только флаконы появятся. Мы же с производством начали выяснять, когда они появятся. Следующая партия планировалась через два месяца, поставку действительно можно было ускорить, графики загрузки реакторов поменять, и через неделю мы всё же начали отправлять новые флаконы.

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

В общем, когда флаконы всё же уехали, нам стало поспокойнее, мы были готовы вернуться в свой уютный мирок термошкафов и продолжить менять линию водоподготовки, как давно хотели.

И тут флаконы доехали.

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



Щель на дне флакона беспокоила людей. Нам писали, что это брак. Нам жаловались. Беспокоились, что продукция внутри испортилась. А это не брак. Потому что одна из самых сложных вещей с флаконами как сделать так, чтобы всё из флакона вытекло наружу. Это флакон объёмом 500 мл, и стоит он 2 378 рублей с акцией Озона. Хочется вытрясти не на 2 100, а именно на 2 3752 378. В крайнем случае, на 2 360. То, что часть немного размажется по стенке, ещё справедливо, а вот то, что часть застрянет внизу, уже нет. Нужно было дешёвое средство достать всё и сразу.

Как обычно, мы подумали, нельзя ли решить эту задачу химически. И нашли совершенно дешёвый и прекрасный способ! Просто заказали флаконы и попросили положить на дно мешочек с гелем. Как вы знаете, главное в геле это каркас. Гель умеет распрямляться и занимать куда больше места, чем одна из компактных форм. Мешочек расправляется, но ему для этого нужны воздух и некоторая влажность. Благодаря этому на дне ничего не остаётся. Но нам нужен воздухозабор. Тоже дешёвый. Собственно, отсюда это технологическое отверстие внизу.

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

Прошло достаточно времени с того поста, чтобы мы узнали ещё кое-что о Хабре. В смысле мы до сих пор не знаем, зачем вам столько флаконов и что вы с ними сделали. Но нам пошли отзывы на Озоне и Вайлдберриз: Читаем вас на Хабре, а когда мы искали нового специалиста, то в сопроводительных письмах к резюме прямо указывали, что читали наш блог тут.




Собственно, наука, считавшая всё это баловством, прочитала комментарии ну так, посмеяться. И внезапно увидели вопрос про то, можно ли мазать на живот, чтобы убрать жир. И тут у них в глазах появился странный блеск. Дело не в животе, а в том, что есть другое место, где нужно убирать похожие формации, второй подбородок. Там рядом щитовидка (у мужчин она закрыта кадыком, у женщин прямо рядом), поэтому не стоит увлекаться эфирами в формуле. Сейчас идёт обкатка средства для лица. Мы уже стабилизировали несколько формул и скоро заходим на альфа-этап.

Здравствуйте, меня зовут Дмитрий Карловский и я тот ещё токсичный перец. Недавно я источал свои альфа-флюиды на Альфа-банк. Ребята в ответ поступили достойно, и не стали атаковать меня в личку объяснениями, как сильно я не прав, а завели задачу на гитхабе. И даже что-то пофиксили, сделав часть моих претензий несостоятельными. Но не ту часть, где SSR портит всё.

Время утекло, пыль улеглась, и тут история получает продолжение: недавно ко мне обратился продюсер контент-студии Хабра с предложением пропесочить их Торт. Что ж, расчехляем вентилятор!

Сложный случай

Возьмём, например, вот эту страницу, содержащую 2500 комментариев. Это настолько огромная страница, что если вы откроете её в Хроме, то он обрежет её уже на 1400 комментарии. Чтобы прочитать оставшиеся вам придётся открыть её, например, в Огнелисе. Причину этого оставим на совести разработчиков. Давайте лучше подумаем как этого не допустить. Но сперва проведём замеры:

Методика измерений

• Размер данных объём HTML или JSON выдачи. Показывается в девтулзах Хрома, если включить "широкие строки". Вес указан лишь того ресурса, что выдаёт комментарии.
• Размер сжатых данных то, что девтулзы показывают по умолчанию для загруженных ресурсов.
• Время полной загрузки время открытия всех комментариев (да, иногда Хром всё же рендерит всё не понятно от чего зависит), обычным секундомером на глазок от нажатия F5 (или ссылки "показать комментарии") до завершения всех видимых пользователю загрузок. Кеш отключался через девтулзы.
• Время показа первого экрана то же, что и время полной загрузки, но дожидаясь лишь появления контента, заполняющего весь экран, что позволяет начать его читать.
• Число DOM элементов выводился document.getElementsByTagName('*').length в режиме наблюдения, приведено максимально наблюдаемое число.
• Отзывчивость при прокрутке длительность блокировки основного потока при скроллинге на одну страницу. Замерялось через профайлер.
• Пересчёт лейаута длительность блокировки основного потока при однократном изменении размера окна. Замерялось через профайлер.
• Потребление памяти объём, который показывают девтулзы для основного потока, после полной загрузки и ручного запуска сборки мусора.

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

Предварительный анализ

У Хабра есть две версии: десктопная и мобильная. Десктопная загружает статью со всеми комментариями единым HTML. Мобильная же поступает хитрее: сначала загружается статья в виде HTML, а по клику на кнопку "комментарии" она подгружает JSON с комментариями и рендерит их с помощью VueJS вместо статьи. Но если на комментарии зайти по прямой ссылке, то будет загружен пререндеренный HTML. Пререндеренный HTML ничем принципиально не отличается от десктопной версии, поэтому я замерял именно вариант с динамическим рендером, который отрабатывает в большинстве реальных сценариев использования.

Как видно, вес JSON примерно в 4 раза меньше HTML. В формате Tree эти данные весили бы ещё меньше, но парсились бы дольше, ибо кастомный парсер на яваскрипте даже более простого формата всё же медленнее нативного JSON парсера. В любом случае, после сжатия, которое применяется сейчас повсеместно, разница уже не столь существенна порядка 30%.

Пререндеренный HTML довольно долго грузится, это связано с двумя факторами:

1. Параллельно начинают грузиться все изображения со страницы, а это 8 мегабайт несжимаемого трафика, который капитально забивает канал. Решить эту проблему могли бы через loading="lazy", но не стали.
2. После загрузки очередного куска HTML происходит его подклейка в общее дерево, что вызывает повторное вычисление стилей, лейаута и рендеринга. Так как стоимость этого процесса растёт по мере роста DOM, то зависимость суммарной задержки загрузки от размера HTML тут экспоненциальная. Решается только одним способом уменьшением HTML.

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

Кроме того, использование VueJS даёт довольно серьёзное пенальти по памяти оно увеличивается более чем в 25 раз.

Всего на страницу выводится около 100K DOM элементов. Это в среднем около 40 элементов на каждый комментарий.

Браузеру становится очень плохо от такого большого DOM дерева и он начинает серьёзно тупить. Например, обновление экрана при скроллинге, не смотря на его аппаратное ускорение, занимает 700мс. И это чисто скроллинг, без пересчёта лейаута. С ним же почти 2 секунды. А пересчитывается лейаут почти на любое изменение DOM дерева. DevTools тоже порой сходят с ума, что осложняет профилирование.

Выбор стратегии

Основная причина тормозов размер DOM дерева. Поэтому требуется такая реализация, которая позволит иметь на пару порядков меньшее число элементов на странице. Выпишем возможные стратегии:

Выводы:

1. Виртуализация меньше всего расстроит пользователей.
2. Так как единовременно отображаются не все комментарии, придётся вручную реализовать поиск по всем комментариям.

Прототипирование

Самый простой способ воспользоваться виртуальным рендерингом переписать страницу на $mol, что позволит нам писать код даже не думая о виртуализации, но всё равно её получить, так как в $mol она встроена под капотом.

Хабр возвращает статью и комментарии в виде JSON. Давайте опишем его схему, чтобы тайпскрипт давал нам подсказки и тайпчек, а рантайм проверял, что выдача сервера соответствует ожидаемой. Для этого мы воспользуемся семейством функций $mol_data:

const Person = Rec({    id: Int,    login: Str,    avatar: Str,})const Comment =  Rec({    id: Int,    author: Maybe( Person ),    children: List( Int ),    message: Str,    timePublished: Maybe( Moment ),})const Comments_response = Rec({    comments: Dict( Comment ),    threads: List( Int ),})const Article = Rec({    titleHtml: Str,    textHtml: Str,})

Некоторые поля опциональны в них возвращается null для сообщений, оставленных НЛО.

Теперь мы можем легко загрузить данные, проверить их и вернуть типизированную структуру. Например, так выглядит загрузка комментариев:

@ $mol_memcomments_data() {    const uri = `https://m.habr.com/kek/v2/articles/${ this.article_id() }/comments/`    const data = Comments_response( this.$.$mol_fetch.json( uri ) )    return data}

Хорошо, данные мы загрузили, осталось их показать. Текст статей и комментариев Хабр возвращает в виде строки, содержащей довольно разношёрстный HTML. Для его отображения воспользуемся компонентом $mol_html_view:

<= Article $mol_html_view    html <= article_content \    highlight <= search    image_uri!node <= image_uri!node \

(Если вы не знакомы с синтаксисом view.tree, предназначенным для декларативной композиции компонент, то можете ознакомиться с кратким или полным его описанием.)

Этот компонент берёт HTML, парсит его и для каждого элемента создаёт соответствующий $mol_view компонент, а он уже сам себя виртуализирует. Кроме того, $mol_html_view позволяет указать строку, которая будет подсвечена в тексте.

Также нам потребовалось перегрузить метод image_uri, который вызывается для каждого IMG элемента, чтобы получить ссылку на картинку. Причина в том, что в атрибуте src в выдаче Хабра изначально находится лишь ссылка на заглушку, а реальная ссылка на изображение берётся из атрибута data-src. Поэтому реализуем этот метод так:

image_uri( node : HTMLImageElement ) {    return node.dataset.src || node.src || 'about:blank'}

Рендеринг дерева комментариев не представляет из себя ничего особенного. Разве что мы добавим возможность сворачивать/разворачивать ветки комментариев.

@ $mol_mem_keycomments_visible( id : number ) : readonly number[] {    if( this.comment_expanded( id ) ) {        return this.comments_all( id )    } else {        return this.comments_filtered( id )    }}

Эта функциональность полезна и сама по себе, но нам она ещё пригодится и для поиска. Дело в том, что $mol пока ещё не умеет прокручивать сролл к заданному компоненту. Штука эта вполне реализуема, но у меня руки пока не дошли, так что если если кто-то возьмётся за это дело было бы супер.

А сейчас, мы, вместо прокрутки страницы между найденными постами, будем сворачивать все ветки комментариев, где искомая подстрока в тексте не встречается. Таким образом пользователь может ввести запрос и просто скроллить страницу. А при желании развернуть ветку и почитать все ответы. Выглядит это примерно так:

Многие пользователи привыкли к хоткею Ctrl+F для поиска по странице, поэтому добавим плагин $mol_hotkey для его перехвата:

plugins /    <= Search_key $mol_hotkey        mod_ctrl true        key * F?event <=> search_focus?event null    <= Theme $mol_theme_auto

Ну а для фокусирования просто доберёмся до нужного нам компонента и скажем ему сфокусироваться:

search_focus( event : Event ) {    this.Search().Suggest().Filter().focused( true )    event.preventDefault()}

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

Кроме того, добавим пользователю возможность вручную менять тему, разместив на тулбаре кнопку $mol_lights_toggle:

tools /    <= Lights $mol_lights_toggle    <= Sources $mol_link_source        uri \https://github.com/nin-jin/habrcomment    <= Search $mol_search        query?val <=> search?val \

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

Наведём немного красоты, переопределив некоторые дефолтные стили, используя модуль $mol_style, который обеспечивает тайпчек и подсказки, учитывающие реальную иерархию компонент:

$mol_style_define( $my_habrcomment , {    Orig: {        flex: {            grow: 1,            shrink: 0,            basis: per(50),        },    },    Article: {        maxWidth: rem(60),    },    Comments: {        flex: {            shrink: 0,            grow: 1,        },    },    Comments_empty: {        padding: rem(1.5),    },} )

Последним штрихом добавим поддержку оффлайна:

include \/mol/offline/install

Этим не хитрым кодом мы установили кеширующий Service Worker, который в случае проблем с соединением будет выдавать данные из кеша.

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

Что ж, вот наш прототип читалки хабракомментариев и готов: https://nin-jin.github.io/habrcomment/#article=423889

Держите букмарклет, позволяющий открывать в ней любую тяжёлую статью:

document.location = document.location.href.replace( /\D+/ , 'https://nin-jin.github.io/habrcomment/#article=' )

Анализ прототипа

Код исходников уложился в 400 строк, на написание которых требуется не более пары часов. По функциональности:

• Отображение произвольной статьи с форматированием
• Отображение дерева комментариев к статье с форматированием
• Возможность сворачивать/разворачивать комментарии
• Поиск по статье/комментариям с подсветкой найденного и сворачиванием лишнего
• Работа в оффлайне
• Поддержка тёмной/светлой тем
• Адаптивность к размеру экрана

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

Если пошаманить можно выиграть ещё несколько секунд. Например, в наивной реализации HTML всех комментариев парсится при открытии страницы для расчёта их минимальных размеров исходя из содержимого. Однако, можно руками задать какое-то константное значение, меньше которого текст комментария точно быть не может:

<= Message $mol_html_view    minimal_height 60    highlight <= search \    html <= message \    image_uri!node <= image_uri!node \

Таким образом парсинг HTML будет происходить лишь при фактическом отображении. Позиция скроллбара, конечно, тогда будет рассчитываться несколько менее точно, но это не страшно.

Итого по скорости загрузки: почти десятикратное ускорение полной загрузки при сохранении времени появления контента в 5 секунд.

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

@ $mol_memcomments_data() {    const search = encodeURIComponent( this.search() )    const uri = `https://m.habr.com/kek/v2/articles/${ this.article_id() }/comments/?search=${search}`    const data = Comments_response( this.$.$mol_fetch.json( uri ) )    return data}

Реализована сейчас, разумеется, не вся функциональность. Но всё остальное особой погоды не делает. Чтобы довести до продакшена, надо будет ещё много чего реализовать. Если кто-то готов этим заняться можете попробовать. Правда сперва придётся договориться с руководством Хабра об использовании их API. Я пробовал несколько раз подкатить с разных сторон никакого ответа не получил.

Также можно заметить, что отступы вокруг разных комментариев пляшут как попало это от того, что HTML, отдаваемый Хабром, это какая-то дичь от слова совсем: слова то в параграфах, то в дивах, то параграфов вообще нет, а абзацы разделяются переводами строк или тегом BR, что вообще вырубает виртуализацию. В общем, тут надо либо чтобы Хабр отдавал что-то единообразное и валидное, либо пилить какой-то свой нормализатор выдачи.

$mol_html_view поддерживает сейчас лишь сравнительно небольшой набор HTML-элементов далеко не всё, что может выдавать Хабр. Добавить поддержку остальных в принципе не сложно и она, конечно, будет расширяться по мере необходимости.

Кроме того, есть и технические косяки:

1. Контент при скроллинге иногда скачет это какой-то косяк в логике виртуализации $mol_list. Не приятно, но жить можно. Как-нибудь конечно же починю.
2. В сафари автоматически отключается виртуализация сверху, так как он не поддерживает overflow-anchor, необходимый для того, чтобы можно было менять контент сверху от видимой области без скачков видимого контента. Это означает, что страница будет открываться всё так же быстро, но по мере прокрутки вниз будет дорендеривать всё остальное содержимое, пока не отрендерит все 100K элементов, когда пользователь домотает до самого конца.

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

Резюме

1. SSR не быстрее грамотной реализации PWA.
2. Вместо поддержки двух абы как слепленных реализаций для разных девайсов, лучше потратить это время на одну, но толковую и адаптивную.
3. Выбирая между двух зол, лучше сделать шаг в сторону возможно именно там расположилось добро.
4. VueJS тупит, а $mol рулит.
5. Браузеру становится очень плохо, когда в доме много элементалей.
6. Стоит предпочитать те решения, что не приводят к не контролируемому увеличению числа элементалей в доме.

Ссылки

1. Исходники читалки можете заметить, что кода там всего ничего.
2. Страница фрейморка $mol ужаснитесь сколько всего у нас там есть.
3. Канал с новостями о $mol и MAM подписывайтесь, чтобы быть в курсе всего важного, что с ними происходит.
4. Канал с видео о $mol когда-нибудь тут появятся видео-туториалы.

Что мы делаем после каждого запуска Хабра-АДМ? Правильно! Публикуем пост Хвастовства.
И особенно приятно, что некоторые участники уже получили свои первые подарки. Так поторопимся и мы.

Пост Хвастовства объявляется открытым!

С НАСТУПАЮЩИМ НОВМ 2021 ГОДОМ!

Ваши iCTPEJlOK и kafeman

PS: А если вам кажется, что комментариев пока слишком мало, можете посмотреть, как это было в прошлых сезонах: 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019.

В конце октября, после волны статей от хайповых авторов, я написал небольшое расширение для Хрома которое позволяет прятать нежелательные статьи из ленты. Расширение было встречено очень тепло (+285, 53_000 просмотров и 70+ звезд на гитхаб) и я даже опубликовал его в Chrome Extension Store. Потом был опрос о наиболее желаемой следующей фиче и самой востребованной (129 голосов) оказалась поддержка Firefox. И вот, спустя месяц, расширение опубликовано в Firefox Addons.

Кому интересно по каким граблям пришлось потоптаться, прошу под кат!

Про Firefox

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

Сначала тестовый код не хотел даже загружаться в Firefox из-за неверного формата манифеста. Пришлось гуглить и пробовать несколько раз, причем даже манифест из официального примера работать не захотел. Потом, после того как Firefox вдруг принял файлы, он, естественно, отказался их запускать, потому что "файлы не проверены, подписи не сделаны, работать не буду". В гугле нашелся специальный флаг -xpinstall.signatures.required = false который нужно выставить что бы разрешить загрузку расширений без подписи, но ни в стабильной версии ни в бете он не работает. Помогло только в Nightly.

Потом, поскольку мне нужно использовать хранилище что-бы хранить настройки, Firefox потребовал дать ему id (ставится в "browser_specific_settings":{"gecko": {"id":"{GUID}"}})). На что Chrome тут же заявил, что свойство browser_specific_settings он не знает и выдал предупреждение. Это исправить так и не удалось, но все вроде бы работает.

Следом возникли проблемы со страницей настроек. Если в Firefox она отображалась красиво, то в Chrome в виде отдельного окна. Полечилось с помощью изменения options в манифесте на "options_ui": {"page": "options.html", pen_in_tab": true}

После чего все наконец то запустилось, и я решил, что наконец-то всех победил. Но не тут-то было. Когда вы грузите бандл, Firefox автоматически запускает линтинг кода и если что-то ему не так, отказывает в загрузке для проверки. В моем случае не так было использования свойств классов (что не страшно и легко лечится), а также использование es6 модулей, что, внезапно, лечится гораздо хуже. Сначала я думал свалить все в один файл (благо размер кодовой базы просто смешной), но потом решил "не комильфо" и настроил WebPack для билда (все равно давно хотел посмотреть на 4ый вебпак)

Кстати, несмотря на то что теперь я публикую собранные артефакты, вы все еще можете использовать код как есть, прямо из src папки. Так что все осталось так же прозрачно, как и было. Мне по-прежнему можно не верить и пользоваться простым и понятным кодом из репозитория.

После WebPack-а все пошло почти гладко. Пришлось еще немного помучаться с описанием расширения (Огнелис подхватил мою дефолтную локаль), но это уже были мелочи.

В результате, 20.12.2020 я отправил расширение на ревью (и был 63 в очереди), а уже 21.12.2020 получил письмо счастья о том, что оно одобрено к публикации. Спасибо команде ревьверов за оперативность.

Новый функционал

Кроме публикации в Firefox я решил добавить еще одну фичу о которой тоже просили (ledascho) блокировка хаба по имени. Сейчас нет возможности отписаться от конкретного хаба и новая возможность это устраняет. Эта функциональность позволяет полностью скрыть статью, даже если она принадлежит и другим хабам на которые вы подписаны.

Итого, на сегодняшний день реализована блокировка:

• По нику автора
• По имени компании
• По имени хаба

UI остался прежним, одно поле для всех.

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

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

И немного статистики

Сейчас у расширения 68 :) пользователей и три оценки. Так что мои опасения что расширение может хоть как-нибудь повлиять на сам Хабр и навредить ему оказались полностью беспочвенными. 40 пользователей из России, 11 из Украины, и еще по нескольку из Казахстана, Узбекистана, Чехии, Штатов, Британии и Израиля.

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

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

Ссылки:

• Firefox
• Chrome
• Repo

Всех с наступающими праздниками, и хорошего нового года!
P.S. Спасибо Sharon McCutcheon за КПДВ Mozilla Corporation за их лого