Проведіть достатньо часу на Hacker News чи Reddit, і рано чи пізно ви побачите ту саму критику: Electron роздутий, Electron використовує забагато пам’яті, а серйозні настільні застосунки мають бути нативними.
У цій критиці є частка правди. Застосунки на Electron зазвичай потребують більше ресурсів уже на базовому рівні, оскільки постачаються разом із Chromium і Node.js. Ретельно спроєктований нативний застосунок може використовувати менше пам’яті, швидше запускатися й глибше інтегруватися з операційною системою.
Але ця дискусія надто зосереджена на комп’ютері й недостатньо — на компанії, яка створює програмне забезпечення.
Для більшості користувачів технологія, що стоїть за застосунком, майже не має значення. Їх цікавить, чи він працює, чи швидко реагує, чи виправляють у ньому помилки та чи з’являються нові корисні функції. Тому для компанії, що розробляє програмне забезпечення, однією з найважливіших властивостей технологічного стеку є те, що рідко потрапляє до таблиць порівняльних тестів: як швидко команда може створювати, випускати, засвоювати досвід і вдосконалювати продукт?
Для багатьох сучасних настільних застосунків Electron винятково добре допомагає із цим.
Дефіцитний ресурс — час інженерів
В ідеалізованій компанії, що створює нативні настільні застосунки, є чудова команда для macOS, окрема команда, яка розробляє застосунок для Windows, і, можливо, ще одна команда для підтримки Linux. Кожен застосунок ретельно оптимізований для своєї платформи, а кожен інженер глибоко розуміє операційну систему, з якою працює.
Більшість компаній не можуть дозволити собі такої розкоші.
Над настільним продуктом можуть працювати п’ятеро інженерів. А можуть і двоє. Ці самі інженери мають створювати нові функції, виправляти помилки, підвищувати продуктивність, відповідати клієнтам, підтримувати інфраструктуру, враховувати зміни в операційних системах і забезпечувати подальший розвиток продукту.
Нативна розробка ускладнює це, оскільки macOS, Windows і Linux — справді різні платформи. У них різні фреймворки інтерфейсу, 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.
Було б перебільшенням стверджувати, що лише 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 сьогодні мають доступ до багатьох великих настільних застосунків, які за інших обставин могли б узагалі не отримати офіційного клієнта для 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 завжди має використовувати нативні фреймворки інтерфейсу 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, для якого застосунок розробляли й тестували.
Це усуває важливу змінну з кросплатформної розробки.
Фреймворки, що спираються на вбудовані вебпереглядачі операційної системи, можуть давати менші за розміром застосунки, але компроміс полягає в тому, що той самий фронтенд може працювати на 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. Драйверу пристрою — точно не потрібен. Ігри, професійне аудіопрограмне забезпечення та застосунки, надзвичайно чутливі до затримок, мають інші вимоги. А якщо ваш продукт завжди працюватиме лише в одній операційній системі, нативну розробку стає набагато легше виправдати.
Але величезна частка сучасного настільного програмного забезпечення не належить до цих категорій.
Це складні інтерфейси, під’єднані до хмарних сервісів. Вони мають працювати у Windows і macOS, а дедалі частіше користувачі очікують і підтримки Linux. Вони мають постійно розвиватися. Вони конкурують із продуктами, які випускають зміни щотижня. І зазвичай їх створює компанія з обмеженою кількістю інженерів.
Для таких продуктів продуктивність розробників — частина продуктивності застосунку.
Electron дає компанії змогу наймати з набагато більшого резерву фахівців, залучати тих самих інженерів до вебу й настільних застосунків, підтримувати один основний застосунок замість кількох, повторно використовувати екосистему JavaScript, більш узгоджено випускати функції для різних операційних систем, підтримувати Linux за ціною, яку інакше часто було б важко виправдати, і витрачати більше інженерного часу на вдосконалення продукту, а не на підтримку паралельних реалізацій.
Витрати Electron легко виміряти в мегабайтах.
Витрати альтернативи побачити важче. Вони проявляються у вигляді додаткових інженерів, дубльованих реалізацій, довших циклів випуску, платформних помилок, труднощів із наймом, ізольованих команд, відсутності підтримки користувачів Linux і функцій, які доходять до всіх на кілька місяців пізніше.
Ці витрати не відображаються в «Моніторі активності».
Але для компанії, яка створює програмне забезпечення, вони можуть бути значно більшими.
Мета розробки програмного забезпечення — не створити найменший бінарний файл.
Вона полягає в тому, щоб створити найкращий продукт, який ваша організація може випускати, підтримувати й безперервно вдосконалювати.
Для напрочуд великого класу настільних застосунків Electron залишається одним із найефективніших способів зробити саме це.