🦜 on the web

HYPERBLAM — это попытка переосмыслить создание музыки в браузере. Его главный тезис сформулирован в слогане: «Make music, not Javascript». Автор предлагает отказаться от императивного программирования аудиографа через JavaScript и описывать музыку декларативно с помощью HTML. По сути, HYPERBLAM декларативная обёртка над Web Audio API, которая использует Web Components. Вместо написания кода вроде: const oscillator = audioContext.createOscillator(); const filter = audioContext.createBiquadFilter(); const gain = audioContext.createGain(); oscillator.connect(filter); filter.connect(gain); gain.connect(audioContext.destination); Описываем через композицию примерно так: <blam-sampler> <blam-sequence> ... </blam-sequence> </blam-sampler> То есть музыка становится частью разметки документа, примерно так же, как HTML описывает интерфейс страницы. Во-первых, декларативность вместо программирования. Автор пытается перенести философию HTML на создание музыки. HTML теги хорошо подходят для описания того, что должно быть создано, а не как именно это создавать. HYPERBLAM использует тот же подход для аудио. Вместо создания графа узлов через JavaScript разработчик описывает структуру музыки через вложенные элементы. Во-вторых, независимость от экосистемы. Проект не использует большие фреймворки и внешние зависимости. Это довольно типичная идея современного веба последних лет возвращение к платформенным API. Браузер уже умеет работать со звуком через Web Audio API, поэтому библиотека выступает лишь тонким слоем абстракции над ним. В-третьих, композиция. Практически всё представлено в виде элементов, которые можно комбинировать между собой. Отдельное направление проекта — генеративная музыка. Библиотека поддерживает работу со случайными последовательностями, полиритмией, случайными модуляциями параметров и различными способами генерации звуковых событий. Благодаря этому её можно использовать не только для написания музыкальных партий, но и для создания процедурного звука, например в играх или интерактивных веб-приложениях. С точки зрения архитектуры фронтенда проект любопытен тем, что переносит идеи Web Components и декларативного UI в совершенно другую область. Если React описывает интерфейсы, то HYPERBLAM пытается описывать музыку. Его можно рассматривать не столько как музыкальную библиотеку, сколько как эксперимент по созданию языка описания звука поверх HTML и Web Audio API.

Preview Next.js 16.3 TL;DR Главная идея: server-driven приложение теперь может ощущаться как SPA, если на каждом async-await явно выбрать Stream / Cache / Block. Prefetching стал адекватным — один shell на роут вместо запроса на каждую ссылку. Ден Абрамов присоединился к команде Next.js и Vercel. (на парт-тайме) Решил две новости в одну совместить. Ден с своей стороны будет не замыленным взглядом помогать закрыть пробелы в распространенных кейсах использования от маленьких блогов до больших проектов. Как он говорит: — the team has been working hard at fixing many of those gaps. i hope to provide an additional “casual Next.js user“ voice to help prioritize the ones that bite people the most. Теперь про обновление. 16.3 приносит нам Мгновенную навигацию. Проблематика: Навигация ощущается медленной, когда запросы на стороне сервера ожидаются для отрисовки страницы. Для сохранения серверной модели и создание SPA-ощущений завозят следующие инструменты. Cache Components Всё работает за флагом cacheComponents: true в next.config.ts. В будущем мажоре станет дефолтом. Курс на «dynamic by default, без скрытого кеширования». Три стратегии для async-операций Когда роут await-ит данные на сервере, теперь надо явно выбрать поведение: * Stream через <Suspense> — юзер мгновенно видит loading-стейт, контент стримится. * Cache через 'use cache' — мгновенно показывается закешированная UI. * Block через export const instant = false на странице/лейауте — осознанно говорим «эта навигация ждёт сервер» (например, для блог-постов, где не хочется shell-а). Stream/Cache → навигация мгновенная. Block → явный opt-out. Медленные навигации без Block теперь подсвечиваются как ошибки в dev через панель Instant Insights. Partial Prefetching (отдельный флаг partialPrefetching: true) Раньше Next делал prefetch-запрос на каждую ссылку во вьюпорте — в Network вкладке был ад из запросов. Теперь: * Prefetch-ится один переиспользуемый shell на роут, не на ссылку. 20 ссылок на /chat/[id] → один запрос на shell этого роута. * Shell-ы кешируются на клиенте на сессию. Концептуально как code-splitting по роутам в SPA. * Это же основа для будущей offline-навигации. Если нужно prefetch-ить больше чем shell — <Link prefetch={true}> плюс 'use cache' на нужных кусках. По умолчанию ограничено build-time контентом; export const prefetch = 'allow-runtime' расширяет до request-time кеша (ценой нагрузки на сервер). Тулинг * Instant Insights — панель в devtools, помечает не-instant роуты ошибками в dev. * Navigation Inspector — ставит навигацию на паузу на этапе shell, видно что реально prefetch-ится, что грузится после. * instant() helper для Playwright (@next/playwright) — ассерт, что после клика что-то видно мгновенно, без ожидания network. * Есть skill для агента для миграции существующих проектов на Cache Components.

React Compiler на Rust уже почти готов Команда React завершает перенос React Compiler с TypeScript на Rust. Новая реализация уже используется внутри компании и показывает хорошие результаты: • 99.9% паритета с текущей TS-версией • около 25% прироста производительности • улучшенная интеграция с SWC и OXC Разработчики отдельно отметили, что значительная часть портирования проходов компилятора была выполнена с помощью ИИ. Сейчас идёт финальная полировка, тестирование и сбор обратной связи. Слияние ожидается в ближайшие недели. Похоже, один из самых важных инструментов React-экосистемы скоро получит Rust версию. https://github.com/oxc-project/oxc/pull/22942 https://github.com/oxc-project/oxc/issues/10048 https://github.com/facebook/react/pull/36173#issuecomment-4608356402

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

React исполнилось 13 лет — первый релиз состоялся 29 мая 2013 года. Я использую React с 2017 года для создания самых разных приложений. За это время успел поработать как с проектами, которые проектировал сам, так и с теми, которые достались в наследство. Сразу оговорюсь: тут не будет технических инсайдов или рассказов про новые API. Скорее это набор выводов и наблюдений, которые накопились за почти 10 лет работы. React сегодня кажется есть везде, где присутствует фронтенд. Веб-приложения, терминалы, 3D-сцены, аудио-интерфейсы — экосистема давно вышла далеко за пределы браузерных страниц. Главная идея React при этом остается неизменной: из простых компонентов собирать более сложные системы. Концепция выглядит простой, но именно вокруг нее возникает большинство архитектурных проблем. Не случайно существует статья Thinking in React. Многие команды читают документацию по API, но пропускают сам подход к проектированию интерфейсов. В проектах, которые мне приходилось поддерживать, основные сложности обычно возникали именно из-за этого. Появлялись чрезмерно сложные компоненты, неудобные API, неожиданные побочные эффекты и баги, связанные с ререндерами. Отдельная проблема — структура проекта. Часто все компоненты складываются в одну папку независимо от назначения: общие, доменные, виджеты, страницы. Со временем навигация по такому проекту становится сложнее, а границы ответственности размываются. Несколько принципов, которые я для себя вынес за эти годы. Один файл — один компонент. То же касается функций и констант. Такой подход упрощает навигацию, улучшает переиспользование и помогает инструментам сборки эффективнее работать с tree shaking. Линтеры на архитектурные границы тоже будет проще настроить и этим жанглировать. Используйте композицию и слоты. Компонент должен предоставлять точки расширения, а не пытаться предусмотреть все варианты использования заранее. Проектируйте API компонентов через поведение, а не через место использования. Когда в компоненте появляются пропсы вроде isAdmin, isMobile или другие флаги, описывающие контекст использования, это часто сигнал того, что ответственность оказалась не на своем месте. Решение о том, какой сценарий нужен, должно приниматься снаружи. Компоненту лучше сообщать, что делать, а не где он находится. Должно получиться что-то "Я вставил компоненты из витрины, и он работает, а теперь докручу изменениями пропсов его вид" Не бойтесь копировать композицию компонентов, если это делает код понятнее. Поддерживать несколько похожих сценариев зачастую проще, чем разбираться в большом универсальном компоненте с множеством условных веток. Раньше такой подход действительно вызывал вопросы о поддерживаемости. Сегодня рефакторинг через AST-кодмоды, автоматизацию и ИИ-инструменты заметно снижает стоимость подобных изменений описывая их на естественном языке. Создавайте локальный state только для логики интерфейса. Не стоит превращать каждый компонент в хранилище бизнес-логики. Используйте Context там, где его действительно сильные стороны раскрываются. Например, когда значение может переопределяться ниже по дереву компонентов и менять поведение вложенных элементов. Особенно полезно это бывает в рекурсивных компонентах. Читайте раздел Escape Hatches на react.dev. Многие спорные решения уже подробно разобраны авторами React, и понимание этих ограничений помогает избежать архитектурных ошибок. Общие компоненты стоит выносить за пределы конкретного приложения: в UI Kit пакет, воркспейс или монорепозиторий. Внутри самого приложения основной фокус должен оставаться на доменной модели и бизнес-задачах. И последнее — следите за экосистемой и обновляйте зависимости вовремя. Откладывать обновления удобно только в краткосрочной перспективе. Со временем накапливается технический долг, а очередное обновление React, библиотеки из стека или экосистемы начинает требовать обновления TypeScript, сборщика (переход на ESM), инфраструктуры и прикладного кода одновременно. В результате простая задача превращается в технические релизы.

Думаем.

Ржу Смотрите на hold и trial fsd

Второй день Holyjs. Был уже на докладе про реактивный css. Полезный и крутой доклад. Сейчас на докладе по LLM.

Первые доклады начались. Кто на конференции пишите, пообщаемся в перерывах.

14-15 Мая буду на Holyjs 2026 Spring. Есть интересные доклады для меня, плюс добавили ИИ трек. Вообще еще думаю залететь на дебаты, не помню, чтобы раньше было такое. В этом сезоне чувствуется, что было какое-то большое переосмысление. Кто точно пойдет, пишите, можем понетворкаться. Если тоже хотите на конфу, пишите мне в личку, подскажу как лучше это сделать.

🤟 представляю лицо редакторов и дизайнеров, которые корпели над текстовками, чтобы они уместились в блок, а потом яндекс выкатывает эту имбу. CLS нравится

tiks Процедурные звуки для веб интерфейса. Без аудиофайлов. Чистый синтез. В нативных приложениях звук часть UX: клики тоглов, нажатия клавиш, нотификации. В вебе обычно тишина. tiks закрывает этот пробел через Web Audio API — все звуки генерируются на лету: осцилляторы, шум, кривые. Никаких mp3. Только математика. Общий движок синтеза — получается единая «звуковая тема». Всё звучит консистентно, а не как набор случайных эффектов. Размер: core ~2KB react hook ~300B vue composable ~300B Доступность: — respects prefers-reduced-motion (можно автозаглушить) — звук не заменяет визуал, только дополняет — глобальный mute tiks.mute() — дефолтная громкость 30% https://github.com/rexa-developer/tiks Демо

STORM — фреймворк для создания terminal UI на основе композитора, который рассматривает терминал как display server, а не просто поток текста. Использует cell-level diff, typed arrays и Dual-speed rendering (React дает структуру, requestRender() — 60фпс) для высокой производительности и минимального GC. Написан на TypeScript, поддерживает flexbox и CSS Grid, но требует учитывать особенности собственного reconciler.

Сhrome's DevTools MCP теперь включает: * Проверки производительности через Lighthouse * Навык обнаружения утечек памяти * Навык отладки доступности * Навык оптимизации LCP и экспериментальный новый CLI https://github.com/ChromeDevTools/chrome-devtools-mcp

Переезжал с Jest 30 на Vitest и оказалось, что это не такая уж “замена одного на другое”, как кажется сначала. В документации про это пишут, но лучше сразу быть готовым — моки работают по-разному. Простая замена jest.* на vi.* не дает того же поведения. Где-то ломается hoisting, где-то импорт происходит раньше моков, и внезапно тесты начинают вести себя иначе. Ожидал, что Vitest будет быстрее, но это тоже не всегда так. Jest в связке с swc, может оказаться быстрее. В моем случае vitest оказался медленнее. Vitest может показать, куда уходит время — transform, setup, import, tests, environment — и становится видно, что иногда узкое место вообще не там, где ожидаешь. Попробовал пойти по стандартному пути — увеличить количество воркеров, поиграться с pool. Прироста не увидел. Тогда начал копать дальше и дошел до того, что Vitest по умолчанию гоняет тесты в изоляции через forks. Это безопасно, но дорого. Отключил изоляцию и включил параллельность: test: { isolate: false, pool: "threads", sequence: { concurrent: true, }, } Тесты действительно начали работать быстрее, но почти сразу всё развалилось. Начали падать тесты, которые раньше были стабильны. Причина довольно простая — окружение перестает очищаться. DOM, моки, глобальное состояние — всё начинает течь между тестами. Документация об этом прямо говорит, но пока сам не упрешься, не очень очевидно, насколько это критично. Даже с учетом сетап файла afterEach(() => { cleanup(); }); Цитирую документацию: This greatly increases test times, which might not be desirable for projects that don't rely on side effects and properly cleanup their state (which is usually true for projects with node environment). In this case disabling isolation will improve the speed of your tests. Нужно писать тесты так, чтобы они не зависели от побочных эффектов, очищать явно моки, и следить чтобы состояния сбрасывалось между тестами. (В Jest это как-то все само работало). Тогда тесты будут быстрыми и получите бенефиты не только по DX, но и по скорости. Отдельная проблема всплыла с Material UI 5. У нас используются компоненты и иконки, и пакет сам по себе не очень дружит с ESM. Он тянет barrel файлы с реэкспортами, и в итоге импорт получается тяжелым. Vitest это хорошо подсвечивает через метрики. В моем случае import занимал около 400ms. Замокал иконки — стало примерно 200ms, уже заметно лучше. Между строк. Про environment. По умолчанию используется jsdom, он тяжелый. Можно попробовать заменить на happydom, если не нужны сложные DOM API. Иногда это дает ощутимый прирост. Дальше попробовал классический подход — заменить импорты с @mui/material на точечные @mui/material/Button. Ожидал, что начнет подтягиваться только конкретный компонент, но эффекта не было. Начал разбираться через devtools Vitest, и там стало видно, что резолвится node-версия пакета, внутри которой всё равно используются те же barrel файлы. То есть как ни меняй импорт, фактически подтягивается почти всё. Оказалось, что внутри mui есть несколько сборок — node, modern, cjs. И Vitest по умолчанию берет не ту, которая лучше всего подходит для tree-shaking. Дальше идея — попробовать алиас на modern сборку и посмотреть, даст ли это выигрыш по import времени. В моем случае замена на modern только ухудшила метрики import, из вариантов улучшить, это попробовать перенести babel-plugin-import на rolldown. Итоги переезда вскрыли проблемы импортов (я еще нашел циклические импорты), старых зависимостей, то как пишутся тесты. Вывод такой, нужно держать руку на пульсе и следить за тех долгом. Современные, быстрые инструменты улучшают DX, это как и локальный запуск, так и быстрый cicd, лучше фидбек что идет не так.

Basewatch Инструмент для отслеживания изменений в web-platform и браузерной поддержке. Помогает понимать, какие фичи стали baseline и когда их можно безопасно использовать в продакшене. Полезен для принятия решений о внедрении новых API без лишнего риска. Используемые источники это MDN Browser Compat Data, CanIUse, Web Platform Baseline, Chrome Status. Также можно подписаться на отслеживание конкретных фич, когда поддержка достигнет определенного процента.

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