Dev News от Максима Соснова
رفتن به کانال در Telegram
Привет! Меня зовут Максим Соснов и по утрам я читаю всякие разные дайджесты про фронтенд, разработку и управление разработкой. Самые интересные, по моему мнению, ссылки из этих дайджестов я кидаю в этот канал с небольшим описанием. Контакт: @msosnov
نمایش بیشتر2 784
مشترکین
-124 ساعت
+17 روز
-830 روز
در حال بارگذاری داده‌ها
کانال‌های مشابه
ابر برچسب‌ها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
اکتبر '26اکتبر '26
اکتبر '26
+25
در 0 کانال‌ها
سپتامبر '26
+30
در 0 کانال‌ها
Get PRO
اوت '26
+31
در 0 کانال‌ها
Get PRO
ژوئیه '26
+35
در 0 کانال‌ها
Get PRO
ژوئن '26
+46
در 0 کانال‌ها
Get PRO
مه '26
+46
در 1 کانال‌ها
Get PRO
آوریل '26
+41
در 0 کانال‌ها
Get PRO
مارس '26
+39
در 0 کانال‌ها
Get PRO
فوریه '26
+41
در 0 کانال‌ها
Get PRO
ژانویه '26
+31
در 0 کانال‌ها
Get PRO
دسامبر '25
+27
در 1 کانال‌ها
Get PRO
نوامبر '25
+33
در 1 کانال‌ها
Get PRO
اکتبر '25
+65
در 2 کانال‌ها
Get PRO
سپتامبر '25
+54
در 1 کانال‌ها
Get PRO
اوت '25
+52
در 0 کانال‌ها
Get PRO
ژوئیه '25
+86
در 7 کانال‌ها
Get PRO
ژوئن '25
+50
در 0 کانال‌ها
Get PRO
مه '25
+57
در 0 کانال‌ها
Get PRO
آوریل '25
+68
در 4 کانال‌ها
Get PRO
مارس '25
+79
در 2 کانال‌ها
Get PRO
فوریه '25
+72
در 2 کانال‌ها
Get PRO
ژانویه '25
+75
در 1 کانال‌ها
Get PRO
دسامبر '24
+88
در 2 کانال‌ها
Get PRO
نوامبر '24
+156
در 1 کانال‌ها
Get PRO
اکتبر '24
+96
در 1 کانال‌ها
Get PRO
سپتامبر '24
+87
در 0 کانال‌ها
Get PRO
اوت '24
+134
در 3 کانال‌ها
Get PRO
ژوئیه '24
+87
در 1 کانال‌ها
Get PRO
ژوئن '24
+111
در 0 کانال‌ها
Get PRO
مه '24
+795
در 2 کانال‌ها
Get PRO
آوریل '24
+41
در 0 کانال‌ها
Get PRO
مارس '24
+55
در 1 کانال‌ها
Get PRO
فوریه '24
+63
در 1 کانال‌ها
Get PRO
ژانویه '24
+98
در 1 کانال‌ها
Get PRO
دسامبر '23
+94
در 2 کانال‌ها
Get PRO
نوامبر '23
+31
در 1 کانال‌ها
Get PRO
اکتبر '23
+88
در 1 کانال‌ها
Get PRO
سپتامبر '23
+58
در 0 کانال‌ها
Get PRO
اوت '23
+47
در 0 کانال‌ها
Get PRO
ژوئیه '23
+36
در 0 کانال‌ها
Get PRO
ژوئن '23
+44
در 0 کانال‌ها
Get PRO
مه '23
+27
در 0 کانال‌ها
Get PRO
آوریل '23
+54
در 0 کانال‌ها
Get PRO
مارس '23
+61
در 0 کانال‌ها
Get PRO
فوریه '23
+33
در 0 کانال‌ها
Get PRO
ژانویه '23
+42
در 0 کانال‌ها
Get PRO
دسامبر '22
+35
در 0 کانال‌ها
Get PRO
نوامبر '22
+138
در 0 کانال‌ها
Get PRO
اکتبر '22
+65
در 0 کانال‌ها
Get PRO
سپتامبر '22
+114
در 0 کانال‌ها
Get PRO
اوت '22
+18
در 0 کانال‌ها
Get PRO
ژوئیه '22
+48
در 0 کانال‌ها
Get PRO
ژوئن '22
+32
در 0 کانال‌ها
Get PRO
مه '22
+15
در 0 کانال‌ها
Get PRO
آوریل '22
+4
در 0 کانال‌ها
Get PRO
مارس '22
+4
در 0 کانال‌ها
Get PRO
فوریه '22
+21
در 0 کانال‌ها
Get PRO
ژانویه '22
+64
در 0 کانال‌ها
Get PRO
دسامبر '21
+6
در 0 کانال‌ها
Get PRO
نوامبر '21
+8
در 0 کانال‌ها
Get PRO
اکتبر '21
+333
در 0 کانال‌ها
| تاریخ | رشد مشترکین | اشارات | کانال‌ها | |
| 27 اکتبر | 0 | |||
| 26 اکتبر | +2 | |||
| 25 اکتبر | 0 | |||
| 24 اکتبر | 0 | |||
| 23 اکتبر | +4 | |||
| 22 اکتبر | +1 | |||
| 21 اکتبر | +2 | |||
| 20 اکتبر | 0 | |||
| 19 اکتبر | +1 | |||
| 18 اکتبر | +2 | |||
| 17 اکتبر | 0 | |||
| 16 اکتبر | +2 | |||
| 15 اکتبر | +1 | |||
| 14 اکتبر | +1 | |||
| 13 اکتبر | 0 | |||
| 12 اکتبر | 0 | |||
| 11 اکتبر | +3 | |||
| 10 اکتبر | 0 | |||
| 09 اکتبر | +1 | |||
| 08 اکتبر | +1 | |||
| 07 اکتبر | +1 | |||
| 06 اکتبر | 0 | |||
| 05 اکتبر | 0 | |||
| 04 اکتبر | +1 | |||
| 03 اکتبر | +1 | |||
| 02 اکتبر | 0 | |||
| 01 اکتبر | +1 |
پست‌های کانال
Migrating the Shop app from React Native to native
Shopify переписали приложение Shop с React Native на Swift и Kotlin. От прототипа до публикации в сторах — 12 недель.
Shop на RN с запуска в 2020 году. С натива ушли по трём причинам:
- реализовывать фичу один раз
- не требовать для этого бэкграунда мобильной разработки под конкретную ОС
- за счёт этого ускорить доставку и держать паритет фичей
Однако оказалось, что RN тоже не без греха. Налог на обновления RN оказался большим. Я не до конца понял, что там было, но упоминаются переход на New Architecture, проблемы с анимациями и библиотеками.
В итоге прототип переезда делал один iOS-инженер одну неделю. По готовому коду RN собирались нативные экраны. Это оказалось далеко не идеальным решением, но оно показало, что переписывание в короткие сроки в целом реально.
Как и все современные миграции, конечно же делали через AI-агентов.
Процесс такой:
- Сделали расширение для Pi
- Субагенты разбирают RN-исходники экрана, декомпозируют их на стейт, UI, навигацию и т. д. и пишут план миграции
- Человек принимает план
- Далее агенты переписывают экран на нативные технологии и проверяют, что логи, стейт и скриншоты на чекпоинтах не изменились
Какие итоги.
Холодный старт, от тапа по иконке до ленты на главной:
- iOS: 3200 → 2466 мс (−23%)
- Android: 4433 → 2233 мс (−50%)
Стабильность сессий 99,5% → 99,95%.
Размер релиза: Android 293 → 184 МБ, iOS 67 → 68 МБ.
Релизный билд Android быстрее примерно на 75%, на iOS время то же.
Лента на Pixel идёт в 120 FPS, отдельных оптимизаций почти не было.
А главное, что блокер, который был актуален в 2020 году, а именно необходимость писать и поддерживать 2 версии кода, более не актуален, т.к. код пишут ИИ-агенты. Достаточно сделать одно работающее решение, а далее ИИ-агенты, если сделать им хороший процесс вокруг разработки, спокойно его адаптируют под любую платформу.
Если раньше узким горлышком было написание кода, то теперь — его ревью и проверка решения.
Я не уверен, что это так классно в реальности, как это звучит в статье. Как минимум видна очень большая подготовительная работа для этого процесса: свои инструменты, пайплайны. Но даже с ним не уверен, что всё идёт вот так вот гладко.
С другой стороны, кейсов переписывания приложения на другой стек становится всё больше и больше. Недавно читал даже кейс, где чел писал софт под железки и подумал «а зачем мне код на читаемом языке, если его всё равно генерирует агент» и заставил агента писать сразу на самом низком уровне (то ли ассемблер, то ли сразу инструкции).
https://shopify.engineering/shop-app-migration
https://shopify.engineering/back-to-native
#development #react-native #shopify #mobile #ai
| 2 | Fixing INP in a Massive React Dropdown
В Subito был дропдаун, в котором 1175 пунктов, и он рендерился оооооооочень долго (1256 мс), что, естественно, негативно влияло на метрику INP. Решение простое и очевидное — использовать виртуальный скролл.
Меню на react-select при открытии монтировало все 1175 опций, хотя на экране помещается около шести. Написали хук useVirtualScroll на 90 строк: меряют высоту одной строки и рисуют видимое окно плюс буфер в 5. После этого вместо 1175 элементов в DOM стало 13, а INP упал до 96 мс.
Простая проблема, достаточно очевидное решение через виртуализацию.
https://dev.to/subito/from-1256ms-to-96ms-fixing-inp-in-a-massive-react-dropdown-16l7
#development #react #performance #inp | 647 |
| 3 | Why (and How) GitHub Ported Copilot's Runtime from Node to Rust
Огромная статья от GitHub про переписывание рантайма Copilot (800 тысяч строк кода) с TypeScript на Rust.
Рантайм GitHub Copilot — это по сути SDK для запуска agent harness, который используется в GitHub Copilot CLI, GitHub Copilot App, VS Code, Visual Studio и ещё куче приложений. Все они вынуждены были тащить Node.js-рантайм для запуска agent harness.
Это означает и потребление избыточной памяти на движок V8 (около 100 МБ), и жёсткую зависимость от Node.js: падает Node.js — падает весь агент.
Каким требованиям должна была удовлетворять целевая платформа:
- минимум зависимостей и оверхеда от языка и экосистемы
- возможность встроиться в процесс
- язык, на котором проще сделать быстрое, масштабируемое и отказоустойчивое решение
- лёгкий интероп с C#, TypeScript, Python, Rust, Go, Java
- современный тулинг, который учитывает безопасность
По итогу выбрали Rust.
Миграция проходила покомпонентно. Берётся TS-код, переписывается на Rust, подключается через napi и прогоняются все e2e-тесты. Если тесты проходят, компонент на Rust вливается в main.
Как проходило переписывание: автор запускал рой агентов и с мая по 21 августа открыл 128 пул-реквестов. Каждый агент работал в своём worktree. Крупные задачи делили на более мелкие и запускали в отдельных сессиях.
Проверка результата также была по максимуму автоматизирована:
- Сначала агенты проводят код-ревью: построчно сравнивают обе версии кода, e2e-тесты менять нельзя, должна остаться только тонкая TS-прослойка
- Далее человек смотрит, что агент всё верно сделал. Были кейсы, когда агенты пытались обмануть систему
Всё переписывание заняло 3,5 месяца. Автор оценивает свою занятость в 3 недели, т.к. параллельно занимался ещё другими задачами. Счёт за токены моделей составил $120 тысяч. При этом 96% токенов прочитаны из кеша. Боюсь представить цифру без такого эффективного cache read.
Какой по итогу результат.
Скорость работы без сети и без инференса. Старт клиента, сессия и один ход:
- Node: 5,25 с
- Rust отдельным процессом: 1,33 с
- Rust внутри процесса: 292 мс
Потребление памяти на десятке клиентов, пик сверх базового:
- Node: +1383 МБ
- Rust отдельным процессом: +247 МБ
- Rust внутри процесса: +126 МБ
Также в статье куча графиков и таблиц: таймлайны, размеры пул-реквестов, скорость изменения кода. Очень крутая инфографика.
Важные уроки, которые выделяет автор этой миграции:
- Нужно задавать цель целиком: рантайм на 100% Rust, без оставшегося TypeScript. Изначально агенты решали задачу «переписать код на Rust», и получалось плохо.
- Агентам нельзя менять e2e-тесты, т.к. это единственный способ понять, что всё действительно работает как раньше.
- Сначала код переписывается as is, а только потом меняются подходы и алгоритмы под новый язык. Нарушение этого правила приводило к проблемам.
- Повторяющиеся проблемы надо уносить в скиллы и инструкции, чтобы они не всплывали в следующих PR.
- С агентами узким местом становится не написание кода, а сборка проекта и запуск автотестов. Агент очень быстро пишет код и потом долго ждёт результатов запуска тестов.
https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot
#development #rust #nodejs #copilot #ai #performance | 745 |
| 4 | Дайджест за 2026-10-12 - 2026-10-16
Improving site performance by shipping more CSS
GitHub улучшил перформанс, переведя код со styled-components на чистый CSS.
Electron to PWA: There and Back Again
Автор год собирал EPUB-редактор на Electron, потом около полугода переписывал его в PWA и вернулся обратно.
Responsive iframes in Chrome 154
В Chrome 154 добавили возможность автоматически подстраивать размер iframe под контент внутри. Годами разработчики делали связку через postMessage с передачей текущего размера и установкой этого размера iframe, но теперь жизнь может стать немного проще.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 698 |
| 5 | Responsive iframes in Chrome 154
В Chrome 154 добавили возможность автоматически подстраивать размер iframe под контент внутри. Годами разработчики делали связку через postMessage с передачей текущего размера и установкой этого размера iframe, но теперь жизнь может стать немного проще.
Чтобы автоматический ресайз работал, необходимо сделать несколько простых шагов.
Первый: в родительском документе установить frame-sizing.
iframe {
width: 100%;
frame-sizing: content-height;
}
Второй: во встроенном документе установить особый meta-тег.
<meta name="responsive-embedded-sizing" content="allow-origins=*">
Третий: из iframe вызывать window.requestResize() для обновления размера в родительском окне. Это нужно, чтобы избежать бесконечного цикла ререндера.
https://developer.chrome.com/blog/responsive-iframes
#development #chrome #css #iframe | 931 |
| 6 | Electron to PWA: There and Back Again
Автор год собирал EPUB-редактор на Electron, потом около полугода переписывал его в PWA и вернулся обратно.
Переезд на PWA рассматривался по нескольким причинам.
Первая — это размер Chromium, который требуется бандлить в бинарь при создании Electron-приложения. Это примерно 250 МБ. Однако автор сразу же пишет, что это не такая важная проблема, т.к. вкладка Twitter съедает гораздо больше.
Вторая — это DX разработки на Electron. Electron слишком низкоуровневый и застрял в нулевых по уровню DX: устоявшихся паттернов нет, HMR нет, удобного управления окнами нет и прочее. Есть проекты типа electron-builder и electron-vite, но они не сильно помогают.
PWA же выглядит как хорошее решение: все DX-плюшки веб-разработки доступны, а также никакого налога на оболочку и возможность установить приложение на телефон.
Выглядит хорошо, но оказалось, что у PWA тоже есть проблемы:
- File System API и OPFS сделаны очень хорошо, но настройка ассоциаций файлов и параметров запуска сделана не очень хорошо
- Кроме того, достаточно быстро автор зарепортил 2 бага в базовом API для PWA
- PWA работает по-разному в разных браузерах, и у разработчика не так много возможностей сказать пользователю, чтобы он установил PWA из правильного браузера
- Окна приложений на десктопе сделаны криво, и нет возможности сделать нормально
- Нельзя кастомизировать меню в трее или доке
- Нельзя сделать системные хоткеи
- Нельзя сделать хоткеи Cmd+Q и Cmd+S, которые зарезервированы за браузером (хотя Cmd+Q — системный хоткей уровня Alt+F4)
- Нельзя интегрировать PWA в системные фичи вида «открой файл через приложение»
В итоге вернулся к Electron.
В целом вывод такой:
Если вам не нужны фичи Electron в виде интеграций с ОС, то берите PWA — DX лучше, кода меньше, тестировать проще.
https://kettanaito.com/blog/electron-to-pwa-and-back-again
#development #electron #pwa #desktop | 899 |
| 7 | Improving site performance by shipping more CSS
GitHub улучшил перформанс, переведя код со styled-components на чистый CSS.
В чём суть. Есть Primer — библиотека компонентов GitHub: кнопки, баннеры, крошки. Все стили в ней были реализованы через CSS-in-JS.
Использование CSS-in-JS негативно сказывается на перформансе:
- на первом заходе стили инициализируются в браузере
- сбор стилей на сервере тормозит SSR
- да и вообще все стили вместо простой вставки в браузер каждый раз надо рассчитывать на каждый рендер компонента
Решение проблемы достаточно наивное — использовать CSS Modules.
Переписывание Primer проводили покомпонентно и безопасно. Сначала перевели все внутренние стили на чистый CSS, и это уже ускорило SSR на 55%, а инициализацию компонентов на 25%.
Но остались использования CSS-in-JS в местах вызова Primer-компонентов, где использовались возможности CSS-in-JS для кастомизации поведения. Поэтому следующим шагом было опубликовать 2 вариации библиотеки Primer — с поддержкой CSS-in-JS и на чистом CSS.
Переход на чистый CSS в местах вызова занял ещё где-то полгода, и в июне 2026 года GitHub полностью на CSS Modules.
В целом очевидная проблема и очевидное решение. Полезно, что есть реальные цифры налога на использование CSS-in-JS.
https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css/
#development #css #performance #github #react #css-in-js | 911 |
| 8 | How we made claude.ai 3x faster in two weeks
Пользователи жаловались на проблемы с перформансом claude.ai и десктопного приложения Claude. Anthropic за две недели ускорили оба продукта примерно в три раза.
Результаты двухнедельной работы (цифры — p75):
- время до возможности печатать при свежей загрузке сайта: 3.1 с → 0.55 с
- новая сессия Claude Code: 0.8 с → 0.3 с
- загрузка облачной сессии Cowork: 2.6 с → 0.73 с
Как и что они делали.
Во-первых, взяли 4 основных пользовательских сценария, скорость которых оптимизировали:
- Открыть приложение
- Начать чат
- Открыть старый чат
- Отправить сообщение
Сам процесс оптимизации примерно следующий:
- В Slack создаётся тред с агентом, где разработчик ставит задачу по оптимизации
- Агент исследует, находит проблемы, приносит решения. Человек их смотрит
- Все проблемы и решения сначала подтверждаются локально: сначала формируется перформанс-бенчмарк, который красный на текущем коде, а после фикса должен стать зелёным
- Если чего-то не хватает — агент дополнительно инструментирует код
- Рискованные изменения раскатываются не сразу на всех пользователей, а поэтапно
Сами оптимизации и исследование достаточно сложные. Я бы сказал, что ни я, ни кто-то из моих коллег так глубоко бы не копал, чтобы ускорить сайт. Чтобы понять, почему я так считаю, достаточно взглянуть на то, что сделано в рамках исследования проблем.
Замер обычного времени выполнения и отрисовки плавает в зависимости от нагрузки CPU, сети, GC и других факторов. Поэтому анализ делался на следующих метриках:
- Количество инструкций CPU, которые понадобились для прохождения сценария
- Количество вызовов функций JS
- Коммиты React
- Пересчёт стилей
- Мутации DOM
Чтобы сделать тесты на инструкции CPU детерминированными, гоняли Node с флагом --predictable: одно и то же выполнение даёт одинаковое расписание GC и компиляции, поэтому число инструкций стабильно от прогона к прогону.
Также обычных метрик кое-где не хватило. Например, CLS не ловил дёрганье сайдбара, поэтому добавили свои события через Layout Instability API.
Отдельно собрали стенд Chrome на 120 Hz, чтобы убедиться, что отрисовка стрима длинного ответа не проседает ниже 120 fps.
Что сделано в рамках улучшения перформанса:
- Пока React не инициализировался, поле ввода уже доступно как статический HTML. Затем React рендерит приложение поверх без миганий, потери ввода и сдвигов лейаута (отдельными тестами проверяют, что нет сдвига ни на пиксель)
- Нашли селектор :root:has(), из-за которого каждое изменение DOM вело к лишним 24 мс пересчёта стилей
- Удалили забытый location.reload() — он давал около полумиллиона скрытых перезагрузок в день, которые обычные load-метрики не видели
- Подсветка кода зависала примерно на секунду из-за em dash: любой non-Latin-1 символ клал всю строку в UTF-16, и regex шли по медленному двухбайтовому пути. Фикс на 20 строк — скопировать блок кода в однобайтовую строку до подсветки
- Зашили code cache V8 в десктопное приложение, чтобы приложик сразу работал с байткодом, а не компилировал JS каждый раз при открытии
- После ускорения обнаружили кейс с пререндером. Когда в адресной строке вводишь сайт, Chrome уже рендерит страницу в фоне, но может сделать это не с той высотой (на корпоративных устройствах часть высоты пустого таба забирает плашка «браузер управляется политиками компании»). До ускорения рендера этого не замечали, после ускорения — пришлось фиксить
Чтобы не было деградации, перформанс-бенчмарки повесили в CI — так меньше шансов потом уронить скорость.
Как итоги:
- Ускорение в 3 раза
- 3000 мерджей
- 200 изменений в день
- 150 тредов с агентом
Ну, а в целом итог такой:
- Раньше ускорение сайта это была работа на недели, а то и месяцы и с результатом можно было идти с докладом на конференцию
- Теперь достаточно оплатить подписку для любого агента и он за короткий срок сделает тот же результат, что делает человек за месяц работы
https://claude.dev/blog/how-we-made-claude-ai-faster
#development #performance #claude #ai #frontend #observability | 1 168 |
| 9 | Дайджест за 2026-09-07 - 2026-09-09
Playwright v1.62.0
Вышел релиз Playwright 1.62. Обычно я не пишу про релизы Playwright, но тут важное событие — допилили component testing. Текущее решение чем-то похоже на описание компонентов для Storybook.
Mobile View — see your site on desktop & mobile at once
Расширение для Chrome от подписчика — Mobile View. Позволяет легко посмотреть, как сайт выглядит на мобильном устройстве, в разных ориентациях, со снятием скриншотов, видео и прочими фичами. Можно запустить сразу 5 эмуляций в рамках одной сессии. Попробовал сам — выглядит действительно супер удобно и прям красиво.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. | 1 157 |
| 10 | Mobile View — see your site on desktop & mobile at once
Расширение для Chrome от подписчика — Mobile View. Позволяет легко посмотреть, как сайт выглядит на мобильном устройстве, в разных ориентациях, со снятием скриншотов, видео и прочими фичами. Можно запустить сразу 5 эмуляций в рамках одной сессии. Попробовал сам — выглядит действительно супер удобно и прям красиво.
Это, конечно, не полноценный симулятор, но решение очень хорошее как для тестирования, так и для демонстрации.
Строго рекомендую хотя бы ознакомиться.
https://mobileview.app/
#development #chrome #tools #responsive #frontend | 1 310 |
| 11 | Playwright v1.62.0
Вышел релиз Playwright 1.62. Обычно я не пишу про релизы Playwright, но тут важное событие — допилили component testing. Текущее решение чем-то похоже на описание компонентов для Storybook.
Забавно, что инструкция по установке начинается с «запустите LLM». Буквально.
> Step 1: Point your coding agent at the skill
npx playwright init-skills
Set up component testing using the playwright-component-testing skill.
Затем надо немного сконфигурировать конфиг Playwright.
Затем создать давно знакомые нам stories-файлы
src/components/Button.story.tsx
import { Button } from './Button';
export const Primary = () => <Button title='Submit' />;
export const Disabled = () => <Button title='Submit' disabled />;
Т.е. по сути один в один истории Storybook. Интересно, не будет ли конфликтов? Пока выглядит, что Playwright-сборка должна будет уметь обрабатывать и исполнять все плагины и декораторы Storybook, либо придётся как-то делить истории Storybook и истории Playwright.
Затем пишем тесты
import { test, expect } from '@playwright/test';
test('renders primary button', async ({ mount }) => {
const component = await mount('components/Button/Primary');
await expect(component.getByRole('button')).toHaveText('Submit');
});
test('disabled button is disabled', async ({ mount }) => {
const component = await mount('components/Button/Disabled');
await expect(component.getByRole('button')).toBeDisabled();
});
Затем запускаем
npx playwright test --project=components
В доке также описаны ещё основные паттерны для тестирования. На них останавливаться не буду.
Надо будет попробовать в своём пет-проекте.
https://github.com/microsoft/playwright/releases/tag/v1.62.0
#development #playwright #testing #component-testing #releaseNotes | 1 124 |
| 12 | Дайджест за 2026-08-31 - 2026-09-04
How to find a Next.js memory leak in production
Очень хорошая и практичная статья про утечки памяти в Next.js. Чел рассмотрел 3 утечки (которые уже исправлены — поэтому обновляйтесь) и то, как их правильно диагностировать.
Canvas UI
Canvas UI — open-source библиотека готовых компонентов для создания красивых эффектов на основе технологии html-in-canvas, которая пока что включена только в Chrome и там за флагом. Эффект стекла, жидкости, VHS и другие готовые эффекты, оформленные как компонент, в который можно обернуть ваш HTML.
Measuring soft navigations
Web Vitals стали основным мерилом скорости работы сайтов. Но при этом Web Vitals плохо покрывают сценарии с SPA-переходами. Из-за этого почти никто не следил за скоростью работы сайтов при SPA-переходах. Но Google придумали методику для замеров SPA-переходов, и в новом Chrome за флагом доступны метрики Soft Navigations.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. | 871 |
| 13 | Measuring soft navigations
Web Vitals стали основным мерилом скорости работы сайтов. Но при этом Web Vitals плохо покрывают сценарии с SPA-переходами. Из-за этого почти никто не следил за скоростью работы сайтов при SPA-переходах. Но Google придумали методику для замеров SPA-переходов, и в новом Chrome за флагом доступны метрики Soft Navigations.
Что определяется как soft navigation:
1. Действие перехода инициировал пользователь
2. Пользователь видит изменение URL
3. Есть видимое изменение (paint)
Спека пока обсуждается, поэтому могут быть изменения. На странице очень подробно описано, какие изменения будут у записей в Performance API (новые типы Entry + navigationId для идентификации метрик каждой отдельной страницы), как их включить, обрабатывать и мониторить.
Очень большой и подробный гайд. Ждём стабилизации.
https://developer.chrome.com/docs/web-platform/soft-navigations
#development #chrome #performance #web-vitals #spa #browser | 866 |
| 14 | Canvas UI
Canvas UI — open-source библиотека готовых компонентов для создания красивых эффектов на основе технологии html-in-canvas, которая пока что включена только в Chrome и там за флагом. Эффект стекла, жидкости, VHS и другие готовые эффекты, оформленные как компонент, в который можно обернуть ваш HTML.
Вместо тысячи слов лучше пройти по ссылке и посмотреть, как это выглядит. А выглядит это прям бомбически.
Также в библиотеке предусмотрено graceful degradation для браузеров, где не включен html-in-canvas, но результат может быть хуже.
https://canvasui.dev/
#development #webgl #canvas #ui #react #frontend | 982 |
| 15 | How to find a Next.js memory leak in production
Очень хорошая и практичная статья про утечки памяти в Next.js. Чел рассмотрел 3 утечки (которые уже исправлены — поэтому обновляйтесь) и то, как их правильно диагностировать.
Если ваше приложение использует Next.js версии между 15.5 и 16.2, то в них есть 3 задокументированных утечки памяти. Вот как их диагностировать:
1. Если утечка медленная и коррелирует с количеством уникальных урлов, которые обслужило приложение, то это утечка Router LRU-кеша
2. Если утечка пропорциональна трафику, то вполне вероятно это утечка дерева рендеринга
3. Если утечка не плавная, а ступеньками, а запросы обрабатываются через middleware, то это утечка айдишников таймаутов
Немного подробнее про каждую утечку.
№1: У роутера в Next.js есть LRU-кеш, и его размер ограничен одним мегабайтом. Но размер определяется некорректно. Собственно сами урлы и не учитываются, что даёт возможность для утечки на сотни мегабайт. Банально любой бот, который перебирает урлы, вызовет эту утечку. Если не можете обновиться — отфильтровывайте урлы до их обработки роутером Next.js.
№2: Дерево RSC-рендера не освобождается, если клиент разорвал соединение. Утечка может достигать 2 МБ на 1 отменённый запрос (что вообще-то нехило).
№3: У middleware отдельный TimeoutsManager, который хранит id таймаутов. id отпускается только если явно вызвать clearTimeout.
А дальше интересный личный кейс автора. У него приложение крутилось как serverless на Vercel, поэтому вместо OOM он получал 504 FUNCTION_INVOCATION_TIMEOUT на tag-страницах блога.
Автор провёл расследование. Сначала подозревал рендер MDX, но оказалось, что он достаточно быстрый — до 100 мс. Оказалось, что причина в функции, которая резолвила slug для страницы. Чтобы зарезолвить один единственный slug, функция грузила и парсила все посты для каждого слага, что давало квадратичную сложность и выливалось в 18 тысяч чтений с диска и 30 секунд на рендер.
Фикс простой: вместо парсинга всех постов на каждый запрос — распарсить единожды и сложить в кеш на инстанс. Скорость работы после исправления:
- next build: ~17.5 мин → 34 сек
- prerender поста: ~32 сек → ~1.6 сек
- on-demand tag page: 504 → ~134 мс
Для поиска утечек автор собрал CLI `next-leak`, который автоматизирует диагностику.
Также отдельно отмечу, что у автора очень красиво задизайнен блог. Не знаю, готовая ли это тема или он сам собрал — но выглядит очень красиво.
https://xabierlameiro.com/blog/nextjs/nextjs-memory-leak-in-production
#development #nextjs #memory #performance #debugging | 934 |
| 16 | Дайджест за 2026-08-24 - 2026-08-28
Check out the New Node.js API Documentation Preview
Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org.
When and what should I be logging?
Sentry написали гайд «когда и что логировать». Гайд не прям чтобы открывал глаза на какие-то новые концепции, но как интро вполне норм.
We Stopped Using RSC on TanStack.com
История о том, почему на tanstack.com отказались от RSC. Сначала перешли на RSC и стало лучше, а потом поняли, что можно было оптимизировать изначальное решение — и тогда бы RSC не понадобился.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 773 |
| 17 | We Stopped Using RSC on TanStack.com
История о том, почему на tanstack.com отказались от RSC. Сначала перешли на RSC и стало лучше, а потом поняли, что можно было оптимизировать изначальное решение — и тогда бы RSC не понадобился.
Как было. Есть сайт с докой, в которой используются тяжёлые библиотеки для рендера markdown и подсветки синтаксиса. Суммарно эти библиотеки занимали 358 КБ.
Как сделали. Включили RSC, тяжёлые библиотеки остались на сервере, на клиент идёт сразу готовый рендер. И перформанс-метрики сразу подскочили. Но позже оказалось, что RSC несёт свои проблемы и неудобства.
Затем инженеры подумали, что переход на RSC — это, возможно, было неверное решение. Перенесли рендер на бэкенд вместо того, чтобы оптимизировать сами тяжёлые зависимости.
Что переделали. Взяли более лёгкие библиотеки, допилили их и вернулись на обычный SSR. Получили заметное ускорение работы + упрощение архитектуры.
Какой итог:
- RSC хорош для решения проблемы с «тяжёлым» кодом
- Но он даёт сложность. Если есть вариант обойтись без RSC — стоит рассмотреть этот вариант.
https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com
#development #react #rsc #tanstack #performance #ssr | 933 |
| 18 | When and what should I be logging?
Sentry написали гайд «когда и что логировать». Гайд не прям чтобы открывал глаза на какие-то новые концепции, но как интро вполне норм.
Итак, что надо логировать:
Runtime decisions. В коде часто есть ветвление по различным условиям — по условиям типа isMobile, по фичефлагам. Вот все эти условия нужно логировать, чтобы понимать, как работал код в каждом конкретном случае. Например, логировать конфигурацию фичетогглов.
Шаги в многошаговых фичах. Например, есть какой-то последовательный долгий процесс. В этом случае лучше логировать каждый шаг и его результат.
Аудит. Если пользователь или система делает какое-то действие, необходимо логировать, кто и что сделал. Любые создания, обновления и удаления сущностей.
Контекст вокруг ошибок. Недостаточно просто залогировать ошибку. Нужно логировать весь контекст, в котором она произошла — какой это был ретрай, какой статус-код, какой URL и всё остальное, что может помочь при дебаге.
Как писать логи:
Используй структурированные логи. Не просто строка в логах, а структура. Например, JSON-объекты. В идеале логи должны содержать ответы на вопросы «что произошло?», «кто это сделал?» и «когда это произошло?».
Наращивай контекст логов. Сначала пользователь может быть неавторизован, но когда он авторизовался — его данные (userId, например) должны попадать в контекст последующих логов. Отдельно полезно делать связь логов через трейсинг.
Что не надо логировать
Избыточное логирование. Не надо логировать вызов всех функций и всех строчек кода.
Секреты и персональные данные. Тут в целом всё понятно.
Большой объём данных без чёткой цели. Тут тоже, думаю, понятно. Хотя, если бы не было проблемы с хранением и обработкой больших данных, то думаю, этого пункта не было бы.
https://blog.sentry.io/logging-best-practices/
#development #logging #observability #sentry #best-practices | 998 |
| 19 | Check out the New Node.js API Documentation Preview
Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org.
https://beta.docs.nodejs.org
#development #nodejs #documentation #dx | 880 |
| 20 | Дайджест за 2026-08-17 - 2026-08-21
postmortem.io · the library of real postmortems
postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов.
The secure way to release an npm package in 2026
Огромная статья от Evil Martians про то, как в 2026 публиковать npm-пакеты, чтобы их было сложнее угнать. В статье в самом начале есть чеклист, что надо сделать, чтобы снизить вероятность кражи пакета. А после чеклиста — почему именно важен каждый шаг и как выстраивается система защиты.
npm publish-time malware scanning and dual-use metadata
npm включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 881 |
