UI-инженерия в эпоху ИИ

12/12/2025 инженер Zed mikayla-maki закрыла PR с предложением добавить в GPUI пользовательские shader. Ответ был вежливым: сначала благодарность за вклад, затем объяснение: “we’re shifting focus to core product work at Zed, and without a Zed use case, I can’t validate this code”. В конце стоял смайлик.

GPUI — собственный GPU-фреймворк интерфейсов Zed. Его часто вспоминают среди альтернатив Electron. Менее чем за четыре месяца до этого Zed объявила о раунде на 32,000,000 долларов под руководством Sequoia. Общий объём инвестиций превысил 42,000,000 долларов.

Спустя девять с лишним месяцев, 26/9/2026, разработчик egoist создал репозиторий MyGo. За 39 дней в нём появилось 1,042 коммита, из них 890 — с подписью Claude.

Claude разрабатывает Anthropic. Собственное настольное приложение Anthropic использует Electron.

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

Настольные приложения Claude и Codex по-прежнему используют Electron: у Web зрелая экосистема, одна кодовая база работает на разных платформах, а модели хорошо её знают. ИИ снижает стоимость разработки, но совместимость и сопровождение разных платформ всё ещё требуют усилий.

Собственная GPU-отрисовка предлагает другой путь, однако GPUI по-прежнему отдаёт приоритет Zed. Кроссплатформенный рендеринг и экосистема компонентов требуют долгой работы. MyGo показывает, как ИИ и готовые компоненты ускоряют старт, но зрелость в эксплуатации и долгосрочная сопровождаемость ещё не подтверждены.

Flutter, Compose, Slint, egui и iced предлагают разные компромиссы. Мы протестировали 10 фреймворков в одинаковых сценариях, измерив плавность, CPU, память и точность воспроизведения дизайна, чтобы выяснить реальную цену каждого подхода.

Мы протестировали 10 фреймворков с одинаковыми сценариями на Apple M4 Max и ThinkPad T14 Gen6. На обеих платформах измеряли CPU и память; для Windows также есть внешние измерения кадров через PresentMon. Кадровые колбэки Mac различаются между фреймворками и не используются для сравнения. Аппаратная часть и показатели памяти тоже отличаются, поэтому сравнение проводится только внутри каждой платформы.

Анимация — плотная сцена: 500 карточек размером 96×64 логических пикселя перекрываются в 25 столбцах. У каждой скругление 12, градиент 135° и тень с blur 16 и смещением вниз 4. Координаты всех карточек обновляются покадрово: они движутся по окружностям радиусом 12 с периодом 4 секунды. Приведена медиана пяти запусков по 30 секунд.

В основном измеряется нагрузка CPU при обновлении интерфейса, подготовке рисования и отправке рендеринга множества непрерывно движущихся элементов с эффектами, а также стабильность вывода кадров. CPU учитывает дерево процессов приложения, а не загрузку GPU или время отдельных этапов. Его нужно читать вместе с интервалами кадров: меньше кадров тоже может означать меньшую нагрузку CPU. 500 — число карточек в сцене; перекрытия и обрезка окном означают, что не все они полностью рисуются в каждом кадре.

Windows

С прокруткой списка справились все. Разница проявилась в анимации: на 500 карточках с тенями и градиентами фреймворки на Rust и Go с собственной отрисовкой в основном удерживали 120Hz. У Flutter, Electron, Tauri и Compose интервал между кадрами вырос до 80–160ms. Значение WPF в 684ms было вызвано 500 отдельными эффектами тени. После их отключения оно вернулось к 8.3ms, поэтому это не общая проблема.

Редактирование текста — ещё один барьер. При вставке 10 символов в секунду в документ из 5,000 строк Flutter, Compose и Slint полностью загружали одно ядро. Flutter в Windows также терял тридцать процентов ввода.

Mac

На Mac CPU анимации составлял около 15%–20% у GPUI, MyGo, egui и iced, 237% у Flutter и примерно 100% у Electron и Compose. При редактировании текста Flutter и Compose по-прежнему занимали почти целое ядро. У Slint было 52%, ниже его 99% в Windows.

В сцене списка примерно 40 MiB у SwiftUI, 340 MiB у GPUI и 800 MiB у egui прежде всего описывают память процессов приложения. Нативный UI может использовать системные службы рендеринга вне приложения: Apple указывает, что AppKit предпочитает рендерить дерево слоёв вне процесса. Часть рисования и композиции выполняется там. Собственные рендереры также используют системную композицию, но по одним процессам приложения нельзя сравнивать распределение работы. Унифицированная память чипов M означает общую физическую память CPU и GPU, а не учёт всех затрат в phys_footprint приложения.

В пяти коротких GPU-трассировках для каждой из сцен списка и анимации SwiftUI не наблюдались события исполнения GPU для PID приложения, тогда как WindowServer был активен. Это не означает, что SwiftUI не использует GPU, и не позволяет приписать ему весь рабочий стол. Базовая память WindowServer колебалась примерно на 205 MiB; отсутствие крупных общих объектов на снимках также не исключает повторное использование существующих системных ресурсов. Данные показывают лишь меньшую память процесса SwiftUI, но не меньшие полные затраты рендеринга и не оплату всей разницы системой.

Эти цифры относятся только к двум нашим компьютерам, этим версиям и написанным нами тестовым программам. Методика и полные данные приведены в разделе 05.

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

Многие фреймворки также используют сохранение данных, кеширование и частичные обновления, чтобы не повторять расчёт компоновки и отрисовку. GPUI сочетает immediate и retained mode. Модель интерфейса, возможность повторного использования работы и время отрисовки кадра — разные вопросы.

MyGo, iced, GPUI, Slint и egui хорошо справляются с анимациями при низкой загрузке CPU. Slint потребляет меньше всего памяти, egui — довольно много, а компоненты редактирования для GPUI нужно добавлять самостоятельно. MyGo сейчас используется главным образом в приложениях самого автора и ещё не прошёл масштабной проверки в реальных условиях эксплуатации.

У Flutter, Electron и Compose также были неудовлетворительные интервалы кадров и потребление ресурсов в этом нагрузочном тесте анимации. Пакет Tauri занимает всего 11 MB, но потребление памяти во время работы примерно такое же, как у Electron.

Сейчас мы считаем проверку важнее рендеринга.

Писать код стало дешевле, но проверка его правильности по-прежнему требует времени. В опросе разработчиков Stack Overflow за 2025 год 66% сталкивались с ответами ИИ “almost right, but not quite”, а 45.2% говорили, что отладка кода ИИ занимает больше времени. В опросе Sonar, опубликованном в 01/2026, 96% не полностью доверяли функциональной корректности сгенерированного кода. Только 48% утверждали, что всегда проверяют его до коммита. Sonar продаёт инструменты проверки кода, поэтому к цифрам стоит относиться с оговоркой, но они согласуются с предыдущим опросом.

Релизы Slint и egui прошли почти незаметно. Мы считаем их важнее прогресса в рендеринге. Агент должен уметь подавать ввод и делать скриншоты, чтобы что-то изменить, посмотреть и исправить снова. Раньше проверка интерфейса требовала человека у компьютера, который всё прокликивал. Теперь эту работу постепенно можно передавать машине.

Сейчас есть три подхода. У кроссплатформенного Web больше всего накопленных средств. Собственная отрисовка на GPU не требует браузера в комплекте, а порог её создания стал ниже. Нативное приложение для каждой платформы — самый старый способ. Раньше несколько команд могли содержать лишь крупные компании. Сейчас сложность — в утроении числа багов и объёма поддержки, о котором говорит Breunig. Если проверка подешевеет, а качество вырастет, прямая генерация нативного приложения для каждой платформы тоже может оказаться рабочим вариантом.

Мы тоже пробуем собственный GPU UI. Отличие — в переносе значительной части DX из Web: компонентов в духе JSX, стилей в духе CSS, компоновки flexbox, реактивного состояния и DevTools как в браузере, с последующей компиляцией в нативный код. Проект ещё на ранней стадии.

Мы не знаем, какой ответ победит. Возможно, несколько будут сосуществовать долго. Три факта из начала статьи не изменились. PR по-прежнему закрыт, MyGo растёт, а настольный Claude всё ещё использует Electron. Это очень интересное время.

Тестирование проходило с 4 по 6 ноября 2026 года. Для каждого фреймворка реализовали одни и те же сценарии, используя рекомендуемые подходы, настройки по умолчанию и релизные сборки. После исправления размытия повторно измерили страницу дизайна Compose и сценарий простоя, который использует ту же реализацию.

Каждый сценарий для каждого фреймворка запускали 5 раз по 30 секунд, последовательно, в перемешанном порядке. Все значения ниже — медианы. Медианный размах между 5 прогонами составил около 3%, девять десятых укладывались в 24%. Список и анимацию измерили повторно после унификации требований, поэтому столбцы собраны не в одно время. Одно логическое ядро — 100% CPU. Для многопроцессных приложений учтены все дочерние процессы. Для Tauri на Mac также учтены процессы WebKit, запущенные системой для него. В кадровые данные Windows вошли только прогоны, однозначно относящиеся к одному swapchain и без потери записей.

Для потока и правки проверили фактически выполненный объём: Flutter в Windows завершил только 68% правки, остальные — более 99%.

Соответствие дизайну

Проверка размытия требует плавных переходов между цветными полосами на заданной панели внутри окна. Применение Modifier.blur с радиусом 24 dp к слою с полосами в Compose 1.12.2 дало плавные переходы на снимках нативных окон в macOS и Windows. SwiftUI тоже сначала размывает известный слой с полосами, затем добавляет полупрозрачную белую заливку. В обоих случаях проверялся именно этот слой. API Compose Desktop

В протестированных реализациях GPUI, iced, egui и Slint поверх полос наложен полупрозрачный слой. При повторной проверке границы полос остались резкими. Blurred в GPUI и window::Settings::blur в iced воздействуют на содержимое за окном. Во встроенных API рисования протестированных версий не обнаружено локального размытия фона. В iced локальные эффекты можно рисовать самостоятельно, а egui позволяет обращаться к бэкенду через PaintCallback. GPUI · Настройки окна iced · Колбэк рисования egui

Slint тестировали в версии 1.18.1 с FemtoVG. В этой версии у элементов не было свойства backdrop-blur. Позже разработчики добавили его для рендерера Skia. На снимках показан рендеринг FemtoVG в версии 1.18.1. Задача в репозитории Slint

Страница дизайна содержит 11 проверок. GPUI, egui, iced, Slint и Compose не воспроизвели образец P3 в проверенном выводе Mac. У снимков Windows нет цветового профиля, поэтому P3 не оценивается; флаги emoji отображаются буквами.

Компоновка становится похожей, а текст различается сильнее всего. Когда iced запрашивал PingFang 700 в macOS, латинские буквы подменялись Menlo Bold.

Ограничения:

• Только один компьютер на платформу. Анимацию измеряли на встроенной GPU Intel; результаты могут не подходить для дискретных GPU.
• Mac во время тестов не простаивал. Кадровые данные — только колбэки приложения, для сравнения фреймворков они не используются.
• Семантика blur у теней различается. egui, iced и GPUI используют приближения. Компоненты редактирования тоже не равноценны: GPUI использует изменённый пример редактора.
• Таблицы CPU и памяти учитывают приложение и включённые вспомогательные процессы. Затраты WindowServer и драйвера не распределены по окнам, выгода повторного использования общих системных ресурсов не измерена; ранжировать полные системные затраты рендеринга по этим таблицам нельзя.
• Не удалось получить достоверные результаты для окон кандидатов метода ввода, дерева доступности Mac и энергопотребления.