HolyJS 2026 Spring

Мы находимся на пороге нового подхода к построению интерфейсов — AI-Driven UI. Здесь ИИ перестает быть просто помощником и начинает участвовать в формировании самого интерфейса.

В конце лета я выступал на одной конференции с докладом LLM-Driven UI, где показал, почему генерация HTML или React-кода в рантайме с помощью LLM не выглядит эффектно и практике оказывается нестабильной и дорогой. Вместо этого я предложил другой подход: LLM генерирует не код, а JSON-схему интерфейса, а фронтенд рендерит ее через заранее описанные компоненты.

Недавно Google представил A2UI — open-source решение с тем же принципом разделения логики агента и визуального слоя. Это подтверждает, что AI-Driven UI становится самостоятельным направлением.

В новом докладе покажу практическую реализацию: собственного агента на Node.js и клиентский рендеринг через web-components в духе A2UI. Разберем архитектуру, ограничения и реальные сценарии применения.

Доклад будет полезен фронтенд- и фулстек-разработчикам, которым важно понимать, как меняется роль UI-архитектуры в эпоху ИИ.

Фронтендеры привыкли бороться за производительность кодом: минификация, tree-shaking, lazy loading. Но что, если настоящие приросты производительности скрываются в инфраструктуре?

Разберем техники, которые дают заметный процент ускорения без изменения клиентского кода.

103 Early Hints — эволюция Server Push, которая работает.

TCP+TLS 0-RTT и QUIC — сократить рукопожатие до минимума.

Квантовые (или не очень) шифры: влияние выбора алгоритмов (RSA vs ED25519) и OCSP Stapling на скорость соединения.

Файловые системы и sendfile — зачем читать файлы с диска, если они уже в памяти? Компилируем статику в бинарник сервера или используем системные трюки.

Zstd vs Brotli — новый король компрессии для динамических запросов.

Спекулятивные правила Chromium — предзагрузка целых страниц ДО клика по ссылке.

Роль Service Worker как перехватчика запросов до основного потока.

Современные форматы изображений/видео/шрифтов. Отдайте браузеру контроль над выбором.

Мы разберем реальные бенчмарки, совместимость с Nginx/Angie и покажем, как внедрить эти техники для продакшена.

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

Начнем с LLM, посмотрим, как LLM превращается в агента, а агент — в агентскую систему. Напишем игрушечного агента с локальной LLM, а поверх него — свою систему оркестрации. Попутно посмотрим на основные сложности и варианты их решения.

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

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

Почему бы не рассмотреть другие подходы, обычные и привычные для бэкенд-мира, взять лучшее и объединить с компонентным подходом? Мы разберем такие архитектуры, как MVC, MVVM, DDD, Clean, и попробуем сделать из этого FDA (Fractal Domain Architecture) — фрактальную архитектуру, которая отлично ложится на современные метафреймворки и легко масштабируется в сотни тысяч строк кода. Подход, в котором домены и бизнес-требования, а не абстракции разработчиков, становятся основой системы и расширяются как горизонтально, так и вглубь.

Доклад основан на реальном кейсе: команда РСХБ была вынуждена в сжатые сроки перевести брокерское приложение с нативного Swift на PWA после блокировки банковских приложений в App Store. Разбираем, почему был выбран React, а не Angular, Vue или Svelte, и как архитектурные решения нативной разработки адаптировались под веб-стек.

Отдельный блок посвящен техническим ограничениям Safari и WebKit, с которыми неизбежно столкнется любой, кто пойдет этим путем: агрессивная очистка хранилища, изоляция контейнеров, отсутствие нативного install prompt и нестабильный Deep Linking. На конкретных примерах разобраны обходные пути: от механизма Deferred Deep Linking через Cookie-снапшот при установке до управления ориентацией экрана и восстановления состояния форм.

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

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

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

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

Расскажу, как продать идею кеширования в своей компании, что там по метрикам и как понять, надо ли оно вам вообще. Бонусом — неочевидные пути развития системы кеширования.

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

Покажу практики, которые мы уже применили в проде: типизированную модель роутинга с выводом параметров, безопасный экспорт дизайн-токенов и иконик из Figma, проверяемые CSS Modules и CSS Variables, типизацию i18next, ENV-конфигов и feature toggles, а также API и MobX как центральный слой приложения. Мы посмотрим, что происходит, когда типизированной информации становится слишком много: в какой момент начинают «умирать» компиляция и линтинг и какие инженерные приемы позволяют удержать систему в рабочем состоянии.

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

Расскажу не только о том, что прижилось, но и об экспериментах, которые оказались неудачными.

Это не лекция, будет много лайвов, вы увидите, как вся эта магия работает прямо на ваших глазах!

Как фронтендеру отличить плохой UX от хорошего без помощи дизайнера.

Фронтенд-разработчик неизбежно влияет на UX, тем более если в команде нет UX-дизайнера. Но как понять, что интерфейс действительно удобный, а не просто «работает»?

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

Много разговоров про «компилируемые» JavaScript-фреймворки и их высокую производительность в сравнении с фреймворками, использующими vdom. На примере одного популярного бенчмарка рассмотрим, как React справляется с тест-кейсами, заглянем под капот, чтобы понять причины просадки производительности, и что с этим делать.

Действительно ли React проиграл гонку за перформанс? Или он вполне способен потягаться с такими фреймворками, как SolidJS? Разберемся в нюансах и сделаем вывод: пора переходить или все же рано списывать его со счетов.