🦜 on the web

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

Подсмотрел как можно использовать 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, который выполняется в реальном времени по мере ввода текста.

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

https://github.com/mlabonne/llm-course

https://github.com/aidenybai/bippy

Автор react-scan и million выложил инструмент, с помощью которого сделан react-scan. Bippy дает доступ к внутрянке реакта притворяясь "реакт девтулзами", тем самым предоставляет доступ к Fiber и другим внутренним компонентам.

Демо

🕹 Пробую делать игру на Godot и Unity: опыт для новичка

Решил попробовать сделать простую игру и заодно сравнить два движка: Godot и Unity. Для гугления использовал бесплатные AI типа Perplexity и DeepSeek, потому что у них нет ограничений по региону, и количеству токенов.

Godot: дружелюбно и по делу

Установка, запуск, первые шаги — всё супер. Не надо никакой IDE, автокомплит из коробки, интерфейс не перегружен. Если цель просто попробовать что-то быстро собрать — это идеальный вариант. Но вот с новой версией (4) справляться сложнее, нейросети вообще живут в прошлом.

Unity: монстр, который требует времени

После Godot переход на Unity ощущается как прыжок с велосипеда на грузовик. Движок кажется монструозным. Без туториалов можно часами кликать по интерфейсу и ничего не добиться. Обязательно нужна сторонняя IDE с настроенным автокомплитом и поддержкой C#, например, Rider или Visual Studio.

И что раздражает: • Запускается долго. Даже на SSD и 32 ГБ DDR5 приходится ждать. • Для простых вещей, вроде кнопки, приходится копаться в куче настроек.

Резюме

Если вы новичок и хотите быстро вкатиться — Godot ваш выбор. Unity лучше для серьёзных проектов, но чтобы освоить его, надо потратить уйму времени и терпения.

Осталось потестить Unreal Engine и понять, где та самая “золотая середина”.

Наткнулся на аналог (если можно так сказать) chatgpt — DeepSeek.

Можно использовать аналог gpt o1 с рассуждениями — Deep Think . Дают 50 использований в день, если я правильно понял.

👀 Ссылка — нет блокировки по РУ региону и можно через гугл акк.

React Scan detects performance issues in your React app.

Новый инструмент для отслеживания ререндеров и проблем с производительностью приложений на Реакте.

На видео от автора, можно увидеть как работает на примере слака и чатгпт (будет в комментах).