На днях команда Opencode объявила, что переводит десктопное приложение с Tauri на Electron. Формулировка у них жёсткая: новая сборка быстрее, надёжнее и скоро заменит текущую Tauri-версию. На фоне многолетнего нарратива «Electron тяжёлый, Tauri лёгкий и современный» это выглядит почти как ересь. Но если внимательно посмотреть на аргументы команды, получается куда более интересная история: для AI-продуктов победителя выбирает не размер бинарника, а количество архитектурных компромиссов.
Миграция в «неправильную» сторону
У десктопной разработки последних лет есть почти религиозный сюжет. Electron считают старым, прожорливым и слишком тяжёлым. Tauri, наоборот, продаётся как аккуратная современная альтернатива: меньше размер приложения, меньше памяти, более «нативный» стек, Rust на бэкенде, системный webview вместо встроенного Chromium.
Поэтому новости обычно выглядят так: очередной проект уходит с Electron на Tauri. Именно так принято «эволюционировать».
Opencode сделал обратное. Команда сообщила, что перевела десктоп на Electron, а Tauri-сборка будет заменена после периода беты. В X это сформулировали без попытки смягчить удар: Electron-версия, по их словам, получилась быстрее и надёжнее.
И вот это важный сигнал. Когда проект делает обратную миграцию на глазах у техно-Твиттера, это обычно значит не «мы не знаем про вес приложений», а «мы упёрлись в реальные ограничения, которые важнее теоретической красоты».
Что именно сказала команда Opencode
Если собрать вместе сам анонс и ответы команды в треде, получается довольно понятная картина.
Первое. Переход не выглядел идеологическим. Один из разработчиков прямо написал, что Tauri ему в целом нравится и что для их случая он просто оказался не тем инструментом. Это важный нюанс: речь не о том, что Tauri «плохой», а о том, что стек не совпал с архитектурой продукта.
Второе. Tauri действительно давал Opencode понятный плюс: приложение получалось меньше по размеру. То есть главный рекламный аргумент Tauri они не отрицают.
Третье. Но дальше начинаются проблемы, которые для AI-десктопа оказались важнее размера.
Команда пишет, что в Tauri им приходилось поднимать `opencode serve` отдельным процессом. Для обычного приложения это может быть приемлемой ценой. Для продукта вроде Opencode, где поверх интерфейса живёт постоянно работающий локальный агентный сервер, это уже архитектурный налог. Ещё один процесс, ещё одна точка отказа, ещё один слой координации, ещё больше состояний, в которых что-то может пойти не так.
С Electron, по словам команды, серверный JavaScript можно держать главном процессе. И это сразу убирает часть лишней сложности. Не нужно отдельно спаунить локальный сервис только ради того, чтобы десктопное приложение могло общаться со своим же движком.
Четвёртое. Самый болезненный пункт — WebKit.
Из ответов разработчиков видно, что именно различия между WebKit и Chromium стали для них постоянным источником трения. Один из комментариев сформулирован почти без дипломатии: они не ожидали, что различия WebKit относительно Chromium окажутся настолько раздражающими. Ещё жёстче звучит реплика о том, что одного только опыта с WebKit на macOS хватило, чтобы захотеть уйти с Tauri на Electron.
Пятое. Команда отдельно упоминает конкретные UI-сценарии, которые в Chromium работают лучше. В качестве примера приводится `diffs.com`: некоторые вещи в таком интерфейсе просто нельзя реализовать настолько же хорошо на WebKit, как на Chromium.
Это уже не спор про вкусы. Это спор про предсказуемость рендеринга, поведение сложных интерфейсов, поддержку нужных браузерных возможностей и итоговое количество багов, которые пользователь видит как «приложение глючит».4
Почему для Opencode Tauri стал неудобен
Здесь начинается самая интересная часть. Если смотреть на кейс Opencode не как на войну фреймворков, а как на инженерное решение, логика миграции выглядит довольно трезво.
Opencode — это не просто оболочка вокруг статичного интерфейса. У него есть локальный агент, серверная логика, работа с рабочими директориями, стриминг состояния, диффы, ветки, ревью-панели, связка с CLI и Bun-окружением. Это не тот класс приложений, где UI живёт сам по себе, а всё остальное можно аккуратно отдать «нативному слою».
Когда у продукта уже есть существенная JavaScript/Bun-логика, Tauri перестаёт быть бесплатным выигрышем. Да, он экономит мегабайты. Но одновременно может навязывать более сложную схему взаимодействия между интерфейсом и локальным движком. Если приложение по сути уже является браузерным клиентом поверх локального сервера, дополнительный уровень orchestration быстро съедает часть выгоды.
Именно это, похоже, случилось у Opencode. Они и так должны были бандлить Bun-основанный CLI. Поэтому аргумент «в Tauri мы избегаем Node» оказался не таким сильным, как кажется со стороны. Экономия на рантайме была, но не радикальная. А вот цена в виде отдельного процесса и возни с WebKit — вполне реальная.
Иными словами: на бумаге Tauri выглядел изящнее. В живом продукте Electron оказался прямее.
Почему Electron тут мог оказаться быстрее, хотя это звучит нелогично
На первый взгляд фраза «Electron быстрее Tauri» звучит как маркетинговая провокация. В абстрактных сравнениях Tauri обычно выигрывает по размеру и нередко по старту. Но такие сравнения почти всегда касаются демо-приложений или простых интерфейсов.
В реальном продукте «быстрее» очень часто означает не FPS в вакууме, а другое:
- меньше накладных расходов на запуск и связывание внутренних процессов;
- меньше несовместимостей UI между браузерными движками;
- меньше обходных решений для конкретного webview;
- более предсказуемое поведение сложных компонентов;
- меньше состояний, в которых пользовательский интерфейс зависает, ломается или ведёт себя странно.
Если твой продукт активно опирается на веб-стек и рассчитывает на Chromium-поведение, встроенный Chromium в Electron перестаёт быть «жиром» и начинает выступать как способ купить стабильность одинаковой среды.
И это, возможно, главный скрытый тезис всей истории. Для AI-инструментов стабильность рантайма часто дороже, чем компактность дистрибутива. Пользователь охотнее простит лишние десятки или даже сотни мегабайт, чем странные баги в диффах, рендеринге, вставке кода, скролле или интерактивных панелях.
Этот кейс ломает удобный миф про десктоп-фреймворки
Из истории Opencode можно вытащить неприятный, но полезный вывод: универсального «правильного» десктоп-стека не существует.
Tauri хорошо продаётся, потому что его преимущества легко показывать на слайде. Размер приложения меньше. Архитектура выглядит аккуратнее. Есть Rust. Не нужно тащить Chromium с собой. Всё это правда.
Но у продуктов вроде Opencode другие единицы измерения. Им важны:
- одинаковое поведение интерфейса на всех машинах;
- минимальное количество межпроцессных костылей;
- удобная интеграция с уже существующим JS/Bun-стеком;
- предсказуемость для сложных веб-интерфейсов;
- скорость разработки и исправления багов в том стеке, который команда реально контролирует.
Если по этим критериям Electron выигрывает, то «но он же тяжелее» перестаёт быть убийственным аргументом. Тяжелее относительно чего? Относительно красивой теории? Возможно. Относительно рабочего пользовательского опыта? Уже не факт.
Что это значит для рынка AI-десктопов
Случай Opencode важен не только для самого Opencode. Он подсвечивает более широкую проблему почти всех AI-приложений на десктопе.
Такие продукты одновременно хотят быть:
- локальными;
- быстрыми;
- насыщенными по UI;
- тесно связанными с CLI и файловой системой;
- кроссплатформенными;
- управляемыми одной сравнительно небольшой командой.
И именно здесь многие начинают понимать, что «нативнее» не всегда значит «проще». Иногда более грубый на вид стек оказывается более управляемым. Если вся критическая логика уже живёт в JavaScript-мире, а пользовательский опыт зависит от тонкостей браузерного поведения, Electron даёт не только бандл, но и среду, которую команда реально контролирует целиком.
Это не означает, что рынок дружно побежит обратно в Electron. Но это означает другое: эпоха лозунга «любой новый десктопный продукт должен идти в Tauri» заканчивается. У серьёзных AI-инструментов слишком много нетипичных требований, чтобы выбирать платформу по идеологическим маркерам.
Главный вывод
В истории Opencode самое интересное не то, что они выбрали Electron. Самое интересное, что они публично признали: для их продукта важнее надёжность и целостность архитектуры, чем символическая победа в войне за размер приложения.
Это взрослая инженерная позиция. Не «какой стек сейчас моднее», а «в каком стеке у нас меньше случайной сложности».
Для пользователей это тоже полезный урок. Если вы строите AI-десктоп, смотреть нужно не только на мегабайты и бенчмарки из презентаций. Нужно смотреть на то, сколько процессов вы обязаны координировать, насколько предсказуем ваш webview, где именно живёт локальный движок, и сколько багов появляется просто потому, что у вас слишком много слоёв.
Opencode, похоже, ответил на этот вопрос довольно жёстко. И их ответ звучит так: в нашем случае Electron оказался не шагом назад, а способом убрать лишнюю сложность.
Если вы делали десктопные AI-инструменты, где для вас проходит граница между «лёгким» стеком и «контролируемым» стеком? Вы бы в таком кейсе терпели ограничения Tauri ради меньшего бандла или тоже выбрали бы Electron ради более предсказуемой среды?