Rune: UI-фреймворк на Rust, который пишут и проверяют ИИ-агенты
Команда OpenCode открыла Rune — фреймворк для десктопных и веб-интерфейсов с собственным GPU-рендерером. Разбираем, как он устроен, чем отличается от GPUI и почему строить на нём продукт пока рано.
ИИ-агент дописал экран настроек и сообщил, что всё готово. Проверить это он не может: чтобы увидеть результат, нужно собрать приложение, открыть окно и посмотреть на него глазами. Обычно это делает человек, и именно здесь агентная разработка интерфейсов упирается в потолок.
Rune — попытка этот потолок убрать. Это открытый UI-фреймворк на Rust от компании Anomaly, которая делает OpenCode. Он рисует интерфейс на видеокарте, работает на macOS, Windows, Linux и в браузере, а главное — любое приложение на нём можно запустить без окна и проверить программно.
Оговоримся сразу: мы изучали документацию проекта, его план развития и обсуждение в сообществе, но сами приложения на Rune не собирали. Всё, что ниже сказано о скорости и плавности, — цели авторов, а не наши замеры.
Авторы описывают его так: нативный фреймворк с GPU-рендерингом, у которого свои рендерер, текст, раскладка и пружинные анимации. Слово «нативный» здесь значит, что приложение не тащит с собой браузерный движок, как Electron, и не рисует через системный WebView, как Tauri. При этом выглядит оно на всех системах одинаково: фреймворк не подражает стандартным элементам каждой ОС.
В плане проекта записаны четыре принципа. Первый — «ощущение и есть продукт»: цель 120 кадров в секунду и анимации, которые можно прервать на полпути. Второй — анимация не проходит через код приложения. Третий — нативное поведение при едином внешнем виде: ввод текста, буфер обмена и доступность берутся у системы. Четвёртый — зависеть можно от библиотек, но не от чужого UI-фреймворка.
Rune не изобретает всё с нуля. Собственные у него рендерер, дерево элементов и анимации, а раскладку, текст и доступность он берёт из готовых библиотек экосистемы Rust.
Из чего собран Rune
Слой и решение
Что это даёт
Рендеринг: wgpu, один проход с SDF-примитивами, атлас глифов
Один код отрисовки на всех платформах, включая браузер
Окна: winit, в планах свои оболочки под каждую ОС
Быстрый старт; свои оболочки нужны ради полноценного ввода на разных языках
Раскладка: Taffy
Привычные flex, grid и block
Текст: Parley, HarfRust, skrifa, fontique
Шейпинг и подбор шрифтов без собственного текстового движка
Анимация: аналитические пружины в потоке рендера
Занятый основной поток не вызывает рывков
Доступность: AccessKit
Одно дерево и для скринридера, и для инспектора
Состояние: дерево с ключами, пересобираемое из view-функций
Обычные функции и типизированная модель, без сигналов
Самое необычное решение — анимации. В большинстве фреймворков каждый кадр анимации проходит через код приложения: если основной поток занят, движение дёргается. В Rune приложение один раз описывает, куда элемент должен прийти и с какой пружиной, а дальше движение ведёт поток рендера.
Интерфейс описывается цепочкой вызовов без макросов и отдельного языка разметки. Так выглядит фрагмент переключателя из примера в документации:
Роль, подпись и состояние элемента задаются там же, где его размер и скругление. Благодаря этому одно и то же описание читают и вспомогательные технологии, и агент.
Главное отличие Rune от соседей — headless-режим. Приложение запускается без окна, и дальше с ним можно делать три вещи:
— отрисовать текущий экран в PNG и сравнить с ожидаемым;
— выгрузить дерево элементов с ролями, подписями и состояниями;
— подать скриптованный ввод: нажатия, набор текста, перемещение фокуса.
Вместе это замыкает цикл: агент меняет код, запускает приложение, смотрит на результат и исправляет ошибку без участия человека. Для обычной разработки это тоже полезно — те же инструменты годятся для автоматических тестов интерфейса.
Агентам адресован и сам процесс разработки. В репозитории лежат правила для них: держать файлы короче 800 строк, описывать режимы перечислениями, не переписывать историю основной ветки. В плане прямо сказано, что код пишут и поддерживают агенты. А запросы на слияние от людей проект не принимает: вместо этого предлагают, чтобы ваш агент завёл задачу с описанием ошибки или идеи.
«
Rune отвечает на вопрос, который раньше не задавали: каким должен быть UI-фреймворк, если его основной пользователь — не человек, а агент.
Ближайший родственник Rune — GPUI, фреймворк редактора Zed. Он тоже написан на Rust и тоже рисует на видеокарте. Авторы Rune рассматривали вариант взять его за основу и записали вердикт: не делать форк, начать с чистого листа и забрать лучшие идеи.
Претензии к GPUI у них конкретные. Он перерисовывает окно целиком при любом изменении, не умеет композитинг слоёв и групповую прозрачность, а анимации в нём заново строят интерфейс в основном потоке. Нет пружин и эффекта матового стекла, на Windows есть проблемы с фокусом. Насколько эти ограничения важны, зависит от задачи: редактору кода они не мешают, а приложению с плавающими панелями и живыми переходами — мешают.
Rune находится в стадии пред-релиза, и авторы этого не скрывают. Версий нет: подключать его предлагают как git-зависимость с закреплённой ревизией рабочей ветки. Интерфейсы меняются часто.
— Настольные системы — основная цель: macOS, Windows и Linux развиваются вместе.
— Веб-сборка экспериментальная: нет запасного режима без WebGPU и не доделана доступность.
— iOS и Android стоят в плане последними этапами.
— В продукте Rune уже работает в Hex, приложении Anomaly для голосовой диктовки: на нём сделаны настройки и плавающие окна.
— Главным испытанием авторы называют воссоздание OpenCode Desktop. Заменит ли Rune нынешнюю версию на Electron, они оставляют открытым вопросом.
Сообщество встретило проект неоднозначно. Репозиторий за несколько дней собрал тысячи звёзд, но обсуждение получилось острым.
Чаще всего Rune называют продуктом «вайб-кодинга»: раз код пишут агенты, непонятно, кто отвечает за его качество. Спорили и о тестах — одни участники утверждали, что их нет, другие показывали каталог с тестами компонентов. Документацию ругали за то, что она написана скорее для агента, чем для человека, и за отсутствие живого демо.
Отдельная группа вопросов осталась без внятных ответов: поддержка скринридеров, письменность справа налево, работа на машинах без подходящей видеокарты. Часть участников жаловалась на размытый текст. Отказ принимать код от людей тоже понравился не всем.
Хвалили при этом именно то, что отличает Rune от остальных: headless-режим и анимации в потоке рендера. Некоторые прямо писали, что хотели бы видеть такую возможность в системных фреймворках.
Rune интересен в двух случаях. Первый — вы исследуете агентную разработку интерфейсов и хотите посмотреть, как выглядит инструмент, спроектированный под неё с самого начала. Второй — вам нужен образец идей: проверка интерфейса без окна и общее дерево для доступности и автотестов пригодятся в любом стеке.
Если же задача — выпустить настольное приложение на Rust в обозримые сроки, выбирать стоит из более зрелых вариантов: GPUI, Iced, egui или Slint. А когда важнее скорость разработки и готовая экосистема, чем расход памяти, Tauri и Electron по-прежнему остаются рабочим выбором. К Rune имеет смысл вернуться, когда у него появятся версии и первое большое приложение, собранное на нём целиком.
