Инструмент поиска утечек памяти fuite

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

По сути достаточно вызвать команду npx fuite https://my-awesome.website/some-page -o ./output.json. После этого утилита запустит безголовый Chrome, а потом долго будет прогонять простые тесты, кликая по ссылкам и возвращаясь назад. В процессе анализирует heap snapshots, подписки на события и всякие доступные через Chrome DevTools Protocol объекты (к сожалению, именно поэтому тестирует по сути только в Chromium), а в конце выдаёт отчёт, где чего протекает.

Так как запускается это всё у вас локально на машинке, то можно хоть на dev-сервер натравить эту утилиту, хоть на продакшен. Я запускал на продакшен. Тестировало долго. Я бы даже сказал, что очень долго. Но нашло в одном проекте утечек на 700 килобайт памяти, а это уже хороший повод потерпеть. Ещё и показывает, где именно протекает, удобно.

https://github.com/nolanlawson/fuite

Переосмысление доступности скрытого текста при поиске

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

Оказывается, в стандарте HTML есть значение атрибута hidden=until-found, которое по умолчанию ведёт себя как hidden, но когда на элементе фокусируются через ссылку или поиском по странице, hidden убирается. И одним из кейсов применения этого атрибута может быть как раз доступность при поиске по странице.

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

https://schepp.dev/posts/rethinking-find-in-page-accessibility-making-hidden-text-work-for-everyone/

Doom на TypeScript

Энтузиасты из сообщества Michigan TypeScript смогли запустить Doom на TS. Точнее, они написали и выложили в опенсорс движок для WebAssembly, который работает на типах. И основная новость, на самом деле, в этом. А Doom на типах рендерится ооооочень медленно, ещё и на обычных машинках не запустится, уж больно много памяти надо. Но ведь работает!

https://news.1rj.ru/str/artalog/1572

Сравнение LLM для генерации alt-подписей к картинкам

Дрис Бюйтаерт попробовал 10 локальных и 2 облачных LLM, чтобы оценить, какие из них лучше справляются с генерацией содержимого для атрибута alt у картинок. Он ведёт свой блог уже почти 20 лет, за это время скопилось много картинок без подписей, а это не ок.

Дрис сразу пишет, что облачные LLM справляются очень хорошо, но для него всё равно не очень удобно загружать больше 9000 фотографий непонятно куда.

Среди локальных лучше всех себя проявили MiniCPM-V и разные версии Llama. Правда, Llama даже в этом микротесте галлюцинировала. То есть автоматическую разметку либо нужно всё равно проверять вручную, либо дождаться, когда локальные модели станут точнее.

Ещё один вариант, который рассматривал Дрис — помечать сгенерированные AI подписи в БД и периодически их обновлять. Но тогда нужно и пользователям дать знать, что это автоматическая подпись. К слову, тогда, может, лучше и не подписывать совсем, потому что уже есть скринридеры с подобными функциями.

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

https://dri.es/comparing-local-llms-for-alt-text-generation

SVG-фавиконки в Safari

Тут в Safari Technology Preview 214 подвезли радостное: поддержку SVG-фавиконок! На сегодняшний день из тройки основных браузеров Safari был последним, кто не поддерживал этот формат. А ведь формат полезный и легковесный: можно динамику подключать, под тему адаптироваться, эмодзи внутрь вставлять. Я буквально много где сам первым делом подключаю к проекту отдельную SVG-фавиконку для dev-сборки, чтобы отличать вкладки между собой.

В общем, жду полноценного релиза.

https://webkit.org/blog/16512/release-notes-for-safari-technology-preview-214/

CSS Puzzle Box 2.0

На ютубах есть относительно популярная категория видео, где автор пытается решить какой-то сложный физический паззл: открыть сейф, достать ключик из кубика без видимых щелей и так далее. Блэкл Мори объясняет, как можно сделать такой паззл на HTML и CSS.

В этот раз вся магия держится на особенностях работы details и summary, а также сочетании свойства resize с max-height, max-width и calc() для хитрых вычислений. Есть специальный Width Hack, который позволяет эти примитивы превращать в машину состояний, где каждое нажатие на «кнопку» вызывает новое состояние со своими кнопками.

Коротко тяжело пересказать, что там происходит, нужно смотреть в демки, вникать в код, пробовать сделать что-то похожее. Мне понадобилась пара часов, чтобы разобраться, но оно того стоило — кажется, на следующем CTF для конференции «Я люблю фронтенд» будут задания со схожими механиками.

А если не хотите разбираться, как паззл работает, то можно просто попытаться его решить.

https://suricrasia.online/blog/inline-css-puzzle-box/

Эффект подсветки на CSS / SVG

Знаете вот этот приятный глазу эффект, когда за телевизором подсветка подстраивается под картинку на экране? Кто-то готовое покупает, кто-то собирает из ардуинки и опенсорса.

Вэс Бос показывает, как сделать такое в интерфейсах при помощи SVG-фильтров. Буквально 5 строчек SVG, 1 строчка CSS — и у вас на сайте есть подсветка для видео, которая подстраивается под каждый кадр.

Дополню оригинальную демку советом не забывать про prefers-reduced-motion — не все пользователи могут комфортно смотреть на переливашки и анимашки.

Видео: https://x.com/wesbos/status/1841186089886777705
Исходный код: https://github.com/wesbos/hot-tips/tree/main/css-backlight

Node Modules Inspector

Увидел в твиттере у Андрея Ситника рекомендацию попробовать визуализатор и инспектор для node_modules от Энтони Фу. Сегодня попробовал — и тут же рекомендую вам тоже.

Одной строкой: pnpx node-modules-inspector.

Подробнее:
- Показывает все зависимости графом, если любите связи смотреть.
- Есть довольно удобный фильтр, чтобы сфокусироваться на какой-то конкретной зависимости.
- Можно проверить все лицензии у пакетов, чтобы не нарушить их нечаянно.
- Показывает размеры зависимостей (у меня в рабочем проекте на 1.5 гига оказалось, без визуализации не доходили руки самому проверить).
- Помогает работать с одноименными зависимостями разных версий — сижу немного в шоке, пытаясь осознать, как мы пришли к использованию 15 версий пакета uuid в одном проекте.
- Подсвечивает устаревшие зависимости.
- И ещё очень много, много всего.

Автор инспектора, если что, делает очень много всякого полезного в опенсорсе, чем вы скорее всего пользовались в современных проектах, так что в качестве и живучести node-modules-inspector я лично не сомневаюсь.

https://node-modules.dev/

Открытие ссылок в PWA

В релизе Chrome 134 выкатилось приятное: поддержка Launch Handler API для открытия ссылок в установленных PWA. То есть если вы, например, установили какое-то PWA для прослушивания музыки и кто-то скинул вам ссылку на сайт, который вы превратили в это самое PWA, то теперь можно в веб-манифесте указать, чтобы открывалась не вкладка в браузере, а PWA.

Запутанное немножко объяснение, но приведу аналогию. Когда вам приходит на мобилке ссылка на Twitter/X, и при этом у вас есть установленное приложение Twitter/X, у вас открывается сразу приложение, а не сайт. Теперь так же можно будет делать для PWA.

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

{
  "launch_handler": {
    "client_mode": "navigate-new" | "navigate-existing" | "focus-existing" | "auto"
  }
}

И дополнительно обработать при открытии страницы window.launchQueue.

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

https://developer.chrome.com/docs/web-platform/launch-handler

API для получения Baseline-статуса фичей

Если вы вдруг пропустили, пользоваться CanIUse уже не модно, сейчас все пользуются Baseline — простым признаком, можно ли тащить фичу в продакшен или ещё рано.

Шучу, конечно, это разные инструменты для разных, хоть и похожих задач. Но сам уже успел привыкнуть, что если у фичи на MDN стоит лейблочка «Baseline Widely available», то особо смотреть на нюансы браузерной поддержки, скорее всего, нет нужды.

Теперь получать данные о поддержке той или иной фичи можно при помощи API.

const query = encodeURIComponent('baseline_status:newly AND group:css');
let url = `https://api.webstatus.dev/v1/features?q=${query}`;
const response = await fetch(url);

В запросах к API есть логические комбинаторы, разные фильтры. Вернёт апишка статус фичи по Baseline с дополнительной информацией, айдишник фичи, название и ссылки на спецификации.

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

https://web.dev/articles/web-platform-dashboard-baseline

Какую нагрузку выдерживает пререндеренный сайт на Next.js

Мартин Холс задумался: если статья из его блога на Next.js попадёт на Hacker News, сайт упадёт или всё будет хорошо?

Напомню, Next.js позволяет генерировать и SSR, и SSG (pre-rendered). При этом фреймворк очень многое автоматизирует и не то чтобы разрешает сильно влиять на то, как доставляются ресурсы на клиент. В итоге одна страница блога Мартина генерировала уже 60+ запросов за раз. А быстрое нагрузочное тестирование показало, что его VPS выдерживает всего 193 запроса в секунду. Получается, четыре посетителя блога в принципе могут положить сайт, если синхронизируются.

В статье есть интересные замеры и разные подходы, как выкрутиться из такой щекотливой ситуации. Есть в том числе отличное замечание, что для личного блога держать 193 RPS на самом деле нормально, грустно бывает только во внезапные пики популярности.

А ещё SSR работает медленнее на 80–90%. Причём вам ещё и CPU хороший понадобится для вычислений. Поэтому если у вас SSR для статических лендингов — лучше сразу денежку сжигайте в топке, хоть воздух нагреете.

Год назад, кстати, фронтендеры в моей команде тоже провели замеры RPS для Next.js-приложения. Нам надо было выдерживать высокую нагрузку буквально в течение одной минуты, пока на большой сцене показывали QR-код на сайт. И тогда тоже выбрали SSG для главной страницы, хотя весь остальной сервис на SSR. Сработало. Но числа для меня были удивительными. Developer Experience, конечно, в современном фронтенде очень высокий, но вот ради одной простой странички столько всего генерировать… Эх.

https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rendered-nextjs-site-handle

Я 💛 Фронтенд 2025

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

Все записи докладов конференции «Я 💛 Фронтенд», которую мы делали внимательно к деталям и с большой любовью к нашим зрителям.

YouTube: https://www.youtube.com/playlist?list=PLKaafC45L_SSmPKkIb4BMs0Mde8p_RvUu
VK: https://vkvideo.ru/playlist/-17796776_55

Режим «от края до края» в Chrome на Android

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

Теперь такое же можно делать и в Chrome 135+. Для этого надо добавить метатег на страницу.

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />

Ключ viewport-fit как раз и отвечает за включение этого специального режима.

А в CSS нужно тогда, как мы уже привыкли для iOS, поработать с env(safe-area-inset-bottom), чтобы всякое кликабельное у вас на сайте не попало в служебные островки, которые всё-таки будут мешать пользователю кликнуть.

В статье есть примеры кода, как работать с «новым» режимом. И видео с визуальной разницей старого и нового режимов. И инструкция, как потестировать это уже сейчас. Больше всего в инструкции мне нравится фраза «Restart Chrome twice».

Почему я режим называю «новым» в кавычках: потому что на iOS мы и так уже работали с похожим поведением, так что если у вас уже были оптимизации под островок и бровку на яблочных смартфонах, то в Android, по идее, заведётся тоже. Более того, Chrome умеет в правильные переменные env тоже очень давно, так что вся новость скорее в том, что теперь надо будет не забыть протестировать ваш красивый сайт ещё и в режиме «от края до края».

https://developer.chrome.com/docs/css-ui/edge-to-edge

MinskJS Meetup #12

Чуть не забыл с вами поделиться. Уже сегодня (19 марта 2025) в 19:00 по минскому времени проведём онлайн-митап нашего лампового минского фронтенд-сообщества.

Будет три доклада:
- Лёша Назаренко расскажет, что такое веб-компоненты в современном фронтенде.
- Глеб Казачинский покажет, как писать веб-компоненты на популярных фреймворках.
- Настя Котова научит разбираться, откуда берутся ошибки node-gyp при установке npm-зависимостей.

Приходите поддержать спикеров (для некоторых это первое публичное выступление) и позадавать вопросы в чат трансляции. Вести митап будут Саша Шинкевич и Глаша Жур, а я буду на подхвате в фоне помогать.

До встречи!

P.S. А запись будет? Будет.

Ссылка на трансляцию: https://youtube.com/live/ILRrXYSthsA
Программа митапа: https://telegra.ph/MinskJS-Meetup-12-03-01

Библиотека styled-components всё

Эван Джейкобс объявил, что проект styled-components переводится в режим поддержки. Так как React Context API не работает в RSC, фронтендеры всё реже используют CSS-in-JS, а у него самого нет активных больших проектов с использованием styled-components.

Это не значит, что нужно бежать выпиливать библиотеку из зависимостей. Если вы не планируете постоянно обновлять проект, вас устраивает React 18, при этом всё отлично работает — пусть и дальше работает. Но новые проекты лучше делать уже без использования styled-components.

https://opencollective.com/styled-components/updates/thank-you

box-decoration-break

Как говорится, век живи — век учись. Оказывается, в CSS уже относительно давно за префиксами и не так давно без префиксов в большинстве браузеров есть свойство box-decoration-break: clone, которое позволяет творить магию с многострочными inline-элементами.

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

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

Так вот, box-decoration-break: clone — и теперь каждая строчка (фрагмент) становится самостоятельной. Со своим фоном, своими границами.

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

Из особенностей: Safari всё ещё просит префикс -webkit- для работы свойства.

https://css-tricks.com/decorating-lines-of-text-with-box-decoration-break/

Уязвимость Next.js CVE-2025-29927

В твиттерах сейчас только и разговоров, что про новую уязвимость в Next.js, которая позволяет получать доступ к админкам, обходить CSP и вообще творить непотребства с вашими сайтами, если они на уязвимых версиях Next.js.

Если коротко, при помощи заголовка x-middleware-subrequest в HTTP-запросе можно уйти в ветку кода, в которую по идее нельзя пускать неавторизованных пользователей.

Что нужно сделать сейчас:
- Обновиться до версий 15.2.3+ или 14.2.25+.
- Если обновиться не получается, то самостоятельно вставить обработчик x-middleware-subrequest, который не даст творить дичь.

Про уязвимость: https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware
CVE: https://github.com/advisories/GHSA-f82v-jwr5-mffw

Археологические раскопки: Packer.js

Иван Акулов вспоминает, как в 2018 году, делая аудит для одного из клиентов, наткнулся на библиотеку мниификации JS-кода Packer. Это очень старая библиотека, у которой есть режим Base62 encode. Тут нет опечатки, Base62.

Суть в том, что ключевые слова из кода заменяются на числа. То есть вместо let x = a.toString() у вас получится что-то вроде 0 1=2.3(), а уже дальше эта строка преобразуется на клиенте в нужный код через словарик и выполняется при помощи eval.

Удивительно, что такой подход сжимает большие библиотеки лучше современных Terser и прочих минификаторов. Например, Three.js сжимается через Terser до 358 КБ, а через Packer — до 266 КБ.

Но нет, это не повод тащить такой минификатор в прод. Привычный gzip в итоге справляется гораздо лучше с кодом от Terser, чем с кодом от Packer. То есть нельзя сравнивать инструменты только по тому, как они работают в изолированном примере, нужно смотреть на доставку кода на клиент целиком. Ну и eval в продакшене — такое себе счастье.

Но подход точно интересный хотя бы для минимальной обфускации.

https://3perf.com/blog/packer/

Не дизейблите кнопки

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

Как часто делают, когда нужно, чтобы пользователь не отправлял форму? Например, когда он только что нажал кнопку «Отправить форму» и интерфейс ждёт ответа от бекенда. Правильно, добавляем атрибут disabled — и всё, браузер всё выключит за нас. Правда же?

Крис Фердинанди подсвечивает, что нет. Во-первых, я всё ещё могу перейти в какой-нибудь input и нажать в нём Enter / Return. Если форма свёрстана как форма, то по умолчанию форма отправится ещё раз. Получается, кнопку выключили, но проблему не решили. UPD. Спасибо подписчикам, обратили внимание на ошибку в статье, есть спека, в которой это поведение продумано, а я поверил и не проверил.

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

В статье предлагается решение с использованием JavaScript. Правильнее будет навесить событие submit на форму, внутри колбека проверить, можно ли отправлять. Если надо визуально «выключить» кнопку, то стилизуем её как неактивную, но не дизейблим.

https://gomakethings.com/dont-disable-buttons/

Lighthouse Treemap

Внезапно для себя обнаружил, что в Lighthouse давно есть возможность посмотреть загружаемые на страницу скрипты в виде Treemap. Это такое отображение прямоугольничками, чтобы понимать, что больше весит по сравнению с другими частями. В Node.js — уже привычный способ смотреть на зависимости, а вот про то, что так же можно посмотреть клиентскую часть прямо в браузере, узнал только сегодня. Случайно кликнул кнопку View Treemap, которую всё время игнорировал.

Посмотреть свои скрипты можно как минимум тремя способами:
1. Запустить аудит Lighthouse прямо в Chromium-браузере, после аудита нажать ту самую кнопку View Treemap.
2. Выгрузить результаты аудита в формате JSON и загрузить на https://googlechrome.github.io/lighthouse/treemap/
3. Запустить Lighthouse через CLI, сгенерировать отчёт.

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

https://umaar.com/dev-tips/247-lighthouse-treemap/

Не забывайте про метатег theme-color

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

Тут можно было бы вставить мем со светящимся разумом, доходящим до мегаразума.

Когда пользователь переключает тему:
Шаг 1. Поменять класс на корневом узле, чтобы применить кастомные стили, заменить переменные, перекрасить интерфейс.
Шаг 2. Поменять color-scheme в CSS, чтобы нативные контролы тоже адаптировались. Это свойство помогает инпутам, скроллбарам и прочим нативным элементам подстроиться под тему.
Шаг 3. Установить <meta name='theme-color'>. Это подскажет браузеру, как адаптировать оформление браузера и операционной системы под тему. Так у вас не получится тёмная тема с большой белой браузерной плямбой наверху экрана.

https://blog.jim-nielsen.com/2025/dont-forget-meta-theme-color/