gogcli

gogcli - инструмент для терминала, позволяющий работать с сервисами Google: почта, диск, документы, календарь и другое. Очень удобно, просто и хорошо интегрируется с AI-агентами

https://gogcli.sh/

#development #google #commandLine #tool

Here's a 1 GB memory reduction for very long Claude Code sessions

Начал снова читать Твиттер, а там оказывается интересное показывают! Например, однострочный фикс утечки памяти в Claude Code, которая спасает гигабайты оперативки.


Код с утечкой памяти: () => controller.abort()
Фикс: controller.abort.bind(controller)

Создание стрелочной функции ведет к созданию замыкания на скоуп функции, в которой создается стрелочная функция, что мешает GC собрать фактически ненужную память.

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

https://x.com/jarredsumner/status/2017825694731145388

#development #javascript #performance #claudeCode #memoryLeak

The Too Early Breakpoint

Слишком ранний брэкпоинт - ситуация, когда интерфейс перестраивается в мобильную сетку слишком рано. Например, когда сайт оптимизируют для десктоп и iPhone и при открытии сайта на планшете или в половинном окне браузера показывается несуразная мобильная верстка с картинкой на весь экран.

Автор показывает на примере крупных новостных изданий как это выглядит и упоминает кейсы, для которых это реально проблема:
- Планшеты и телефоны-раскладушки (сам пользуюсь раскладушкой и периодически на сайтах действительно происходит что-то несуразное)
- Окно браузера открытое в split-screen или не на весь монитор
- Превью ссылок в разных приложениях (например в Telegram)

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

https://ishadeed.com/article/too-early-breakpoint/

#development #css #responsive

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

7 practical animations tips
7 практических советов по созданию анимаций. Статья с гифками и интерактивными примерами, на которых прямо показывается, как с помощью небольших улучшений сделать анимации в интерфейсе приятнее

Yarn 6 Preview
Я уже давно не следил за развитием Yarn, а тут оказывается, они уже готовят шестую версию (пятую пока еще, правда, не выпустили). Собственно, основная большая фича Yarn 6 - это реализация пакетного менеджера на Rust

gogcli
gogcli - инструмент для терминала, позволяющий работать с сервисами Google: почта, диск, документы, календарь и другое. Очень удобно, просто и хорошо интегрируется с AI-агентами

Here's a 1 GB memory reduction for very long Claude Code sessions
Начал снова читать Твиттер, а там оказывается интересное показывают! Например, однострочный фикс утечки памяти в Claude Code, которая спасает гигабайты оперативки.

The Too Early Breakpoint
Слишком ранний брэкпоинт - ситуация, когда интерфейс перестраивается в мобильную сетку слишком рано. Например, когда сайт оптимизируют для десктоп и iPhone и при открытии сайта на планшете или в половинном окне браузера показывается несуразная мобильная верстка с картинкой на весь экран.

Немного про свой ИИ-кодинг

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

Недавно, читая посты в твиттере и чье-то интервью или заметку (по-моему Мартина Фаулера), я нашел интересную мысль: многие бест-практисы разработки, которые продвигали Мартин Фаулер, Кент Бек, Боб Мартин и другие, хорошо ложатся на ИИ-кодинг.

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

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

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

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

№1 TDD
TDD, как паттерн разработки, прекрасно работает для ИИ-кодинга:
- Пиши тест, убедись что он падает
- Напиши реализацию, убедись что тест проходит
- Рефактори

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

Что для этого нужно:
- Правило или скилл, которые скажут агенту а) как надо разрабатывать по TDD; б) запускать тесты и не завершать задачу, пока все тесты не будут зелеными
- Какие-то примеры, какие тесты считать хорошими и как вообще надо тестировать

Но, конечно, в современном фронтенде не без проблем. Однажды ИИ написал бесконечный ререндер компонента через useEffect, что привело к бесконечному запуску тестов. Когда я указал ему, что тесты бегают в бесконечном цикле и это надо исправить. Я его оставил, но через какое-то время обнаружил, что макбук начал лагать. Оказывается, ИИ решил проверять исправления следующим образом: запускать тесты в фоне и, если через 15 секунд процесс не завершился - значит не починил. Так он и запустил в фоне 6+ vitest с бесконечным циклом внутри react.

№2 BDD
BDD оказался очень удобным фреймворком для ИИ-кодинга в пет-проекте. Как это работает: я описываю юзер стори, которые надо реализовать. Затем мы с ИИ описываем их в feature-файле через gherkin (формат сценария Given-When-Then)

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

№3 Строгое разделение ответственности
Тут много всяких паттернов: SOLID, CQS, View-Controller и так далее.

Суть в том, чтобы строго следовать бест-практисам по делению ответственности. В текущем сетапе у меня настроены такие правила хорошего дизайна:
- В *.types.ts описывается интерфейс сущности с JSDoc. Интерфейса должно быть достаточно для использования сущности потребителем, т.е. не надо сканировать всю реализацию для ее использования
- React-компоненты жестко делятся на View (не достают ничего из DI, не используют стор) и на Container. Все состояния View компонентов загоняются в storybook. Также view-компоненты удобно тестировать в cypress
- Логика приложения находится в store. API на изменение стора - это экшны. У фичи может быть несколько сторов для разных кейсов. Например в текущей фиче, которую щас делаю, 3 стора: UI конфигурации, доменная модель настроек, применение фичи на канбан-доске.

При планировании работ прошу ИИ-агента следовать этим правила и в плане описывать:
- mermaid-диаграмму с сущностями и их связями
- файловую структуру будущей фичи

Поделитесь в комментах фидбеком или тем, какие вы практики нашли полезными в ИИ-кодинге - буду учиться :)





#development #javascript #bdd #cypress #note

npmx.dev: a fast, modern browser for the npm registry.

npmx.dev - альтернатива сайту npmjs.com. Как и npmjs, позволяет искать и исследовать пакеты в npm, но также имеет несколько дополнительных фичей: поддержка темной темы, возможность провалиться в исходники пакета, показ используемой модульной системы, показ размера пакета и тд

Выглядит интересно

https://github.com/npmx-dev/npmx.dev

#development #javascript #npm

A Broken Heart - Allen Pike

Еще одна история в стиле "один из самых безумных багов, с которым я сталкивался". Allen Pike рассказывает о баге, из-за которого страница загружалась в 100 раз дольше.

В чем суть. Однажды Allen увидел, что сайт, который обычно грузится моментально, стал виснуть при загрузке. В таком случае одна из первых реакций - недовольное "опять кто-то навертел в рендере React'а". Allen послал Claude Code найти и пофиксить проблемы с рендером React'а. Claude Code нашел, пофиксил и... ничего не изменилось

Allen'у пришлось самому погружаться в традиционные инструменты для дебага. Это принесло свои плоды - было обнаружено, что Safari тратит секунды, потребляя 90+% CPU M1 MAX на перестроение лэйаута.

Далее Allen взял еще один традиционный метод поиска проблем - бинарный поиск через удаление функционала.
Метод, я надеюсь, знакомый каждому:
1. Выбираем код, в котором, как мы думаем, скрыт корень проблемы. На ранних итерациях следует выбирать большие объемы кода
2. Удаляем код.
3. Если проблема исчезла - значит проблема где-то в этой части. Восстанавливаем код, goto 1 выбирать часть кода внутри текущей
4. Если проблема не исчезла - значит проблема где-то еще. Goto 1 выбирать новый кусок кода

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

Итак, возвращаемся к багу. Allen решил найти проблему этим методом с помощью Claude Code. Claude Code может оперировать кучей файлов с кодом и проверять гипотезу, что позволяет запустить процесс поиска проблемы в фоне. При этом Claude Code может выполнить это достаточно быстро.

Claude Code успешно обнаружил проблему и она оказалась в emoji ❤️. Что, весьма неожиданно. Allen (да и я тоже) часто использует emoji в интерфейсах, потому что они узнаваемы, их легко встраивать в интерфейсы (по сути как обычный текст) и они работают везде.

В чем корень проблемы. В 2008 году Apple добавили в шрифты цвета, чтобы поддержать emoji. Сделали это весьма костыльно - буквально зашили png в шрифты. Чуть позже рабочая группа сформировала удобный стандарт для цветов в шрифтах. В приложении использовался отдельный шрифт для emoji, чтобы добиться консистентности рендеринга emoji на разных платформах. Этот шрифт опирался на гугловый формат COLRv1, который ускорял загрузку шрифта, но фолбечился до svg в некоторых браузерах. Safari оказался как раз этим "некоторым" браузером. Собственно рендер svg и приводил к дикому пересчету лэйаута.

Такой вот баг.

Какие уроки можно вынести:
- Нельзя доверять даже рендерингу шрифтов. Шок.
- Старые добрые инструменты для поиска проблем все еще работают. Не шок. Если вы все еще не прокачались до черного пояса в девтулах - никогда не поздно начать это делать.
- ИИ-агенты позволяют автоматизировать поиск проблем

https://allenpike.com/2026/a-broken-heart

#development #safari #bug #emoji #cloudCode

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

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

npmx.dev: a fast, modern browser for the npm registry.
npmx.dev - альтернатива сайту npmjs.com. Как и npmjs, позволяет искать и исследовать пакеты в npm, но также имеет несколько дополнительных фичей: поддержка темной темы, возможность провалиться в исходники пакета, показ используемой модульной системы, показ размера пакета и тд

A Broken Heart - Allen Pike
Еще одна история в стиле "один из самых безумных багов, с которым я сталкивался". Allen Pike рассказывает о баге, из-за которого страница загружалась в 100 раз дольше.

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

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

Announcing TypeScript 6.0 Beta

Анонсировали бету TypeScript 6.0. Версия, которая должна стать переходной между текущей реализацией TS на JS и будущей реализацией на Go в 7.0. Версия 6.0 будет нести в себе изменения, упрощающие миграцию на будущую 7.0 версию, но также и некоторые полезные изменения.

Первое интересное исправление. Если у вас есть Generic-функция, которая вычисляет аргумент generic'а по переданному аргументу функции внутри, то если функция является стрелочной, то все будет работать корректно, а если это метод объекта - то будет ошибка. Шок контент. Пример ниже

declare function callIt<T>(obj: {
    produce: (x: number) => T,
    consume: (y: T) => void,
}): void;

// Works, no issues.
callIt({
    produce: (x: number) => x * 2,
    consume: y => y.toFixed(),
});

callIt({
    consume(y) { return y.toFixed(); },
    // error: 'y' is of type 'unknown'.

    produce(x: number) { return x * 2; },
});

Это связано с тем, как TS обрабатывает this у функций. Хотя ни там, ни там он не используется, во втором случае у функции есть свой this и это как-то влияет на тайп-чекер. Теперь это исправили

Завезли флаг --stableTypeOrdering для упрощения миграции до 7 версии. Этот флаг, как следует из названия, стабилизирует порядок типов в скомпилированных декларациях. Оказывается, есть кейс, когда заведение переменной, которая никак не связана с функцией, меняет порядок типов в декларации функции. Пример

Вот так компилируется, что функция возвращает 100 или 500

// Input: some-file.ts
export function foo(condition: boolean) {
    return condition ? 100 : 500;
}

// Output: some-file.d.ts - 100 | 500
export declare function foo(condition: boolean): 100 | 500;

Но если добавить перед этим переменную, то возвращаемое функцией значение начнет компилироваться как 500 или 100

// Input: some-file.ts
const x = 500;
export function foo(condition: boolean) {
    return condition ? 100 : 500;
}

// Output: some-file.d.ts - 500 | 100
export declare function foo(condition: boolean): 500 | 100;

Внимание, флаг может замедлить тайп чекинг на 25%.

Также в TypeScript 6 вошли:
- target es2025
- Поддержка Temporal
- Поддержка новых методов в Map: getOrInsert, getOrInsertComputed
- Поддержка RegExp.escape
- lib dom.iterable внесли просто в dom. Теперь достаточно подключить только dom чтобы итерироваться по document.querySelectorAll

Ломающие изменения
На основе анализа конфигов пользователей, часть опций стали дефолтными, часть требует явного указания.
- Необходимо указывать types. По дефолту теперь будет []. Для включения старого поведения можно установить ["*"]
- rootDir по дефолту теперь ..
- strict: true по дефолту
- module: "esnext" по дефолту
- target: "es2025" по дефолту. В целом политика такая, что дефолтным будет считаться текущий стабильный ES.
- noUncheckedSideEffectImports: true по дефолту
- libReplacement: false по дефолту
- target: es5 задепрекейтили. Теперь минимальный таргет - es2015 (более известный как es6)
- --moduleResolution node задепрекейтили. Те кто использовали эту опцию, должны переехать или на nodenext или на bundler
- Удалена поддержка --module amd, umd, systemjs
- baseUrl больше не поддерживается, используйте paths
- --outFile задепрекейтили, используйте бандлеры вместо TS для вывода результата в 1 файл
- Задепрекейтили старый синтаксис для модулей. Это, конечно, может выстрелить т.к. могут быть third-party type declarations, где такой синтаксис используется

// ❌
module Foo {
    export const bar = 10;
}

// ✅ 
namespace Foo {
    export const bar = 10;
}

declare module "some-module" {
    export function doSomething(): void;
}

- Также задепрекейтили ассерты импортов в пользу with

// ❌ 
import blob from "./blahb.json" asserts { type: "json" }

// ✅ 
import blob from "./blahb.json" with { type: "json" }

В общем, готовимся к переезду на 7.0. Как минимум морально. Как максимум - заменяем все устаревшее на современное.


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

#development #typescript #javascript #breaking

Building Bulletproof React Components

Один из разработчиков Vercel написал короткий гайд, как делать "пуленепробиваемые" компоненты. Суть в том, что большинство компонентов пишутся под happy path — они работают, пока не сталкиваются с реальным миром: SSR, гидрация, несколько инстансов, конкурентный рендеринг, порталы и т.д.

В статье с примерами кода разбираются 10 аспектов, которые нужно учитывать:
1. Server-Proof — не используйте localStorage или другие браузерные API напрямую в рендере, выносите в useEffect
2. Hydration-Proof — код может работать по разному на сервере и в браузере. Популярные проблемы - таймзоны, адаптив через код, темы. Учитывайте это.
3. Instance-Proof — учитывайте, что компонент может быть инстансирован несколько раз на странице. Например, используйте useId() вместо захардкоженных id
4. Concurrent-Proof — несколько компонентов (или несколько параллельных запросов к серверному рендеру) могут привести к дубликации запросов в API или БД. Добавляйте кеширование и дедубликацию запросов.
5. Composition-Proof — React.cloneElement может не сработать для серверных компонентов. Для кейсов передачи данных при композиции используйте контекст
6. Portal-Proof — вместо window используйте ref.current?.ownerDocument.defaultView для обработчиков событий, иначе они не будут работать в iframe и порталах
7. Transition-Proof — для анимаций с <ViewTransition> в React 19 оборачивайте изменения стейта в startTransition()
8. Activity-Proof — если компонент инжектит глобальные стили, используйте media="not all" чтобы отключать их когда компонент скрыт через <Activity>
9. Leak-Proof — используйте taintUniqueValue чтобы предотвратить случайную утечку токенов и секретов из серверных компонентов в клиентские компоненты. Это экспериментальная фича, которая позволяет развалить рендер с кастомной ошибкой, если клиентский код попробует достучаться до запрещенного значения
10. Future-Proof — не используйте useMemo как хранилку данных. useMemo создан для улучшения перформанса. Если вам нужно хранить данные - используйте useState.

Крутой и простой чеклист того, что следует учитывать при разработке приложений.


https://shud.in/thoughts/build-bulletproof-react-components

#development #react #ssr #hydration #components #performance #security #quality

Components Will Kill Pages

Размышления о том, как AI может поменять подход к сайтам и приложениям. Основная мысль: в мире, где пользователи всё чаще получают ответы через ChatGPT и подобные интерфейсы, традиционная навигация по страницам уходит в прошлое.

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

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

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

Звучит интересно. Например, я работаю в сфере бронирования отелей и было бы круто, если бы мы отдавали AI удобные виджеты для просмотра вариантов отелей, а пользователь взаимодействовал с ними прямо в чате (смотрел фотки, отзывы, варианты заселения), вместо того чтобы считывать все то же самое из текстового полотна или доверяясь AI.

В таком будущем API из компонентов будет таким же важным, как и текущие сайты, реализующие пользовательские сценарии.

https://bitsandbytes.dev/posts/components-will-kill-pages

#development #frontend #ai #components

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

Announcing TypeScript 6.0 Beta
Анонсировали бету TypeScript 6.0. Версия, которая должна стать переходной между текущей реализацией TS на JS и будущей реализацией на Go в 7.0. Версия 6.0 будет нести в себе изменения, упрощающие миграцию на будущую 7.0 версию, но также и некоторые полезные изменения.

Building Bulletproof React Components
Один из разработчиков Vercel написал короткий гайд, как делать "пуленепробиваемые" компоненты. Суть в том, что большинство компонентов пишутся под happy path — они работают, пока не сталкиваются с реальным миром: SSR, гидрация, несколько инстансов, конкурентный рендеринг, порталы и т.д.

Components Will Kill Pages
Размышления о том, как AI может поменять подход к сайтам и приложениям. Основная мысль: в мире, где пользователи всё чаще получают ответы через ChatGPT и подобные интерфейсы, традиционная навигация по страницам уходит в прошлое.

wc3ui - библиотека компонентов в стиле wc3

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

Выглядит круто. Даже захотелось внедрить в какой-то пет-проект и снова перепройти кампании wc3. Надеюсь есть в канале люди, у которых сводит олд-скулы от такого.

https://wc3ui.banteg.xyz

#development #javascript #uikit #wc3

@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 марта.