@github-ui/storybook-addon-performance-panel

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

https://github.com/github/storybook-addon-performance-panel

#development #javascript #storybook #performance

fetch-network-simulator

fetch-network-simulator - библиотека, которая позволяет симулировать проблемы с сетью при работе с fetch.

Что можно делать:
- Повышать задержку
- Терять пакеты
- Автоматические ретраи
- Ответы приходят в порядке, отличном от порядка запросов (полезно для вскрытия кейсов, когда приложение ожидает, что при отправке двух запросов А и Б, ответы точно придут в том же порядке)
- Ограничение на параллельность

Все это настраивается прямо в JS коде. Выглядит интересно: можно посмотреть как будет работать сайт при наличии различных сетевых проблем и найти какие-то проблемы в самом сайте. DevTools делают что-то похожее, но не все (потерю пакетов там, вроде бы, не эмулировать).

Настройка библиотеки выглядит так

import { enableNetworkSimulator } from "fetch-network-simulator";

if (process.env.NODE_ENV === "development") {
  enableNetworkSimulator({
    debug: true, // optional: structured request lifecycle logs

    latency: { enabled: true, delayMs: 1500 },
    packetLoss: { enabled: true, lossRate: 0.3 },
    retry: { enabled: true, maxAttempts: 3, retryDelayMs: 200 },
    staleResponse: { enabled: true, staleProbability: 0.5 },
    burstControl: { enabled: true, maxConcurrent: 1 },
    networkSpeed: { enabled: true, kbps: 500 }
  });
}

https://github.com/thisiskps/fetch-network-simulator

#development #javascript #fetch #performance

Electrobun v1

Год назад я в канале писал, что анонсировали разработку Electrobun - это Electron, но поверх bun. И вот теперь вышел Electrobun v1

Какие изменения:
1. Автор уже завез один свой проект на Electrobun. Получается уже можно сделать что-то рабочее
2. Поддержка macos, windows, ubuntu
3. Своя реализация OOPIF (Out Of Process IFrame) для вставки webview. Про создание своего OOPIF есть отдельная статья

https://blackboard.sh/blog/electrobun-v1/

#development #javascript #bun #electron #electrobun

WebMCP is available for early preview

Текущие ИИ-агенты плохо взаимодействуют с сайтами. Что, в общем-то, не удивительно. Если зайти на почти любой сайт и попробовать поработать с его html, то можно сойти с ума от сложности html-структуры. Поэтому ИИ-агентам приходится или работать со скриншотами, или пытаться взаимодействовать со сложным html. Google принес решение - WebMCP

WebMCP пока в супер ранней стадии. WebMCP предполагает два API, которые могут реализовать сайты для ИИ-агентов:
1. Декларативное API. Грубо говоря, разметить HTML чтобы агенты могли заполнять там формы
2. Императивное API. Грубо говоря, предоставить функции, которые ИИ-агент может дернуть для получения какого-то результата (считай tool)

Т.е. как это должно работать:
1. Вы предоставляете API для ИИ-агентов
2. ИИ-агенты, когда заходят на ваш сайт, находят это API
3. Для выполнения запроса пользователя агенты начинают использовать API

Ждем, куда это в итоге придет. Если все большие компании, разрабатывающие агентов, подтвердят что это хорошее решение, то, видимо, скоро будем писать API для ИИ-агентов.



https://developer.chrome.com/blog/webmcp-epp

#development #mcp #webmcp #aiAgents #chrome

Всем привет!

23 марта запустится новая Podlodka React Crew - онлайн-конференция про разработку с React. Классический для подлодки формат - каждый день с 23 по 27 марта один доклад утром, один доклад вечером.

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

Мои коллеги, которые посещали прошлые Podlodka React Crew, очень позитивно отзывались как о формате, так и о докладах.

Доклады затрагивают самые разные области работы с React:
- Про модные фичи в React (серверные комопненты, новые api)
- Про базовую базу в React приложениях (бест практисы и современные паттерны)
- Про старые добрые микрофронтенды
- Про перформанс: поиск проблем и их решение
- Про безопасность
- Про AI (куда же без этого)

В общем, хорошая онлайн конфа с разносторонними темами. Цены не грабительские - если интересно, рекомендую сходить. Скоро разберусь с ботами для розыгрышей и разыграем проходку через бота.

Дайджест за 2026-03-02 - 2026-03-13

wc3ui - библиотека компонентов в стиле wc3
Битва UI-китов закончена. Наконец-то нашелся ультимативный ui-kit, предоставляющий компоненты как в warcraft III. Гонка ui-kit'ов потеряла смысл с таким игроком.

@github-ui/storybook-addon-performance-panel
Аддон для storybook, который собирает и отображает в интерфейсе storybook метрики производительности компонентов. Новый Must-Have среди сторибучных аддонов для всех проектов. Должен помогать находить критичные проблемы рендера на ранних этапах и в изолированной среде.

fetch-network-simulator
fetch-network-simulator - библиотека, которая позволяет симулировать проблемы с сетью при работе с fetch.

Electrobun v1
Год назад я в канале писал, что анонсировали разработку Electrobun - это Electron, но поверх bun. И вот теперь вышел Electrobun v1

WebMCP is available for early preview
Текущие ИИ-агенты плохо взаимодействуют с сайтами. Что, в общем-то, не удивительно. Если зайти на почти любой сайт и попробовать поработать с его html, то можно сойти с ума от сложности html-структуры. Поэтому ИИ-агентам приходится или работать со скриншотами, или пытаться взаимодействовать со сложным html. Google принес решение - WebMCP

Анонс новой Podlodka React Crew
Новый запуск подлодки про React. На борту: модные фичи, бест практисы, микрофронтенды, AI, перформанс и безопасность
——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Fastest Frontend Tooling for Humans & AI

Статья про замену инструментов вокруг разработки на более быстрые. Во-первых, это полезно разработчикам. А во-вторых, это ускоряет работу ИИ-агентов.

Что предлагает автор:
Первое - уже переехать на typescript, написанный на go (tsgo). Сам автор уже полгода сидит на tsgo и очень доволен т.к. tsgo в 10 раз быстрее. Также говорит, что tsgo находит ошибки, которые не находит обычный tsc

Миграция:
- npm install @typescript/native-preview
- Удалить легаси-флаги конфига TS
- Заменить все вызовы tsc на tsgo
- Добавить "typescript.experimental.useTsgo": true в конфиг vscode

Второе - переехать на oxfmt вместо prettier. Oxfmt это более быстрая реализация prettier с кучей встроенных плагинов. Также oxfmt фолбечится до prettier для обработки файлов не на JS/TS.

Миграция через ИИ-агента:
> Migrate this project from Prettier to Oxfmt. Read https://oxc.rs/docs/guide/usage/formatter/migrate-from-prettier.md. Update all scripts, tools, and hooks to use Oxfmt. Remove all Prettier configuration files and reformat the code using Oxfmt.

Также полезным будет установить расширение для vscode
code --install-extension oxc.oxc-vscode.

Третье - переехать на oxlint вместо eslint. Oxlint умеет запускать eslint плагины внутри себя, что позволяет переехать на более быстрый линтер, не потеряв при этом богатую экосистему плагинов

Миграция также через ИИ-агента
> Migrate this project from ESLint to Oxlint. Read https://oxc.rs/docs/guide/usage/linter/migrate-from-eslint.md. Update all scripts, tools, and hooks to use Oxlint. Remove all ESLint configuration files. Lint the code and fix any lint errors.

Также автор собрал свой конфиг для линтера, который вы можете поставить. Сам конфиг не интересен, но интересны принципы, которые лежат в основе конфига:
1. Только ошибки, никаких предупреждений.
2. Строгий, консистентный код-стайл.
3. Предотвращение багов (запрет любых конструкций, которые могут к ним привести)
4. Только быстрые правила. Медленные отключаются
5. Субъективные правила отключены (например, влияющие на стиль написания кода)

Эти правила уменьшают двусмысленность, что полезно при ИИ-кодинге.

Также из быстрого инструментария:
1. npm-run-all2 - команда для запуска других команд в параллель
2. ts-node + swc

Звучит интересно. Кто-то уже пробовал tsgo и oxlint?

https://cpojer.net/posts/fastest-frontend-tooling

#development #javascript #eslint #typescript #oxlint #prettier

Разыгрываем билет на Podlodka React Crew, проходящую с 23 марта по 27 марта.

Дайджест за 2026-03-16 - 2026-03-20

Fastest Frontend Tooling for Humans & AI
Статья про замену инструментов вокруг разработки на более быстрые. Во-первых, это полезно разработчикам. А во-вторых, это ускоряет работу ИИ-агентов.

——————————————

Can't Maintain. Can you spot the better API?

"Не поддерживаемый" (Can't maintain) - сайт с короткими квизами, где надо выбрать более поддерживаемый вариант реализации JS или React-кода. При ответе краткий экскурс, почему один из вариантов более поддерживаемый, чем другой. Очень залипательный сайт.

https://cant-maintain.saschb2b.com

#development #javascript #quiz #react

Why is WebAssembly a second-class language on the web?

WebAssembly развивается с 2017 года, но все еще не стал полноценной частью веб-экосистемы. В статье Ryan Hunt объясняет, какие проблемы есть у современного WASM и что надо изменить, чтобы wasm стал популярен у разработчиков

Есть 2 основные проблемы, делающие WASM "неудобным":
1. Код из WASM не может напрямую работать с Web API. Для этого нужна JS прослойка, которая будет мостиком между WASM и Web API
2. WASM код нельзя загрузить никак, кроме как из JS-кода (что является следствием первой проблемы)

Вторую проблему уже решают в пропозале esm-integration. Он позволяет загружать wasm-модули как обычные js-модули

import { run } from "/module.wasm";

run();

<script type="module" src="/module.wasm"></script>

Но необходимость прослойки для работы с Web API все еще делает неудобной работу с Web API. Можно писать эту прослойку самому, но это а) не самая тривиальная работа; б) требует одновременно компетенций как в wasm, так и в web. Можно использовать embind или wasm-bindgen, но там тоже есть свои нюансы

Компиляторы, собирающие нативный код в WASM, не занимаются сборкой JS-кода для интеграции wasm в web-api - они лишь собирают wasm, а дальше разработчик сам должен написать мостик между WASM и Web API, если это требуется для приложения.

Также есть проблема, что даже если написать такой мостик, то от этого пострадает перформанс. В классическом бенчмарке TodoMVC wasm+JS оказался почти в 2 раза медленнее, чем wasm-код с доступом к web api.

Как решение этой проблемы предлагается WebAssembly Component - пропозал, разрабатываемый с 2021 года

WebAssembly Components:
- Могут быть созданы из разных языков программирования
- Могут быть запущены в разных рантаймах
- Могут использовать друг друга
- Могут напрямую вызывать Web API

Это позволит снизить порог входа для интеграции WASM в приложения.

https://hacks.mozilla.org/2026/02/making-webassembly-a-first-class-language-on-the-web/

#development #javascript #web #wasm

How we Rewrote 130K Lines from React to Svelte in Two Weeks

Команда strawberry за 2 недели переписала 130к строчек кода с React на Svelte с применением ИИ-агентов. Интересный кейс, про который можно и почитать. Хотя, конечно, тот факт, что ИИ-агенты хорошо справляются с переписыванием - давно не новость

Почему вообще понадобилось переезжать с React:
1. Strawberry использует несколько отдельный рендереров для разных компонентов своего браузера. Каждый компонент - отдельное React-приложение. Обновление этих приложений из главного процесса приводит к плохому UX.
2. Strawberry - это ИИ-стартап, знаете ли. ИИ-агенты, которые работают как ядро приложения, постоянно вызывают ререндер React-приложений.

В общем, React быстрый, но недостаточно быстрый для чуваков из Strawberry (хотя конечно больше похоже на то, что они просто решили не париться с оптимизацией ререндеров)

Отдельно забавляет подход, с которым начался процесс переписывания. Какое-то обсуждение через ADR, RFC или хотя бы тред - это все лишнее. Чел просто на один из дейликов пришел и сказал "смотрите, переписал уже 60% кодовой базы на Svelte". Живем в эру, где быстрее показать Proof of Concept, чем начать обсуждение какой-то инициативы.

Как состоялось переписывание:
1. Были оформлены правила миграции, чтобы гарантировать, что ИИ-агенты пишут код "правильно". Короткие примеры правил: "Avoid $effect", "Prefer stores over component state", "Keep reactivity explicit."
2. За 1 раз переписывается одна фича
3. ИИ-агент читает правила, портирует код, тестирует код.
4. Старый код не удалялся, пока не была завершена миграция (чтобы при любых проблемах можно было поднять эталонные исходники и сравнить решение)
5. Часть библиотек отсутствует на svelte, поэтому пришлось их написать самим (через агентов конечно)

Какие результаты:
1. х2 ускорение
2. FCP уменьшился с 300мс до 124мс
3. Количество ререндеров в приложении уменьшилось в 10 раз
4. Удалили 56 неиспользуемых зависимостей


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



https://strawberrybrowser.com/blog/react-to-svelte

#development #javascript #react #svelte #migration #refactoring #ai

Дайджест за 2026-03-23 - 2026-03-27

Can't Maintain. Can you spot the better API?
"Не поддерживаемый" (Can't maintain) - сайт с короткими квизами, где надо выбрать более поддерживаемый вариант реализации JS или React-кода. При ответе краткий экскурс, почему один из вариантов более поддерживаемый, чем другой. Очень залипательный сайт.

Why is WebAssembly a second-class language on the web?
WebAssembly развивается с 2017 года, но все еще не стал полноценной частью веб-экосистемы. В статье Ryan Hunt объясняет, какие проблемы есть у современного WASM и что надо изменить, чтобы wasm стал популярен у разработчиков

How we Rewrote 130K Lines from React to Svelte in Two Weeks
Команда strawberry за 2 недели переписала 130к строчек кода с React на Svelte с применением ИИ-агентов. Интересный кейс, про который можно и почитать. Хотя, конечно, тот факт, что ИИ-агенты хорошо справляются с переписыванием - давно не новость

——————————————

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

——————————————

Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

Reveal.js 6.0

Вышел новый релиз Reveal.js. Reveal.js — это инструментарий для создания веб-презентаций из кода. Основное важное изменение для релиза — нативная поддержка React. Теперь можно собирать интерактивные презентации на привычном стеке.

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

В общем, решил совместить приятное с полезным и отправил агента сначала мигрировать презентацию с pptx на reveal. Агент нашёл какой-то пакет для парсинга слайдов на Python и собрал базу для презентации. Результат простой миграции выглядит, конечно, достаточно убого.

Дальше пошли сплошные плюсы. Заставил агента через Chrome MCP провести ревью слайдов и исправить явные косяки. С этой задачей он справился: где-то выровнял, где-то увеличил, а где-то распределил контент по слайду.

Дальше пошёл самый кайф. Т. к. на слайдах были картинки, а тут у нас целый React, то почему бы не добавить интерактива? Описал, какой интерактив я ожидаю на слайдах, и вообще попросил все картинки из интернета заменить на что-то более живое.

Результат следующий: половина коллег сказали «вау, круто», другая половина оценила как «юзлес кринж». Считаю, главное, что мне нравится :)

Но как итог:
- Reveal.js норм ложится для создания интерактивных презентаций на React. Слайды с демками, кликабельные блоки, кастомные анимации любой сложности — всё можно сделать в Reveal.js.
- ИИ-агент с доступом к Chrome MCP вполне бодро может собрать презентацию сам по вашему контенту и с вашим видением.


https://github.com/hakimel/reveal.js/releases/tag/6.0.0

#development #javascript #react #revealjs #presentation #release #ai #agents

Next.js 16.2

Вышел релиз Next.js 16.2. Кратные ускорения (400% ускорение старта при разработке и 50% ускорение рендеринга), правки в Turbopack и адаптация фреймворка для AI. Ещё новая дефолтная страница для 500 ошибки.

Что прикольного завезли:

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

Удобное отображение диффа между серверной и браузерной разметкой, когда разъехалась гидрация. За это однозначный лайк. Также более удобное отображение ошибок в dev overlay.

Я бы не писал в канал, если бы не отдельные телодвижения в релизе для ИИ-агентов.

Что конкретно сделали:

Теперь при создании нового приложения через create-next-app создаётся Agents.md. В файле написано, что это Next.js репозиторий и необходимо смотреть доку в node_modules/next/dist/docs. Это сделано потому что, по исследованию, наличие доки по фреймворку рядом с кодом позволяет агентам достигать лучших результатов в бенчмарках.

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

При старте сервера Next.js пишет в lock-файл PID процесса. Если попытаться стартануть новый сервер, то Next.js не позволяет это сделать и говорит, что сервер уже запущен. Это также полезно для агентов, которые любят запустить приложение с десяток раз.

Сделали DevTools для агентов. Можно получать инфу из DevTools через CLI. В целом, как будто ИИ-агенты и так могут это делать через MCP или прямое или почти прямое использование CDP через CLI, но встроенная в фреймворк возможность так делать, конечно, удобнее для массового использования.

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


https://nextjs.org/blog/next-16-2

#development #javascript #react #nextjs #turbopack #release #ai #agents #devtools

Анонс TypeScript 6.0

Анонс последнего мажорного релиза TypeScript на текущем стеке. Напомню, скоро TS-компилятор перепишут на Go, и это будет 7-я версия языка. 6-я версия — переходная. В рамках неё можно подготовиться: избавиться от настроек, которые не будут поддерживаться, и поставить настройки, которые приводят поведение компилятора к новому поведению.

Можно ставить в планы по техническим работам обновление TypeScript.


https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/

#development #typescript #release #microsoft

Дайджест за 2026-03-30 - 2026-04-03

Reveal.js 6.0
Вышел новый релиз Reveal.js. Reveal.js — это инструментарий для создания веб-презентаций из кода. Основное важное изменение для релиза — нативная поддержка React. Теперь можно собирать интерактивные презентации на привычном стеке.

Next.js 16.2
Вышел релиз Next.js 16.2. Кратные ускорения (400% ускорение старта при разработке и 50% ускорение рендеринга), правки в Turbopack и адаптация фреймворка для AI. Ещё новая дефолтная страница для 500 ошибки.

Анонс TypeScript 6.0
Анонс последнего мажорного релиза TypeScript на текущем стеке. Напомню, скоро TS-компилятор перепишут на Go, и это будет 7-я версия языка. 6-я версия — переходная. В рамках неё можно подготовиться: избавиться от настроек, которые не будут поддерживаться, и поставить настройки, которые приводят поведение компилятора к новому поведению.

——————————————

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

——————————————

Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

Start naming your useEffect functions, you will thank me later

Огромная статья, в которой очень простой месседж — именуй чёртовы колбэки в useEffect.

В чём суть. Есть две большие причины именовать колбэки в useEffect.

Первая: самодокументирующийся код. useEffect(() => {}) говорит о том, как мы запускаем код (при изменениях чего-то), но не говорит о том, что там запускается и почему.

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

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

Автор даёт в статье пример компонента, который общается по WebSocket и синхронизирует состояние сущности.

Пример useEffect с именованным колбэком:

useEffect(function resetStockOnLocationChange() {
    if (prevLocationId.current !== locationId) {
      setStock([]);
      prevLocationId.current = locationId;
    }
  }, [locationId]);

Привычка давать имена колбэкам позволяет на берегу обнаружить проблемы с ответственностью. Сложно дать имена колбэкам, которые делают либо слишком много, либо слишком мало.

Вторая причина для именования колбэков чисто прагматичная. Лучше в инструментарии и в стек-трейсах видеть at resetStockOnLocationChange, чем at anonymous.

В общем, именуйте колбэки в useEffect. Это бесплатно и сразу делает вашу жизнь лучше. Можно ещё написать или найти ESLint-правило, которое не даст коммитить анонимные useEffect.


https://neciudan.dev/name-your-effects

#development #javascript #react #hooks #useeffect #best-practices #article

Rewriting our Rust WASM Parser in TypeScript

OpenUI сделали парсер на Rust и компилировали его в WASM. Rust же быстрый, но недостаточно. Какое-то время оптимизировали его, пытались ускорить, но по итогу оказалось, что реализация на TypeScript работает быстрее.

Причина банальна — очень много потерь на передачу данных между JS и WASM. Как ни пытайся оптимизировать эту передачу данных, всё равно проиграешь решению без передачи. Что в итоге и сделали — переписали парсер один в один на TypeScript и ускорились в разы.

Очередное напоминание, что в текущих реалиях WASM хорош для тяжёлых задач (например, видеопроцессинг) и для переноса нативного кода в веб, но плохо подходит для ускорения приложений, если нужно передавать много данных между WASM и JS.

Также хорошее напоминание, что если садишься оптимизировать что-то, надо исследовать возможности для оптимизации максимально широко, а не концентрируясь только в каком-то одном этапе.


https://www.openui.com/blog/rust-wasm-parser

#development #typescript #rust #wasm #performance #parser #openui #article