Опция --erasableSyntaxOnly в TypeScript

Вышли релизноуты беты TypeScript 5.8. Там есть разное полезное, но меня зацепила одна конкретная опция. В новом релизе хотят добавить аргумент --erasableSyntaxOnly, который попросит TS ругаться на конструкции языка, несовместимые с Node.js.

Если помните, в Node.js завезли возможность запускать ts-файлики вырезанием типов. И мешать могут енамы, неймспейсы, специальные особенности конструкторов классов. В целом, если вам правда очень хочется запускать ts-код без компиляции и сборки, можно поискать эти мешающие конструкции тем же поиском по файлам, регулярками, но гораздо приятнее, когда на ошибку кто-то укажет явно.

В общем, Node.js и TypeScript идут навстречу друг другу, это здорово.

https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-8-beta/

Время избавляться от BlinkMacSystemFont и -apple-system

Короткий рецепт. Если у вас в стилях подключаются шрифты BlinkMacSystemFont и -apple-system, то удалите их и замените на system-ui. Поищите в фолбеках.

А вот почему так, откуда эти шрифты взялись и безопасно ли их вообще использовать — в посте Стояна Стефанова.

https://highperformancewebfonts.com/read/ditch-BlinkMacSystemFont-and-apple-system

Кнопка «Вверх» с индикатором прогресса

Мануэль Матузович собирает популярную на различных сайтах кнопку «Scroll to top» на HTML и CSS. Кнопка из коробки доступная (потому что ссылка), заодно показывает, сколько процентов страницы уже прочитано пользователем. «2-в-1, только сейчас в нашем онлайн-магазине, ещё и бесплатно!»

Заранее предупрежу, что использует она под капотом современные возможности браузеров вроде Scroll Timeline API и @property, но это не мешает прогрессбар прикручивать как прогрессивное улучшение.

https://matuzo.at/blog/2025/scroll-to-top-button

Сохранение интерактивности страницы во время View Transition

Я несколько раз в подкасте жаловался на то, что у прекрасного View Transition API есть один существенный недостаток: пока идёт анимация перехода, страница перестаёт быть интерактивной. То есть кнопки не нажимаются, ховеры не срабатывают и так далее.

В целом, оно и логично. Во время перехода по сути у вас одна картинка превращается в другую. Не очень понятно, куда клик должен проваливаться.

И вот Брамус поделился простым, но интересным решением.

::view-transition {
    pointer-events: none;
}

Во время перехода на странице создаётся псевдоэлемент ::view-transition, который накладывается поверх вьюпорта. И ведь в CSS уже давно есть способ убирать с элементов обработку событий указателя. Классно! Классно же, да?

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

У меня в проекте переключение темы сделано через VTA, и там этот сниппет, к сожалению, не применить, потому что тема переключается на всём документе единомоментно. Но я уже поигрался с тем, чтобы анимировать внутри страниц таким образом — нравится.

https://www.bram.us/2025/01/29/view-transitions-page-interactivity/

CTF для конференции «Я люблю фронтенд»

Уже сбился со счёта, сколько лет помогаю делать конференцию «Я люблю фронтенд» в составе програмного комитета. Не буду говорить, что программа там классная. Не буду намекать, что можно будет 15 февраля подключиться посмотреть в онлайне или прийти офлайн (если успели ухватить билет).

Но для меня одна из самых любимых частей этого события — ежегодный CTF для фронтендеров, который мы готовим к конфе с 2021 года. Многие же говорят, что пришли в айтишечку, чтобы делать игры (а потом что-то пошло не так). А мы вот прямо сейчас доделываем ещё одну игру, которая стартует сегодня в MTk6MDMgKEdNVCszKQ==.

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

P.S. Авторы игры не несут ответственности за тильт и батхёрт во время решения задач

hyphenate-limit-chars

Одно из недавних моих открытий в мире CSS-спецификаций. Думаю, про свойство hyphens: auto, которое включает перенос на новую строку для длинных слов, вы знаете. Точнее, просит браузер, если у него есть правильные словари, включить эти самые переносы. Использую редко, потому что мне в целом не нравится, когда в веб бездумно переносят то же самое, что есть на бумаге.

Но, оказывается, есть ещё одно полезное свойство, которое не даёт браузеру переносить слишком короткие слова. Если записать hyphenate-limit-chars: 10 4 3, то вы говорите браузеру:
- не переноси слова, которые короче 10 символов;
- при переносе оставляй на первой строке не меньше 4 символов;
- при переносе оставляй на второй строке не меньше 3 символов.

Можно написать короче, hyphenate-limit-chars: 10, если вам важен контроль только над длиной слов.

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

https://developer.mozilla.org/en-US/docs/Web/CSS/hyphenate-limit-chars

Любопытное применение CSS-импортов в вебе

Эрвин Хофман подсвечивает большую проблему в современном вебе. По статистике Веб-Альманаха за 2024 год на 18.86% сайтов есть @import в CSS. Причём на 15.16% это подключение чего-то стороннего. Чаще всего — веб-шрифтов, fonts.googleapis.com в статистике лидирует.

Почему это проблема? Потому что @import блокирует рендеринг. Браузер видит @import в CSS-коде, идёт качать новые стили, в это время много какие процессы уходят на перекур. И только после того, как новые стили скачаются, можно продолжить остальное важное для рендера страницы. В случае со сторонними доменами тратится ещё и неприличное время на DNS-резолвинг, рукопожатия лишние и прочее междоменное. Ну и заодно любезно сливаются данные о пользователе, которые можно достать из запроса даже к CSS-файлу.

А вот был бы старый надёжный <link rel="stylesheet" href="another.css">, таких проблем бы не было. У браузера есть так называемый preload scanner, который умеет для оптимизации скачивать ресурсы заранее. Ещё и приоритет ресурсу можно выставить повыше, если стили очень важные.

В общем, если у вас есть в команде внутренние KPI на ускорение сайта, при этом в коде есть CSS-импорты — уберите их, с высокой вероятностью полезные метрики вырастут.

https://calendar.perfplanet.com/2024/the-curious-performance-case-of-css-import/

Шрифт Martian Mono v1.1.0

Приятный релиз для любителей шрифтов с лигатурами. У «Злых Марсиан» есть свой моноширинный шрифт, Martian Mono. Мне он нравится не только за приятные и читаемые формы символов, но и за уважение к многообразию языков в мире. У меня есть свой тест для шрифтов: смотрю на букву Ў. Если что, это не просто «У» с шляпкой, а 22-я буква беларусского алфавита, а я иногда в личных проектах пишу комментарии на беларусском языке (і што вы мне зробіце? гэта мая родная мова, дзе хачу, там і выкарыстоўваю). Очень многие хорошие кириллические шрифты на этом тесте ломаются.

В версии 1.1.0 появилось ещё больше символов из разных языков мира. И новые программистские лигатуры.

https://github.com/evilmartians/mono/releases/tag/v1.1.0

Как поиск Google использует Speculation Rules API

Интересные новости. Оказывается, Google Search для двух первых результатов в выдаче в браузерах, которые умеют в Speculation Rules API (а это Chromium-браузеры на данный момент), заранее делает prefetch. Причём, если я правильно помню, когда не задана явно настройка eagerness, то это по сути равно «как только, так сразу». А так как страница поиска довольно хорошо оптимизированная, то в большинстве случаев запросы на первые два сайта идут.

В статье показано, как Google использует API для анонимизации IP пользователей, прятания referer (иначе можно было бы выдачу поиска исследовать) и работы с куками (точнее, их отсутствием).

С одной стороны, вроде бы становится хорошо: LCP у сайтов в топе уменьшается на 67 миллисекунд на мобилках и на 58.6 миллисекунд на десктопах. А это для современного веба много. С другой — не нашёл нигде статистики, как эти сайты с нагрузкой справляются лишней. Ведь по сути сайт в топе выдачи — это популярный сайт. И обращаются к нему часто, то есть владельцы сайтов как-то прогнозируют трафик, чтобы держать какую-то нагрузку. Для большинства сайтов вряд ли один дополнительный запрос от пользователя что-то радикально сломает, но ведь кому-то и сломает.

Для остальных 8 ссылок в поиске работает чуть менее агрессивный prefetch с настройкой "eagerness": "moderate", то есть скачивание начинается по 200мс-ховеру или по опусканию указателя.

Предвосхищая вопросы про рекламу, вроде «Интересно, на рекламу тоже работает такой prefetch?», подозреваю, что нет. Потому что реклама не попадает в число 10 ссылок выдачи, она всегда в дополнение. А ещё за клик по рекламе списывается денежка рекламодателя, хотя, наверное, тут могли бы как-то отделить честный клик от предварительного префетча. В статье про это ничего нет, но я попробовал поиграться с запросом «окна», глядя в девтулзы — не заметил префетча рекламы, а вот органическую выдачу вполне себе браузер скачивает заранее.

https://developer.chrome.com/blog/search-speculation-rules

Инструмент поиска утечек памяти 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