🦜 on the web

Второй день Holyjs.

Был уже на докладе про реактивный css. Полезный и крутой доклад.

Сейчас на докладе по LLM.

14-15 Мая буду на Holyjs 2026 Spring.

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

Кто точно пойдет, пишите, можем понетворкаться.

Если тоже хотите на конфу, пишите мне в личку, подскажу как лучше это сделать.

Сhrome's DevTools MCP теперь включает:

* Проверки производительности через Lighthouse * Навык обнаружения утечек памяти * Навык отладки доступности * Навык оптимизации LCP

и экспериментальный новый CLI

https://github.com/ChromeDevTools/chrome-devtools-mcp

Next.js 16.2 — AI, DX, и ускорение турбопака.

Сначала про турбопак.

Был тред, от platformatic про то, что некст медленный и на 1к реквестов у него 50-60 процентов success rate. Началось шапкозакидательство, потому что начали сравнивать с tanstack start.

Команда некста, взяла platformatic/flame, нашла проблему. Далее буду цитировать.

Tim Neutkens from Next.js found a hotspot in React Server Components: JSON.parse with a reviver callback forces a C++ to JS boundary crossing for every key-value pair.

His fix landed in React itself. 75% speedup in RSC deserialization. Benefits every React framework.

Next.js 16.2.0-canary.66: throughput more than doubled (322 to 701 req/s). Average latency dropped by 6x. 83% reduction in latency. Тем самым добились следующего: Up to ~60% faster rendering Up to ~400% faster 𝚗𝚎𝚡𝚝 𝚍𝚎𝚟 startup. Подробнее по ссылкам можно почитать.

Далее про AI и DX.

Теперь проект проще для AI‑ассистентов. Агентам легче понимать структуру проекта, ловить баги прямо из терминала и инспектировать приложение в работе — всё это без браузера. Можно копировать в документации (появилась отдельная кнопка) целые страницы оптимизированые под ИИ.

Логи из браузера теперь попадают в терминал. Добавили дифф ошибки гидратации. Дебаг ноды добавили для прод сервера.

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

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

Opus 4.6 уже лучше понимает container queries, container units с гридами. Самое трудное в таком подходе это формулы пропорций отступов, флюидная типографика, и вообще смена мышления зависимости от вьюпорта.

В этой задачи ИИ позволяет быстро проверять мысли и видеть результат.

Пока выводы делать рано, нужны еще переменные, чтобы окончательно понять, а можно ли сделать компоненты без пропсов isDesktop, isMobile, size, без вычисления в рантайме. Для простого копипаста композиции и переиспользования на других экранах.

Agent Skills

Новая спецификация от Anthropic — Skills — быстро набирает популярность в AI-дев сообществе. Идея в том, что агент может получать новые возможности по требованию, через progressive disclosure: подгружается только то, что действительно нужно, чтобы контекст оставался компактным и управляемым.

Тема активно обсуждается и появляются ресурсы: • Skills.sh — платформа от Vercel для поиска популярных open-source skills • React Best Practices от Vercel — skills для React и Next.js

Пробуйте, подбирайте на свой вкус. Кому-то поможет в команде прийти к единому стилю вайбкодинга🙂

Набор настраиваемых частиц разбавит приложение анимациями для ваших Call to Action.

Upd. Разобрали почему есть проблемы с производительностью

Почему нам нужны новые подходы к адаптивному дизайну

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

/* Традиционный подход с медиа-запросами */ @media (max-width: 768px) { .card { flex-direction: column; } }

Этот подход привел к появлению условных конструкций в коде компонентов: <Button size={isMobile ? 'xs' : 'md'}> Нажми меня </Button> <Card variant={isTablet ? 'compact' : 'full'} />

Хотя медиа-запросы решали многие проблемы, они имеют существенный недостаток: компоненты реагируют только на размер экрана, а не на контекст, в котором они используются. Но что, если компоненты могли бы адаптироваться к размеру своего непосредственного контейнера?

Если схематично представить, то получается так, что вписываем наши компоненты в рамки и от их размеров этот компонент сам будет меняться 0px 350px 500px │─────────│────────────│

│ ┌────────────────────────────┐ │ │ ┌──────┐ Address │ │ │ │ IMG │ $280k–$310k │ │ │ └──────┘ [Confidence: 85%] │ │ └────────────────────────────┘ 0px 350px │─────────│

│ ┌────────────────────────────┐ │ │ ┌────────────┐ │ │ │ │ IMAGE │ │ │ │ └────────────┘ │ │ │ 123 Main St, Phoenix AZ │ │ │ $280,000 – $310,000 │ │ │ [Confidence score: 85%] │ │ └────────────────────────────┘

Далее это вижу так: любой шаблон, макет, layout — это всегда набор блоков, в которые помещаются элементы интерфейса и контент.

Возьмём лист А4 — у него фиксированная ширина, но внутри этой ограниченной области мы можем располагать элементы, считая, что доступная ширина — 100%. Аналогично с экранами устройств: у каждого девайса своя фиксированная ширина в пикселях, но с точки зрения CSS мы всё равно часто оперируем значением width: 100%.

Контент всегда занимает доступную ширину родителя. Один блок вкладывается в другой, и относительные значения продолжают работать — 100% внутри 100%, но в пикселях это уже конкретные числа, зависящие от контекста.

Это база (пересказал css): любой layout строится из вложенных прямоугольников с фиксированной пиксельной шириной, даже если мы пишем width: 100%.

Так вот вопрос: если карточки, блоки и секции в макетах всё равно имеют фиксированные размеры, зачем нам ориентироваться на ширину экрана? Мы же хотим вписывать компоненты в конкретные блоки, а не подгонять их под экран. Гораздо логичнее мыслить не “экранами”, а “контейнерами”.

Проще заложить в макетах компактный начальный стиль и максимальную ширину контента — а остальное рассчитывать динамически через clamp, minmax, пока не упрёмся в минимальный или максимальный порог.

И да, про это тоже будет отдельный пост: как донести такую философию до дизайнеров. Потому что рисовать по 5 версий одного экрана под каждое разрешение — это уже вайбы 2015 года, а не современный рабочий процесс.

После того как я погрузился в возможности container queries, container units, а также fluid-типографику с clamp() и minmax(), возник вопрос: а можно ли вообще избавиться от флагов, пропсов и хуков в React-компонентах, которые отвечают за адаптивность?

Зачем каждый раз писать isMobile, size, compact, dense, fullWidth, вызывать хук для определения ширины экрана, если можно описать поведение компонента сразу через CSS и дать ему возможность адаптироваться к размеру своего контейнера?

Это размышление постараюсь разбить в небольшую серию постов, где я исследую, как убрать всю эту логику из JS и сделать компоненты по-настоящему контекстными и адаптивными.

Вот с чего обычно всё начинается: function ProductCard({ product, isMobile }) { return ( <Card size={isMobile ? 'compact' : 'full'}> <Image src={product.image} size={isMobile ? 'small' : 'large'} /> <Title fontSize={isMobile ? '16px' : '24px'}>{product.name}</Title> {!isMobile && <Description>{product.description}</Description>} <Price>{product.price}</Price> <Button size={isMobile ? 'xs' : 'md'}>Купить</Button> </Card> ); } К чему хочется прийти (css modules не обязательно, будем пробовать tailwind-variants, headless решения, какой-нибудь react-aria-components) function ProductCard({ product }) { return ( <div className="product-card-container"> <Card className="product-card"> <Image src={product.image} /> <div className="product-info"> <Title className="product-title">{product.name}</Title> <Description className="product-description">{product.description}</Description> <Price className="product-price">{product.price}</Price> <Button className="buy-button">Купить</Button> </div> </Card> </div> ); }

Когда кажется, что паттерн Render Props — это устаревшее и непопулярное решение, вдруг находишь ему применение в headless UI-компонентах, а потом появляются и новые проекты, которые раскрывают его возможности по-новому.

RenderHooks позволяет размещать хуки прямо рядом с разметкой, где они действительно нужны — без обёрток-компонентов, без нарушения правил хуков и без шаблонного кода, даже если вы используете собственные хуки.

import $ from 'render-hooks';

export function Counter() { return ( <$> {({ useState }) => { const [n, set] = useState(0); return <button onClick={() => set(n + 1)}>Clicked {n}</button>; }} </$> ); }

А вот with-react — коллекция React-компонентов, которые оборачивают хуки и предоставляют более композиционный API. Каждый компонент принимает render prop, получающий значение, возвращаемое хуком.

Это позволяет реализовать поведение, которое ранее нарушало бы правила хуков. function SearchForm() { return ( <form action="/search"> <input name="q" /> <WithFormStatus> {(status) => ( <button disabled={status.pending}> {status.pending ? 'Submitting...' : 'Submit'} </button> )} </WithFormStatus> </form> ) }

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

Сейчас занимаюсь ресерчем — обновлять ESLint до 9 версии или переходить на что-то более свежее и быстрое: OXC, RSLint, Biome. И вот в процессе наткнулся на интересный ишью по React Compiler.

В обсуждении на GitHub отписался Evan You. Он подробно описал, почему сегодня сложно эффективно использовать React Compiler вместе с инструментами на Rust — такими как OXC и SWC.

React Compiler реализован как набор Babel-плагинов на JavaScript. OXC и SWC — это компиляторы и линтеры, написанные на Rust. Между ними нет общего API, и прямой интеграции не получается без существенных компромиссов.

Основные проблемы: • Для запуска React Compiler потребуется передавать AST между Rust и JavaScript. • Это ограничивает параллелизм и добавляет накладные расходы. • В случае SWC интеграция достигается через встроенный JS-движок (QuickJS), но такой подход не масштабируется и остаётся временным решением. • Команда OXC считает подобный путь неоправданным и рекомендует запускать React Compiler отдельно.

Что предлагается сейчас:

Использовать React Compiler как отдельный Babel-проход, например, через @vitejs/plugin-react и его babel-настройку. Такой способ работает стабильно в экосистеме Vite.

Возможные направления развития: • Переписать React Compiler на Rust. Это обеспечит наибольший прирост производительности (по оценкам — в десятки раз), но требует значительных усилий. • Перенос на Go с использованием C FFI-интерфейса (FFI — Foreign Function Interface). Такой подход применяет команда TypeScript при переносе своих инструментов. • Создание API для “лёгких JS-трансформов”: AST передаётся в JS, где создаются инструкции по изменениям, а финальная работа выполняется обратно в Rust. Такой подход уже используется в некоторых Vite-плагинах, но в случае с React Compiler его применимость под вопросом из-за сложности самого компилятора.

Если хочется использовать современный Rust-базированный сборщик и линтер, то подключение React Compiler создаст неудобства. И наоборот — если в проекте требуется React Compiler, то отказ современных сборщиков и переход на Babel может усложнить сборку и снизить ее скорость.

На текущий момент приходится выбирать: либо современный toolchain, либо полная поддержка React Compiler — вместе они пока работают с ограничениями.

https://blog.jetbrains.com/webstorm/2025/04/webstorm-2025-1

JB клоуны🤡, конечно, лютые. Добавили возможность подключиться к локальной LLM, но плати👀, если тебе нужен чат из виджета в ИДЕ. Стикер сами знаете какой😡

Vibe coding? Может лучше Vibe Drawing?

https://github.com/martin226/vibe-draw

В одной соц сети пожаловались на медленную навигацию Next.js.

Lee Robinson выпустил 5 минутное видео объясняющее, что произошло. Он воссоздал через v0 проблемное приложение и показал как решать данный кейс

Подсмотрел как можно использовать https://manus.im/ (есть еще его опенсорс аналог ANUS 😳)

MANUS — универсальный ИИ агент, который может и код писать, и путешествие запланировать, и анализ провести.

На видео пример, как проверяет SEO оптимизацию и выдает отчет по веб сайту.

Большое обновление Hero UI

Теперь рядом с компонентом появилась кнопка "открыть в чате" и в нем можно изменить компонент под свои нужны.

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

https://heroui.chat/

Утекли промты Vercel для v0.dev.

Формат промта похож на системный, а v0 использует gpt-4o, а для размышления DeepSeek.

Сам промт на гитхабе

React Scan Inspector — браузерное расширение для React-scan.

React-scan — инструмент, который автоматически находит проблемы с производительностью в React приложениях.

https://github.com/jantimon/chrome-react-scan-inspector

Реакту нужен фреймворк при создании приложений, и вот почему:

За 8 лет работы с React я убедился во всех его особенностях. React — отличная библиотека, но, по сути, это лишь часть решения для создания масштабных приложений. Когда ты попадаешь в проект, где сборка настроена хаотично, отсутствует единый подход к роутингу, а идеологическое обоснование выбора инструментов практически отсутствует, это начинает сильно раздражать.

Особенно остро ощущается проблема сборки. Представьте себе: «голый» вебпак без плагинов для оптимизации приводит к долгому холодному старту и долгим ребилдам, меня такое вгоняет в тильт. Нажал на save — и можно отлучиться пить чай пять минут, ведь сборщик на JavaScript просто не справляется с обходом графа зависимостей. Такое окружение способно вывести из себя любого разработчика.

Решением становится использование готовых инструментов, в которых большинство этих болевых точек уже учтены «из коробки». Современные фреймворки, такие как Next.js, предлагают встроенный файловый роутинг, оптимизации для разработки и продакшена, настроенные линтеры, горячую перезагрузку и fast refresh. Ребилды происходят мгновенно, зависимости оптимизированы, а сборка не превращается в кошмар. При этом тебе не нужно тратить часы на настройку инфраструктуры — ты сразу можешь сосредоточиться на создании продукта. И да, не продаю тут Next.js.

Кстати, нельзя не упомянуть гугловскую команду Аврора, которая вместе с разработчиками Next.js активно работает над оптимизацией сборки приложений.

Как мне кажется, депрекейт CRA тому доказательство. Его было сложно настроить, он не нес никакой философии и оказался пустышкой. В документации CRA даже говорится: "Create React App is a comfortable environment for learning React, and is the best way to start building a new single-page application in React." Я всегда утверждал, что это решение должно оставаться лишь «комфортной средой для изучения React» и не больше.

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

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

p.s. Однако если вы создаёте расширения или виджеты на React, полноценный фреймворк вам не нужен — в этом случае вполне достаточно всего, что даёт React «из коробки».

В следующей версии Bun

Bun.serve() получит встроенную поддержку горячей перезагрузки фронтенд-приложений.

Выше приведено демонстрационное приложение-клон интерфейса Twitter TailwindCSS + shadcn / ui. Это быстрая перезагрузка css и js / ts / tsx, запуск плагина tailwind css, перенос jsx / tsx, websocket hmr, который выполняется в реальном времени по мере ввода текста.