Putout - новый линтер и модификатор кода. Это такой аналог Eslint, со своим видением того, как должен работать линтер. Из особенностей, которые сразу бросаются в глаза: очень сильно размыта грань между линтером и код-модом - есть правила, которые удаляют ненужные код, а есть правила, которые прям проводят рефакторинг (заменяют commonjs на esm). Также для написания своих плагинов предлагается использовать putoutscript - js-совместимый язык для плагинов Инструмент при этом очень модульный, в нем выделяются: движки, плагины, процессоры, операторы, форматтеры. Их очень много и все они поставляютя как разные пакеты. В общем, проект очень хорошо структурирован и декомпозирован. Также отдельный респект за документацию: Readme проекта очень хорош

Команда Google Chrome представила новое API для анимаций на основе скрола. Один из самых популярных юзкейсов для таких анимаций - шакала прогресса чтения статьи в шапке сайта. Обычно это делается с помощью JS и у этого подхода есть очевидные минусы: JS нужно исполнять в главном потоке, что может привести к проблемам с производительностью. Команда Google Chrome добавила API, которое позволяет реализовать тоже самое на CSS. ``` @keyframes grow-progress { from { transform: scaleX(0); } to { transform: scaleX(1); } } #progress { animation: grow-progress auto linear forwards; animation-timeline: scroll(block root); } ``` Тут конечно же встает вопрос "а что если мне нужна кастомная логика?". Команда Google Chrome это предусмотрела и дает API на JS ``` const progressbar = document.querySelector('#progress'); progressbar.style.transformOrigin = '0% 50%'; progressbar.animate( { transform: ['scaleX(0)', 'scaleX(1)'], }, { fill: 'forwards', timeline: new ScrollTimeline({ source: document.documentElement, }), } ); ``` Не уверен правда, что это API настолько же гибкое, как и возможности подписки на `scroll`. Но вообще добавление такого API в CSS позволяет декларативно и просто описывать разные интересные приколдесы.

Вышел prettier 3.0 Что нового: - Во первых, теперь висящая запятая по умолчанию будет ставится везде. Но можно сконфигурировать это поведение. - Сделаны дополнительные правила форматирования кода. Всякие странные edge кейсы типа 10 `??` к ряду и просто устранение разного форматирования в похожих кейсах. - часть API prettier стало асинхронным. Получается нужно, чтобы плагины к IDE и другим тулам научились работать с асинхронным API

Сайт показывает через сниппеты кода, как основные сценарии реализованы в различных фреймворках. Особо ничего полезного, но выглядит интересно

Driver.js - библиотека для создания ознакомительных онбордингов для пользователей сайта. Позволяет с помощью небольшого конфига создать анимированный тур по сайту с подсветкой элементов и показом объясняющего материала к этим элементам

Статья описывает архитектурный паттерн headless component. Headless Component - это когда мы реализуем логику компонента отдельно от верстки. Это позволяет разделять логику от вёрстки (SRP) и переиспользовать логику или вёрстку независимо друг от друга. В статье это разобрано на очень странном примере (есть 2 компонента: переключатель и раскрываемый контент, и их общая логика (буквально управление bool'ом) выносится в отдельный хук). Но, с другой стороны, приведены примеры библиотек, следующих концепции headless component и хорошо описаны плюсы и минусы подхода. Плюсы: - Позволяет переиспользовать логику отдельно от вёрстки (верно и обратное) - Разделение ответственности. Которое ведет к большей гибкости - Тестируемость логики и вёрстки Минусы: - Есть оверхед в начале т.к. надо заняться явным разделением логики и вёрстки (а это не всегда так просто как кажется на первый взгляд) - Разработчикам необходимо научиться применять паттерн - Приведет к усложнению в коде, если начать использовать везде (и где надо и где не надо) - Требуется уделять больше внимания производительности т.к. появляются новые места для плохого перформанса.

Очень хороший плейлист на ютубе, в котором содержится видеокурс по git. В коротких видео (от 2 до 16 минут) рассматриваются основные концепции git

Когда-то событие DOMContentLoaded перестали считать важной метрикой т.к. она чисто техническая и для пользователя она не интересна. Пользователю интересно чтобы контент быстро отрисовался и приложение стало интерактивным. Эта статья рассказывает, что событие DOMContentLoaded все еще может быть очень полезным для анализа производительности сайта. Тот факт, что метрика - техническая, не значит что она не полезна. У нас есть TTFB, которая также техническая метрика, но тем не менее очень ценная для анализа производительности сайта. Автор разбирает, как работает DOMContentLoaded и как это можно использовать. Событие возникает, когда все синхронные и deferred скрипты завершили свое выполнение. При этом в Navigation Timing API у нас есть 2 события - `domContentLoadedEventStart`, аналогичное DOMContentLoaded и `domContentLoadedEventEnd` - время когда обработчик `DOMContentLoaded` завершил работу. Также мы знаем, что есть событие `domInteractive`, которое, по сути, возникает когда браузер закончил чтение HTML страницы. Из этих данных мы можем выяснить следующие цифры: * `domContentLoadedEventStart - domInteractive` - время, необходимое на загрузку и исполнение deferred скриптов * `domContentLoadedEventEnd - domContentLoadedEventStart` - время необходимое на запуск обработчие DOMContentLoad Т.к. `DOMContentLoaded` предшествует последующим событиям (запуск приложения, отрисовка), то очень важно следить за этой и связанными метриками и оптимизировать их. Например, уменьшить размер HTML, количество блокирующих JS-файлов, инлайн маленьких JS-файлов (чтобы убрать пенальти на время сетевого запроса). Любое улучшение метрики улучшает все последующие метрики (практически все), поэтому имеет смысл уделять внимание `DOMContentLoaded`, хотя многие современные гайды по производительности не уделяют внимания этому событию

Пост про комбинирование парсеров. Автор на примере простых парсеров рассказывает, как, используя композицию, из простых парсеров получать сложные комбинированные парсерсы. Парсеры в статье упрощены и ищут в тексте определенные слова. Но сама статья достаточно хорошо объясняет, что если у вас простые чистые функции, делающие 1 свою работу хорошо, то с помощью базовым примитивов для композиции вы можете составлять более сложный функционал. В целом объяснение материала похоже на объяснение композиции чистых функций в рамках ФП

Статья расскзаывает про 15 полезных трюков при работе в DevTools. Некоторые "трюки" очень странные, другие же весьма полезные. 15. DevToolsUI можно зумить 14. DevTools позволяют удалять лишние элементы из DOM 13. Можно посмотреть шрифты, используемые элементом или страницей 12. Измерение расстояний на странице 11. Обнаружение неиспользуемого кода 10. Ускорить воспроизведение видео. Если плеер на странице не дает управлять скоростью воспроизведение - не беда! Это можно сделать через консоль 9. Смена языка DevTools (тут вспоминаются въетнамские флешбеки от devtools в MS Edge которые ну очень сильно хотят быть удобными и навязчиво предлагают русскую локаль) 8. Отключение обработчиков событий на элементах 7. Просмотр логов консоли на ios в не-сафари браузерах. В Chrome и Edge оказывается можно открыть специальную ссылку в отдельном табе и в этом табе будут складываться логи с других табов. Это может быть полезно для дебага через консоль прямо на устройстве, если нет возможно использовать другие способы дебага. Это, по крайней мере, лучше чем дебаг через алерты. 6. Скопировать стили элемента 5. Скачать все картинки со страницы (через JS скрипт) 4. Визуализировать страницу в 3D. Это можно использовать для анализа вложенности DOM, z-index или слоёв 3. Отключение debugger стейтментов, если вы не хотите на них останавливаться 2. Редактирование и переотправка сетевых запросов. 1. Эмулирование устройств

Один из менеджеров, работавших в npm, написал статью про большую проблему в безопасности npm экосистемы. Оказывается, в npm манифест пакета и контент пакета могут отличаться. При загрузке пакета в npm необходимо загрузить 2 вещи: манифест и tarball (архив) с контентом пакета. Манифест, это, по сути, примерно та же самая мета-информация о пакете, которая содержится в package.json. В tarball также хранится package.json пакета. Проблема в том, что в npm нет никакой валидации, что манифест пакета синхронизирован с package.json в tarball. На практике это несет следующие проблемы: 1. Можно убрать все скрипты и зависимости из манифеста, но при загрузке tarball окажется что скрипты и зависимости есть. В этом случае зависимости могут быть установлены, а скрипты (postinstall например) - запущены. Чем опасен запуск скриптов объяснять не нужно. С зависимостями же может быть не так очевидно: - Можно установить "вредную" зависимость, не указывая ее в манифесте - Можно заставить пакетный менеджер повысить или понизить версию какого-нибудь пакета. Допустим, в проекте стоит зависимость A^1.0.0, мы ставим пакет у которого в tarball в зависимостях также указан пакет A, но определенной версии, подходящей под ^1.0.0, но с какой-нибудь уязвимостью. Тогда пакетный менеджер может принять решение задедублицировать пакет A. Таким образом, зависимостью в tarball можно изменить версию пакета во всех проекте. 2. Если поиграться с полем version в tarball то можно заставить менеджер пакетов повысить или понизить версию пакета. Как следствие, из-за этой проблемы открыто много разных уязвимостей. А также некоторые популярные пакеты также подвержены этим проблемам (различие зависимостей и скриптов в манифесте и при установке)

JS-библиотека реализующая методы мат. статистики. Умеет считать как простые вещи (медиану, персентили, квантили) так и работать с дисперсией, коефициантами кореляций и всем таким. Если у вас есть задача получать какие-то статистические выводы на основе данных - это либа для вас. Лично я её применю в ближайший месяц для подсчета процессных метрик.

Еще 1 сервис для преобразования кода в картинку. Например это может быть полезно для презентаций или демок в Readme. Выглядит прикольно.

Очень крутая статья про написание кастомных правил Eslint. Она хороша как туториал, погружающий в проблематику и где каждый шаг написания кастомного правила хорошо расписан. Я, с удивлением для себя, обнаружил что в astexplorer можно не просто посмотреть AST кода, но и сразу писать и проверять работу eslint-правила. Рекомендую к прочтению и сохранению всем, кто хочет писать свои кастомные eslint-правила

Хорошая статья, объясняющая, что такое CDN и зачем он нужен. CDN - это сеть глобально-распределенных серверов, которые хостят ваш контент и быстро отдают его посетителям. Зачем это нужно. Представьте, что у вас есть производство и 1 большой склад для всей продукции, которую покупают по всему миру. Когда клиент из другой части света покупает что-то, ему приходится очень долго ждать. Поэтому крупные компании имеют локальные склады. Примерно тоже самое верно и для интернет-трафика. Для того, чтобы пользователь из Индии смог посмотреть сайт из Новосибирска, интернет трафик пройдет большой путь. Этот путь можно сократить, если уметь раздавать тот же самый трафик ближе к пользователю. Этим как раз и занимается CDN. CDN решает проблему быстрой доставки контента до пользователя, что дает следующие преимущества: 1. Нагрузка распределяется по серверам, вместо загрузки 1го сервера 2. CDN умеют оптимизировать трафик (корректно кешировать и сжимать его) 3. CDN умеет бороться с DDoS При внедрении CDN следует следить за следующими аспектами: - Ресурсы должны грузиться. Бывает, что при неверной конфигурации CDN часть ресурсов не может загрузиться - Метрики производительности (TTFB, LCP) должны улучшиться - Не должно быть ошибок в консоли (CORS, неверные заголовки)

Вышел Svelte 4. Со времени прошлого релиза прошло более 4х лет. Уменьшился размер пакета (сайт для изучения svelte в результате "похудел" на 12%), улучшился DX, обновили доку и требуемую версию NodeJS. Но при этом весь код, написанный для svelte3, совместим со svelte4, а для облегчения миграции есть автоматика.

Вводная статья про server actions в next.js. Статья рассказывает, что это такое, как это использовать и какие ограничения есть. Серверные экшны - это функции, которые будут выполняться на сервере, но при этом доступны как обычные функции из клиентского кода. Т.е. от пользователя не нужно заниматься оборачиванием кода в API: поднятием веб-сервера, созданием контроллера и тд. Это происходит под капотом (это либо что-то близкое к React Server Components либо это оно и есть, но для функций). Зачем это вообще может понадобиться: - Уменьшить вынесение логики в браузер = уменьшение размера поставляемого JS - Реализация сервер-специфичной логики (запросы в базу данных) - Безопасность. Например, шифрование, скрытие алгоритмов и тд Для того, чтобы объявить экшн серверным, необходимо использовать декларацию `use server` либо в самом экшне, либо в файле ``` async function myActionFunction() { 'use server'; // do something } ``` Либо ``` 'use server' export async function myActionFunction() { // do something } export async function anotherActionFunction() { // do something } ``` Теперь эти экшны можно импортировать прямо в компоненты и использовать как обычные функции, только они будут исполнятся на сервере. Также из интересных фичей - серверные экшны могут работать с отключенным JS в браузере при использовании в формах

Статья про развития индустрии разработки ПО. Автор работает в индустрии более 20 лет и своими глазами видел развитие технологий. Из своего опыта он делает вывод, что разработки идет по непрерывному циклу появляются новые, более эффективные инструменты = разработка ускоряется или упрощается = потребность в разработке возрастает = зарплаты разработчиков растут = в индустрию приходят новые люди = появляются новые инструменты... Раньше для раздачи стримингового контента надо было создавать свою P2P систему на C++. Теперь же эту задачу хорошо решают CDN. Это справедливо и для других вещей, которые нам сейчас кажутся обыденностью, но раньше были недоступны (быстрые юнит-тесты, CD, быстрая интеграция с системами оплат) Что происходит с экономикой, когда появляется инструмент, позволяющий решить задачу в 10 раз дешевле? Доступность производимого разработкой продукта растет = все больше компаний хочет себе свой продукт = растет спрос на разработчиков = у разработчиков растут зарплаты и в индустрию приходят новые разработчики Эти новые разработчики имеют совершенно иные навыки т.к. требования для входа в индустрию меняются вместе с развитием программной инженерии. Если раньше надо было знать Computer Science, понить как работает процессор, ОС, память, знать САР теорему, то теперь эти знания совершенно не обязательны. Это открывает путь в индустрию людям с совершенно другим бекграундом, что повышает разнообразие и ведет к появлению новых инструментов. Какое предсказание можно сделать: - Сейчас хорошее время чтобы стать разработчиком - Рынок инструментов для разработчиков будет расширяться - Компаниям следует поспевать за трендом, чтобы быть в экономике: использовать новые инструменты и современные подходы (децентрализация, высокая скорость интерации и тд) - Разработчикам следует использовать инструменты, делающие их эффективнее - Количество инженеров в компании с топ-разработчиками растет быстрее (разработчики придумывают инструменты = эффективность разработки увеличивается = бизнес масштабирует эффективность через найм)

Статья, подробно рассказывающая, как дебажить node.js с помощью различных инструментов. Начиная от console.log и заканчивая подключением к дебагерру через Chrome DevTools и VSCode и работе в дебагере

Статья объясняет разницу между гидрацией (Hydration) и оживлением (не уверен на счет корректного перевода, но оригинал - Resumability). В кратце описываются основные варианты гидрации веб приложения и чем же это отличается от resumability Автор разбирает гидрацию на 3 вида. 1. Полная гидрация. Это классическая схема, когда при серверном рендеринге генерируется HTML, а затем приложение в браузере приклеивается ко всем отрендеренным DOM-нодам, начиная с корня приложения 2. Частичная гидрация (Partial hydration) появилась как следствие того факта, что полная гидрация может быть очень тяжелой в плане производительности. Частичная гидрация предполагает, что гидрировать нужно только то, что необходимо пользователю. Т.е. пока пользователь не взаимодействует с компонентом, незачем его инициализировать. На этой концепции построена Island Architecture 3. Гидрация в React Server Component. Введение серверных компонентов на React позволяет явно выделять те компоненты, которые требуют гидрации на клиенте и те, которые могут быть отрисованы 1 раз на сервере. Resumability же предполагает, что нам не нужно ничего гидрировать и загружать пользователю, пока он не начнет взаимодействовать с кодом. В моей трактовке это очень близко к частичной гидрации, но разница вот в чем: при частичной гидрации предполагается что мы загружаем код компонента, когда пользователь имеет возможность с ним провзаимодействовать, чтобы как раз сделать компонент интерактивным. При Resumability же, мы навешиваем обработчики событий сразу, а только при взаимодействии загружаем компонент. И это позволяет не грузить лишний код в браузер и это недостижимо для текущих фреймворков, которые используют гидрацию.

Анонс бетки XState 5 XState пытается упростить кривую обучению. А именно, упрощает терминологию (уменьшая её), уменьшает количество API, описывает кучу примеров использования, предоставляет интерактивную документацюи и всячески стремиться к тому, чтобы применять XState было проще Что нового ожидается Вместо кучи разных сущностей для реализации логику теперь будут акторы. Акторы - единая сущность для логики в xstate. Акторы можно создать из промисов, функций, обсерваблов и тд. Также можно создавать акторы из чего угодно, написав соответствующие хелперы. Раньше акторы могли быть сохранены и загружены, но это не работало для внутренних акторов (актор А, вызывает акток Б). Теперь же сохраняется и загружаются все связанные акторы. Т.к. акторы могут запускать друг друга, то они естественным образом создают иерархию. Иерархия акторов - это система. В рамках одной системы акторы могут общаться друг с другом через специальное API. Упрощена передача данных в акторы. Также из интересных фич: добавили возможность применение partial wildcards для подписки на события. Раньше надо было выбирать - либо явно описывать все события. либо подписываться на все разом. Теперь можно подписаться по шаблону, например `pointer.*` Сейчас идет активная работа над хорошей интеграцией с TypeScript

Визуализированный гайд по работе с промисами. Гайд, с помощью анимаций, разбирает, когда и как лучше работать с несколькими промисами. Работу с группой промисов мы можем разделить на 4 категории двумя вопросами: 1. Хотим ли мы дожидаться исполнения всех промисов? 2. Необходимо ли нам чтобы все промисы выполнились успешно? В зависимости от ответа на эти вопросы необходимо выбрать нужный метод для работы с группой промисов. Если мы хотим дожидаться исполнения всех промисов и все промисы должны быть успешны - необходимо использовать `Promise.all`. Если мы хотим дожидаться исполнения всех промисов, но нам не обязательно, чтобы все промиссы были выполнены успешно - используем `Promise.allSettled` Если мы хотим дождаться первого успешного промиса - используем `Promise.any`, если мы хотим дождаться первого завершившегося промиса - `Promise.race`. Правила достаточно просты. В статье они красиво визуализированы (хотя у меня все равно возникли вопросы). Статью можно рекомендовать как обучающую для тех, кому необходимо познакомиться с работой промисов.

Очень хорошая статья в блоге Мартина Фаулера одновременно про проектирование через TDD и выделение зависимостей в коде без фреймворков. Код написан на typescript (все чаще в блоге Мартина Фаулера фигурирует код на javascript или typescript) Автор пытается решить следующую историю: пользователь хочет получить список лучших ресторанов, по мнению других пользователей. Автор последовательно, без фреймворков и следуя TDD, по немногу заводит сущности и сразу проектирует, как они должны друг с другом взаимодействовать. Сначала описывает верхнеуровневые детали, затем по-немногу погружается в домен и описывает зависимости, необходимые бизнес-логике для работы. Также автор следует бест-практисам, разделяя инфраструктурный код и бизнес-логику приложения. Код, который ищет лучшие рестораны, не знает ни о HTTP, ни о базах данных. Очень интересна реализация DI - автор просто берет и примяеняет Partial Application в создании хендлера запроса, в который кидаются зависимости (например, функция получения списка ресторанов) и которая возвращает обработчик запроса. Статья очень хороша по следующим причинам: - Очень хорошо объясняется, как применять прицнипы чистой архитектуры при проектировании сервиса - Очень хорошо объясняется, как использовать TDD при проектировании сервиса и его зависимостей - Автор не задается вопросом, а какой способ делать DI (pure, IoC container, etc) или какая библиотека для DI лучше - он его просто делает. В Javascript есть возможность применять Partial Application - этого УЖЕ достаточно для реализации DI - Объясняются концепции хорошего кода Рекомендую к прочтению

Статья про использование хуков, мидлварок и декораторов в fastify. Ниже приведу краткий пересказ. Хуки используются, чтоб добавить кастомную логиу перед или после какого-то действия. Например, перед отправкой ответа можно добавлять служебные заголовки Например ``` fastify.addHook("onSend", (request, reply, payload, done) = { reply.headers({ Server: "fastify", }); done(); }); ``` Хуки можно навесить как глобальные, так и на отдельные роуты. Хуки могут быть связаны как с запросами или ответами, так и с циклом работы приложения. Мидлварки позволяет добавить в цепь обработки запроса кастомную логику. Например, популярные использования для мидлварок - парсинг cookie или body у запроса. Fastify поддерживает expressjs-style мидлварок с помощью плагинов, но лучше использовать нативные fastify middlewares. Например, подключение `cookie-parser` позволяет удобно работать с куками в обработчиках запросов. ``` import Fastify from "fastify"; import middie from "@fastify/middie"; import cookieParser from "cookie-parser"; const fastify = Fastify({ logger: true, }); await fastify.register(middie); fastify.use(cookieParser()); ``` Также в fastify есть декораторы. По названию кажется что это еще 1 API для добавления логики к обработчикам запросов, но это не так. Декораторы позволяют добавлять новые свойства или функции к объекту fastify приложения, запроса или ответа. По сути, они позволяют добавить кастомное API во встроенные в fastify объекты. Например, можно добавить метод `isAuth` прямо в request, что звучит достаточно удобно. Также fastify имеет встроенную поддержку валидации данных через JSON-схему ``` fastify.post( "/users", { schema: { body: bodySchema, }, }, async (request, reply) = { /* обработка запроса */ } ); ``` Если запрос не проходит валидацию, fastify отвечает 400 кодом с описанием, какое поле не прошло валидацию. Если вам надо переехать на fastify с expressjs, то можно использовать плагин `@fastify/express`, который облегчает использование `expressjs` кода в fastify окружении.

Bun вместе со своим бандлером представил свои макросы. Макросы - это JS-функции, которые выполняются в момент сборки приложения, а не во время исполнения приложения. Bun исполняет функцию-макрос и инлайнит её результат в вызываемом коде. При этом поддерживаются как синхронные, так и асинхронные функции Примеры применения: - Инлайн env переменных в код (например git commit) - Загрузка сетевых ресурсов (fetch чего-нибудь) - Предкомпиляция хелперов На самом деле, очень интересный функционал Пример кода ``` import { getGitCommitHash } from './getGitCommitHash.ts' with { type: 'macro' }; console.log(`The current Git commit hash is ${getGitCommitHash()}`); ```

Статья рассказывает, как с помощью shared workers реализовать совместное использование websocket соединения несколькими вкладками. Shared worker это примерно как web worker, но с возможностью быть интегрированным несколькими вкладками. Такой worker не зависит от времени жизни определенной вкладки, т.е. если вкладка, которая породила такой worker, закроется - это не приведет к завершению worker'а. Shared worker завершается сам, когда не остается вкладок, которые с ним работают. В shared worker реализуется работа с websocket соединением, worker может обрабатывать сообщения от websocket и отправлять их во все подключенные вкладки

Коллекция полезных хуков для React, совместимых с серверными компонентами, от команды ui.dev

Возможно вам не нужен React Query. Статья является ответом на горячие споры в интернете о том, что серверный компоненты react делают React Query ненужным. Не смотря на то, что React предоставляет удобный способ делать асинхронную загрузку данных прямо в серверном компоненте, React все еще остается очень гибким решением, которое не форсит какой-то один способ как делать что-то "правильно". Для определенных приложений (например, которые сразу пишутся по определенной архитектуре, в которой серверные компоненты хорошо встроены), React Query действительно может быть не нужен. Однако для многих приложений придется использовать гибридный подход (и серверный компоненты и React Query) из-за ограничений архитектуры, плавных миграций или каких-то плюшек React Query. Либо же останутся проекты, которые не будут использовать серверные компоненты.

Статья про то, как команда wikipedia обнаружила, что их метрика Total Blocking Time на некоторых страницах достигает 600мс, что выше рекомендованной на 400мс и как они это исправляли. Что такое Total Blocking Time. Google Chrome любые таски, которые длятся дольше 50мс, помечает как long task. Сумма превышения тасками черты long task между первой отрисовкой и тем, как страница стала интерактивной (между FCP и TTI) и является Total Blocking Time. Например, страница отрисовалась, затем JS код выполняет 3 таски - 80мс, 30мс и 100мс. И затем страница становится интерактивной. В этом случае TBT будет = (80-50) + (100-50) = 80мс - столько времени таски превышали лимит в 50мс. Для некоторых страниц википедии TBT составлял 600мс. Просто безумно большое число. Эта проблема была решена в 2 этапа. 1. Было найдено, что 456мс забирает функция `_enable`. Wikipedia использует jquery, и эта функция находила все ссылки и накидывала им кастомный обработчик. На некоторых страницах находятся тысячи ссылок, что делает запуск этой функции долгой задачей. Хуже всего, что этот код не необходим, т.к. буквально за ним идет подписка на `hashchange`, который делает ровно то же самое, что и навешиваемый обработчик. Поэтому этот код был беспощадно удален, что дало улучшение в 200мс. 2. Дальше при исследовании было найдено, что функция `initMediaViewer` занимает 114мс. Там примерно та же проблема, что и в пункте 1. А конкретно - навешивается куча обработчиков слишком рано. Вместо этого используется возможность делегерирования событий. Обработчик накидывается только на контейнер с картинками. Обработчик по `event.target` определяет, какую конкретно картинку необходимо подгрузить В целом wikipedia избавились от 300мс в метрике TBT. Это все еще много (больше рекомендаций), но тут важно, что причина катастрофически низкой производительности как правило в том, что никто просто ей не занимается. Оптимизации в статье самые базовые и легко могли быть сделаны раньше.

Туториал по созданию своего плагина для ChatGPT на JS. В целом создается простой HTTP сервер, который умеет отдавать корректную метаинформацию для интеграции с ChatGPT.