Пульс веб-платформы 25.04.2025

Новости

  • не Vitest единым: в параллельной Rust-песочнице начали готовить свой тестовый фреймворк на основе API Jest, обещают глубокую интеграцию с RS-экосистемой
  • в новой версии pnpm 10.9 поддержана установка JSR-пакетов pnpm add jsr:<pkg_name>
  • вышел React Compiler RC: прошлый отдельный eslint-плагин смерджен в eslint-plugin-react-hooks, начали двигаться в сторону поддержки в том числе Babel-free-сборки
  • в React экспериментируют с ViewTransitions — плавными переходами между компонентами, наборами данных, состояниями интерфейса, а также с Activity — специальным API для анмаунта частей инфтерфейса, но с сохранением их состояния и низкоприоритетным продолжением рендера (для дальнейшего возможного показа этих частей)
  • пропоузал Records and Tuples в ES был официально отклонён TC39 из-за нежелания добавлять новые примитивы в язык, в пользу добавления новых объектов (tc39/proposal-composites#15)
  • JetBrains выкатили обновление WebStorm 2025.1 с подпиской на возможность подключить AI-ассистента + агента

Проекты

  • number-flow — в последнее время распространился дизайн-паттерн, когда что-то печатается в браузере, и этот кросс-фреймворковый компонент для анимированного перехода между чисел может пригодиться
  • playwright-mcp — вот к Playwright вслед за Puppeteer прикрутили MCP-интерфейс, так что теперь LLM смогут невизуально взаимодействовать со страницами благодаря дереву доступности (погодите, но это же была тула для тестов?!)

Статьи и демки

JS/TS

  • в недавно вышедшем Chrome 135 появилась экспериментальная поддержка fetchLater — особого API для отправки beacon-запроса «в один конец»; замысел авторов — не отталкиваться больше от событий страницы (unload/beforeUnload, которые поддерживаются нестабильно), а перейти к регистрации разработчиками намерения отправить beacon-запрос, а браузер уже позаботится об остальном сам (хотя, в целом, целесообразность появления этого API не очень ясна, ведь недавно как раз везде поддержали keepAlive у обычного fetch)
  • одна из причин, почему с веб-компонентами всё сложно: атрибут у HTML-элемента и значение свойства у JS-объекта этого элемента — это разные штуки: когда меняется свойство, значение атрибута не меняется, а вот смена значения атрибута чаще всего отзеркаливается в смене значения свойства, и в веб-компонентах как кастомных элементах с этим нужно разбираться вручную
  • замена ветвистых условий в функциях на плоскую структуру, где сначала идут early-returns, после идёт непоредственно функциональность, а затем обработка ошибок выполнения, обычно улучшает читаемость, и хочется меньше скипать код при его изучении
  • разбор более сложных кейсов в TS: as const для уточнения типа, indexed access types, mapped types:
const sendEvent = <E extends EventName>(event: E, payload: HomeEvents[E]) => {
  /* ... */
};
type BooleanProperties<Type> = {
  [Key in keyof Type]: boolean;
};

CSS

--page-colour: oklch(from #49498d calc(l / 4) c h);

Платформа

  • помимо привычных браузеров Chrome, Firefox, Safari и Edge, которые в современном мире распространяются дефолтными установками в ОС, на базе их опенсорсных движков строят другие браузеры со своими фишками: где-то с переосмысленным UX (Arc, Horse, Zen, Wavebox, Surf, Shift), где-то с доп privacy (Orion, DuckDuckGo), где-то с доп функциями (Vivaldi), где-то с криптой (Brave), но отдельные смельчаки строят полностью свои движки (Ladybird, Flow, Servo)
  • ещё один пойнт про осознанное применение AI в кодинге: делегируя AI-помощнику трудности решения проблем и нахождение решений, вы обкрадываете свой же опыт, благодаря которому нарабатывается экспертиза (преодоление «диких» условий без сторонней помощи закаляет), а также лишаете себя удовольствия от процесса (ведь кодинг это не только выдача готового кода, но и удовлетворение от становления лучшей версией себя в процессе его написания), а вот делегировать рутинные части, бойлерплейт и объяснение концепций — вполне ок для AI