Ако прекарате достатъчно време в 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. Инженерът, който разработва настолни приложения, може да допринася за уеб приложението. Full-stack TypeScript инженерът може да преминава между продуктите според променящите се приоритети.
За малка или средна компания тази гъвкавост може да струва много повече от спестяването на 100 MB RAM.
Вижте кой всъщност използва 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 да имат достъп до много водещи настолни приложения, които в миналото може би никога не биха получили официален клиент за 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.
За много продукти по-добрият модел е:
по-голямата част от приложението е обща, с малко количество нативен код там, където операционната система наистина го изисква.
Нативният код се превръща в резервен изход, а не в основа на целия продукт.
За много компании това е много по-добро разпределение на инженерните усилия.
Потребителите се интересуват от продуктите, не от рамките
Има малка група технически подготвени потребители, които отварят Activity Monitor, забелязват няколко процеса на Chromium и веднага се оплакват, че приложението използва Electron.
Повечето потребители не го правят.
Не ги интересува, че Slack използва Electron. Не ги интересува, че VS Code е изграден с уеб технологии. Не знаят каква рамка използва Claude. Интересува ги дали софтуерът им помага да си свършат работата.
Ако едно приложение се стартира достатъчно бързо, реагира бързо, рядко се срива и решава проблема на потребителя, технологията на реализацията до голяма степен остава невидима.
Обратното е също толкова вярно. Едно нативно приложение не се превръща автоматично в добър продукт, защото използва Swift или WinUI.
Софтуерът се конкурира на ниво продукт, а не на ниво рамка.
Оптимизирайте компанията, не само изпълнимия файл
Electron има реална цена. Той използва повече дисково пространство. Базовото му потребление на памет обикновено е по-високо от това на малко нативно приложение. Определено има продукти, при които тези недостатъци правят Electron неподходящ избор.
Една дребна помощна програма в лентата с менюта вероятно не се нуждае от Chromium. Драйверът за устройство със сигурност не се нуждае. Игрите, професионалният аудиософтуер и приложенията, изключително чувствителни към латентността, имат различни изисквания. А ако продуктът ви винаги ще работи само на една операционна система, нативната разработка става много по-лесна за обосноваване.
Но огромен процент от съвременния настолен софтуер не попада в тези категории.
Той се състои от сложни интерфейси, свързани с облачни услуги. Трябва да работи на Windows и macOS, а потребителите все по-често очакват и поддръжка за Linux. Трябва да се развива непрекъснато. Конкурира се с продукти, които пускат промени всяка седмица. И обикновено се създава от компания с ограничен брой инженери.
За тези продукти продуктивността на разработчиците е част от производителността на приложението.
Electron позволява на една компания да наема от много по-голям кръг таланти, да споделя инженери между уеб и настолната разработка, да поддържа едно основно приложение вместо няколко, да използва повторно JavaScript екосистемата, да предоставя функции по-последователно за различните операционни системи, да поддържа Linux на цена, която иначе често би била трудна за оправдаване, и да отделя повече инженерно време за подобряване на продукта, вместо за поддържане на паралелни реализации.
Лесно можете да измерите цената на Electron в мегабайти.
Разходите при алтернативата са по-трудни за забелязване. Те се проявяват като допълнителни инженери, дублирани реализации, по-дълги цикли на издаване на версии, специфични за платформите грешки, трудности при наемането, изолирани организационни звена, потребители на Linux без поддръжка и функции, на които им трябват още месеци, за да достигнат до всички.
Тези разходи не се виждат в Activity Monitor.
Но за компанията, която създава софтуера, те може да са значително по-големи.
Целта на софтуерната разработка не е да създаде най-малкия изпълним файл.
Тя е да създаде най-добрия продукт, който организацията ви може да пуска, поддържа и непрекъснато да подобрява.
За изненадващо широк клас настолни приложения Electron остава един от най-ефективните начини да се постигне точно това.