Проведите достаточно времени на Hacker News или Reddit, и рано или поздно вы увидите одни и те же претензии: Electron раздут, Electron потребляет слишком много памяти, а серьёзные настольные приложения должны быть нативными.
В этой критике есть доля правды. Приложения на Electron обычно потребляют больше ресурсов уже на старте, поскольку поставляются вместе с Chromium и Node.js. Тщательно спроектированное нативное приложение может использовать меньше памяти, быстрее запускаться и глубже интегрироваться с операционной системой.
Но в этом споре слишком много внимания уделяют компьютеру и слишком мало — компании, которая создаёт программное обеспечение.
Для большинства пользователей технологии, на которых построено приложение, почти не имеют значения. Им важно, работает ли оно, быстро ли реагирует на действия, исправляются ли ошибки и появляются ли полезные функции. Поэтому для компании-разработчика одно из важнейших свойств технологического стека — то, что редко встречается в таблицах сравнительных тестов: насколько быстро команда может создавать и выпускать продукт, учиться на обратной связи и улучшать его?
Для многих современных настольных приложений Electron исключительно хорошо решает эту задачу.
Дефицитный ресурс — время разработчиков
В идеализированной компании, создающей нативные настольные приложения, есть отличная команда для macOS, ещё одна команда для Windows и, возможно, ещё одна — для поддержки Linux. Каждое приложение тщательно оптимизировано под свою платформу, а каждый разработчик глубоко понимает операционную систему, с которой работает.
Большинство компаний не могут позволить себе такую роскошь.
Над настольным продуктом могут работать пять разработчиков. А могут — двое. Эти же люди должны создавать новые функции, исправлять ошибки, повышать производительность, отвечать клиентам, поддерживать инфраструктуру, учитывать изменения операционных систем и обеспечивать дальнейшее развитие продукта.
Нативная разработка усложняет эту задачу, потому что macOS, Windows и Linux — действительно разные платформы. У них разные UI-фреймворки, API, системы разрешений, особенности жизненного цикла приложений, установщики, механизмы обновления, системы уведомлений, управление окнами, API специальных возможностей и множество платформенных особенностей, накопившихся за годы.
Electron меняет расклад. Он объединяет Chromium, Node.js и API настольных систем в общую модель приложения для macOS, Windows и Linux. Один и тот же TypeScript-разработчик часто может реализовать функцию целиком — от интерфейса до логики приложения — и выпустить её на всех настольных платформах. Нативный код остаётся доступным там, где он действительно нужен, но становится исключением, а не основой продукта. Сам проект Electron называет это одним из своих главных преимуществ: единая кодовая база на JavaScript для всех трёх основных настольных платформ.
С годами эффект этой разницы накапливается. Если каждая значимая функция требует отдельных реализаций для Mac и Windows, компания снова и снова платит этот платформенный налог: за каждую функцию, переработку дизайна, эксперимент, исправление ошибки, улучшение доступности и оптимизацию производительности.
С Electron значительную часть этой работы достаточно выполнить один раз.
Electron оптимизирует скорость итераций
Продукты редко становятся отличными потому, что первая реализация была идеальной. Они становятся отличными благодаря последовательным итерациям.
Команда что-то выпускает. Клиенты этим пользуются. Команда делает выводы. Меняет функцию. Ею начинает пользоваться больше людей. Обнаруживается ещё одна проблема. Команда снова вносит улучшения.
Чем короче цикл между идеей, реализацией, обратной связью и улучшением, тем быстрее продукт становится лучше.
Electron особенно хорошо сокращает этот цикл, потому что построен вокруг технологий, которые компании-разработчики уже повсеместно используют: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js и npm.
Это означает, что компании могут совместно использовать гораздо больше, чем исходный код. Между веб-продуктами и настольными приложениями можно распределять разработчиков и переиспользовать компоненты интерфейса, инструменты, библиотеки, инфраструктуру, подходы к тестированию и накопленные в компании знания.
Фронтенд-разработчик не становится внезапно бесполезным, когда компании нужна помощь с клиентом для Windows. Разработчик настольного приложения может вносить вклад в веб-приложение. Фулстек-разработчик на TypeScript может переходить между продуктами по мере изменения приоритетов.
Для небольшой или средней компании такая гибкость может стоить намного больше, чем экономия 100 МБ оперативной памяти.
Посмотрите, кто на самом деле использует Electron
Electron иногда описывают как способ срезать углы для компаний, не желающих вкладываться в «настоящее» настольное приложение. Продукты, построенные на нём, делают эту позицию всё менее убедительной.
Сам проект Electron приводит в пример такие продукты, как Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom и Canva. Это не простые утилиты. Многие из них входят в число самых сложных и широко используемых приложений для продуктивной работы в мире.
Visual Studio Code — особенно показательный пример. Microsoft могла бы создать свой флагманский редактор кода практически на любой технологии для Windows, но VS Code использует Electron на Windows, macOS и Linux. В нём есть терминалы, отладка, языковые серверы, интеграция с Git, удалённая разработка, блокноты, расширения и глубоко настраиваемые редакторы.
Интересный вопрос не в том, могла ли Microsoft сэкономить память, создав три отдельные нативные версии. Конечно, могла.
Гораздо важнее другой вопрос: развивался бы VS Code так же быстро, оставался бы настолько единообразным на разных платформах и обзавёлся бы столь большой экосистемой, если бы каждая крупная возможность требовала нескольких отдельных реализаций?
ChatGPT и Claude показывают разницу в подходах
Сравнение ChatGPT и Claude тоже поучительно.
Изначально OpenAI создала для ChatGPT отдельное нативное приложение для macOS. Anthropic, напротив, построила Claude Desktop на Electron и с самого начала имела общую основу настольного приложения для разных платформ.
По мере развития продуктов эта разница становилась всё важнее. Claude Desktop мог продолжать добавлять такие возможности, как интеграции MCP, расширения и Claude Code, в то же самое кроссплатформенное приложение. Теперь Anthropic поддерживает Claude Code прямо в настольном приложении, включая несколько локальных и удалённых сессий.
Позже OpenAI тоже стала ориентироваться на Electron в своём новом кроссплатформенном направлении настольных приложений, и теперь Electron включает и ChatGPT, и Claude в список известных приложений на своей платформе.
Было бы преувеличением утверждать, что только Electron объясняет разницу в темпах развития продуктов. Размер команды, приоритеты, продуктовая стратегия и внутренняя организация тоже имеют значение. Но архитектурное преимущество очевидно: общая кроссплатформенная основа упрощает выпуск функций для разных операционных систем без необходимости поддерживать отдельные реализации.
Именно такое преимущество становится всё ценнее по мере роста настольного продукта.
Evernote узнала цену поддержки отдельных клиентов
Evernote — один из самых наглядных исторических примеров этой проблемы.
Годами Evernote поддерживала разные приложения для Mac, Windows, мобильных устройств и веба. Со временем в этих продуктах накопились различия в поведении и отрисовке, устаревшие архитектурные допущения и проблемы с синхронизацией.
В 2020 году Evernote пересоздала приложения для Windows и Mac на общей кодовой базе. Компания заявила, что новая основа сделает приложения стабильнее, позволит быстрее исправлять ошибки, чаще выпускать функции и улучшит синхронизацию между платформами.
Этот переход не был безболезненным, и некоторым давним пользователям не понравилась первоначальная потеря платформенных функций. Но причины, по которым Evernote решилась на столь дорогостоящую переработку, интереснее самих проблем перехода.
Когда в продукте появляются развитый редактор, локальное хранилище для работы без интернета, поиск, вложения, совместная работа, задачи, календари и сложная синхронизация, поддержка нескольких независимых реализаций становится всё дороже. Ошибки проявляются по-разному. Отрисовка отличается. Логика синхронизации взаимодействует с разными локальными архитектурами. Каждое значимое изменение продукта приходится переносить в несколько клиентов.
Общая архитектура не устраняет сложные проблемы. Она позволяет компании решать больше таких проблем один раз.
Linux, возможно, самое недооценённое преимущество Electron
Linux делает аргументы в пользу Electron ещё весомее.
Полноценно поддерживать Linux сложно. В отличие от macOS или Windows, «настольный Linux» — не единая платформа с жёстким централизованным контролем. Разработчикам приходится учитывать разные дистрибутивы, форматы пакетов, окружения рабочего стола, графические стеки, системные библиотеки и протоколы отображения.
Для многих компаний-разработчиков рациональным бизнес-решением было бы просто не поддерживать Linux.
Electron меняет экономику этого решения.
Поскольку Electron предоставляет общую среду выполнения для macOS, Windows и Linux, добавить поддержку Linux может быть значительно проще, чем поддерживать отдельную нативную реализацию для него. Это одна из причин, по которым пользователи Linux сегодня имеют доступ ко многим крупным настольным приложениям, которые раньше, вероятно, никогда не получили бы официального клиента для Linux.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian и многие другие инструменты могут поддерживать Linux без необходимости сопровождать совершенно отдельное приложение на GTK или Qt.
Electron также берёт на себя значительную часть специфической для Linux сложности, избавляя от неё разработчиков приложений. Хороший пример — переход с X11 на Wayland. Разработчики Electron рассказывали, как переход Chromium на Wayland фактически перевёл вместе с ним и приложения на Electron, сократив объём работы с графическим стеком, которую каждой команде пришлось бы выполнять самостоятельно.
Без фреймворков вроде Electron многие компании не стали бы создавать нативные клиенты для Linux. Они просто поддерживали бы macOS и Windows, оставив пользователям Linux вкладку в браузере.
Вероятно, Electron сделал для коммерческого настольного ПО под Linux больше, чем принято признавать.
Даже Microsoft всё чаще выбирает веб-технологии
Microsoft — пожалуй, самый убедительный контрпример к идее о том, что серьёзное ПО для Windows всегда должно использовать нативные UI-фреймворки Windows.
Microsoft контролирует Windows. Она контролирует Win32, .NET, WinUI, WebView2 и значительную часть платформы, на которой работают разработчики. Если бы полностью нативная разработка для Windows всегда была очевидным выбором, у Microsoft были бы наилучшие возможности использовать её повсюду.
Но она этого не делает.
Visual Studio Code использует Electron. Teams по-прежнему построен вокруг React, TypeScript и Chromium даже после того, как Microsoft заменила Electron более оптимизированной оболочкой на WebView2. Новый Outlook для Windows тоже во многом опирается на веб-технологии, и Microsoft прямо описывает такую архитектуру как способ повысить гибкость разработки, ускорить выпуск функций и обеспечить более единообразный пользовательский опыт.
Teams особенно показателен. Microsoft хотела повысить производительность и снизить потребление ресурсов, поэтому изменила архитектуру. Но она не стала переписывать интерфейс в виде традиционного нативного приложения для Windows.
Она сохранила веб-стек и оптимизировала всё вокруг него.
Это важное различие. Microsoft решила, что организационные преимущества React, TypeScript и Chromium стоит сохранить, даже активно повышая производительность.
Здесь есть и другой урок. За прошедшие годы сама Microsoft представила множество поколений технологий для приложений Windows: Win32, WPF, UWP, WinUI и другие. Компания, выбирающая «нативную разработку для Windows», не обязательно выбирает платформу на все времена. Часто она делает ставку на одно из поколений фреймворков, которым Microsoft в данный момент отдаёт предпочтение.
Веб-платформа, как ни иронично, стала одной из наиболее стабильных платформ для разработки приложений.
Найм — часть архитектуры
Выбор фреймворка также определяет, кого вы сможете нанять.
Разработчики JavaScript и TypeScript составляют один из крупнейших кадровых резервов в отрасли. Компания, создающая продукт на Electron, может нанимать специалистов из этого пула вместо того, чтобы собирать отдельные команды опытных специалистов по macOS, Windows и Linux.
Специалисты по нативной разработке по-прежнему ценны. Серьёзным настольным продуктам всё ещё нужны разработчики, глубоко понимающие операционные системы. Но Electron меняет то, сколько таких специалистов вам требуется.
Вместо того чтобы поручать платформенным экспертам создание большей части приложения, можно оставить относительно небольшой объём кода нативной интеграции, а основную часть команды направить на работу над общим продуктом.
Это особенно важно, если у компании уже есть веб-приложение. Компоненты React иногда можно использовать совместно. Библиотеки TypeScript можно переиспользовать. Логику продукта можно переносить между вебом и настольным приложением. Разработчики могут переходить из команды в команду без необходимости осваивать совершенно другую экосистему.
Снижается и зависимость от отдельных сотрудников. Если уходит единственный разработчик, глубоко понимающий ваш нативный клиент для Windows, найти замену его знаниям может быть сложно. С Electron гораздо большая часть кодовой базы использует технологии, знакомые остальным сотрудникам компании.
Таким образом, фреймворк определяет не только то, как отрисовывается интерфейс. Он влияет и на то, как можно организовать само подразделение разработки.
Нативное приложение не обязательно лучше
Разработчики часто используют слово «нативный» почти как синоним слова «быстрый».
Но это не одно и то же.
Нативные API дают разработчикам возможность создать очень эффективное приложение. Достигнет ли конечный продукт такой эффективности на практике, зависит от архитектуры, команды, бюджета и объёма работ по оптимизации, который компания может себе позволить.
Нативное приложение тоже может быть медленным, нестабильным, прожорливым по памяти, непоследовательным или плохо поддерживаемым.
Что ещё важнее, разделение небольшой команды между несколькими нативными реализациями означает, что каждой реализации достаётся меньше рабочего времени разработчиков.
Представьте, что у компании есть шесть разработчиков для настольного продукта. Один вариант — разделить их между Mac и Windows, возможно, оставив Linux без поддержки. Другой — направить почти всех шестерых на одно общее приложение Electron для всех трёх платформ.
Какой подход даёт компании больше ресурсов разработки, чтобы ускорять запуск, устранять утечки памяти, доводить до совершенства взаимодействие с интерфейсом, улучшать доступность, уменьшать число сбоев и реагировать на запросы пользователей?
Совсем не очевидно, что нативные приложения в итоге окажутся лучшим продуктом.
Возникает интересный парадокс: фреймворк, который потребляет несколько больше машинных ресурсов, может позволить компании создать лучше оптимизированный продукт, потому что требует гораздо меньше ресурсов разработки.
Electron даёт вам контролируемую платформу
У Electron есть ещё одно преимущество, которое легко упустить из виду: он поставляется с той средой выполнения Chromium, под которую приложение создавали и тестировали.
Это устраняет важный переменный фактор из кроссплатформенной разработки.
Фреймворки на основе системных WebView позволяют создавать приложения меньшего размера, но компромисс заключается в том, что один и тот же фронтенд может работать на WebView2 в Windows, WKWebView в macOS и WebKitGTK в Linux. У этих движков разные возможности, ошибки, графики выпуска версий и поведение при отрисовке.
Electron предлагает другой компромисс: включить среду выполнения в поставку и сделать её частью приложения.
Да, это требует места на диске.
Но зато разработчики получают гораздо более единообразную целевую среду в трёх очень разных операционных системах.
Для разработки такая предсказуемость имеет огромную ценность.
Когда Electron недостаточно, нативный код по-прежнему доступен
Выбор Electron не означает отказа от доступа к нативным возможностям.
Приложения Electron могут использовать нативные модули и платформенный код там, где это необходимо. Это означает, что архитектурный выбор на самом деле не сводится к следующему:
100% нативного кода или 100% JavaScript.
Для многих продуктов лучше подходит другая модель:
большая часть приложения общая, а небольшой объём нативного кода используется там, где операционная система действительно этого требует.
Нативный код становится запасным выходом, а не основой всего продукта.
Для многих компаний это гораздо более рациональное распределение усилий разработчиков.
Пользователям важны продукты, а не фреймворки
Есть небольшая группа технически подкованных пользователей, которые открывают «Мониторинг системы», замечают несколько процессов Chromium и сразу начинают жаловаться, что приложение использует Electron.
Большинство пользователей этого не делают.
Им не важно, что Slack использует Electron. Им не важно, что VS Code построен на веб-технологиях. Они не знают, какой фреймворк использует Claude. Им важно, помогает ли программа справляться с их работой.
Если приложение запускается достаточно быстро, оперативно реагирует на действия, редко вылетает и решает задачу пользователя, технология реализации по большей части остаётся незаметной.
Обратное тоже верно. Нативное приложение не становится автоматически хорошим продуктом только потому, что использует Swift или WinUI.
Программные продукты конкурируют на уровне продукта, а не на уровне фреймворка.
Оптимизируйте компанию, а не только исполняемый файл
У Electron есть реальные издержки. Он занимает больше места на диске. Его базовое потребление памяти обычно выше, чем у небольшого нативного приложения. Безусловно, существуют продукты, для которых эти издержки делают Electron неправильным выбором.
Небольшой утилите в строке меню, скорее всего, не нужен Chromium. Драйверу устройства — точно не нужен. У игр, профессионального аудиософтa и приложений, крайне чувствительных к задержкам, другие требования. А если ваш продукт всегда будет работать только на одной операционной системе, оправдать нативную разработку становится гораздо проще.
Но огромная доля современного настольного ПО не относится к этим категориям.
Это сложные интерфейсы, подключённые к облачным сервисам. Им нужно работать в Windows и macOS, и пользователи всё чаще ожидают также поддержки Linux. Им нужно постоянно развиваться. Они конкурируют с продуктами, в которых изменения выходят каждую неделю. И обычно их создаёт компания с ограниченным числом разработчиков.
Для таких продуктов продуктивность разработчиков — часть производительности приложения.
Electron позволяет компании нанимать сотрудников из гораздо более широкого кадрового пула, распределять разработчиков между вебом и настольными приложениями, поддерживать одно основное приложение вместо нескольких, переиспользовать экосистему JavaScript, более согласованно выпускать функции для разных операционных систем, поддерживать Linux с затратами, которые иначе часто было бы трудно оправдать, и тратить больше времени разработчиков на улучшение продукта, а не на сопровождение параллельных реализаций.
Издержки Electron легко измерить в мегабайтах.
Издержки альтернативы заметить сложнее. Они проявляются в дополнительных разработчиках, дублирующих реализациях, более долгих циклах выпуска, платформенных ошибках, трудностях найма, изолированных друг от друга подразделениях, отсутствии поддержки пользователей Linux и функциях, которые доходят до всех на несколько месяцев позже.
Эти издержки не видны в «Мониторинге системы».
Но для компании, создающей программное обеспечение, они могут быть значительно выше.
Цель разработки ПО — не создать самый маленький исполняемый файл.
Она в том, чтобы создать лучший продукт, который ваша организация способна выпускать, поддерживать и непрерывно улучшать.
Для удивительно широкого класса настольных приложений Electron остаётся одним из самых эффективных способов добиться именно этого.