Stačí strávit dost času na Hacker News nebo Redditu a dříve či později narazíte na stejnou kritiku: Electron je nabobtnalý, Electron spotřebovává příliš mnoho paměti a seriózní desktopové aplikace by měly být nativní.
Na této kritice je něco pravdy. Aplikace postavené na Electronu mají obecně vyšší základní nároky na prostředky, protože s sebou dodávají Chromium a Node.js. Pečlivě navržená nativní aplikace může spotřebovávat méně paměti, spouštět se rychleji a být těsněji propojena s operačním systémem.
Tato debata se ale příliš soustředí na počítač a málo na firmu, která software vytváří.
Pro většinu uživatelů technologie stojící za aplikací téměř nehraje roli. Zajímá je, jestli aplikace funguje, jestli reaguje svižně, jestli se opravují chyby a jestli přibývají užitečné funkce. Pro softwarovou firmu je proto jednou z nejdůležitějších vlastností technologického stacku něco, co se v tabulkách s výkonnostními testy objevuje jen zřídka: jak rychle dokáže tým produkt vyvíjet, vydávat, získávat poznatky a zlepšovat?
U mnoha moderních desktopových aplikací je v tom Electron mimořádně dobrý.
Vzácným zdrojem je čas vývojářů
V idealizované firmě vyvíjející nativní desktopový software pracuje vynikající tým pro macOS, další tým vytváří aplikaci pro Windows a možná ještě další zajišťuje podporu Linuxu. Každá aplikace je pečlivě optimalizovaná pro svou platformu a každý vývojář do hloubky rozumí operačnímu systému, na kterém pracuje.
Většina firem si takový luxus nemůže dovolit.
Na desktopovém produktu může pracovat pět vývojářů. Mohou to být i dva. Titíž vývojáři musí vytvářet funkce, opravovat chyby, zlepšovat výkon, reagovat na zákazníky, udržovat infrastrukturu, vypořádávat se se změnami operačních systémů a posouvat produkt dál.
Nativní vývoj to ztěžuje, protože macOS, Windows a Linux jsou skutečně odlišné platformy. Mají různé frameworky pro uživatelské rozhraní, API, systémy oprávnění, chování v průběhu životního cyklu aplikace, instalační programy, mechanismy aktualizací, systémy oznámení, správu oken, API pro přístupnost a léta nahromaděných specifických zvláštností.
Electron tuto rovnici mění. Spojuje Chromium, Node.js a desktopová API do společného aplikačního modelu pro macOS, Windows a Linux. Tentýž vývojář pracující s TypeScriptem často dokáže vytvořit funkci od uživatelského rozhraní až po aplikační logiku a vydat ji na všech desktopových platformách. Nativní kód zůstává k dispozici tam, kde je skutečně potřeba, ale stává se výjimkou, nikoli základem produktu. Sám Electron to popisuje jako jednu ze svých hlavních výhod: jednu kódovou základnu v JavaScriptu pro všechny tři hlavní desktopové platformy.
Tento rozdíl se v průběhu let kumuluje. Pokud každá významná funkce vyžaduje samostatnou implementaci pro Mac a Windows, firma tuto „daň za platformy“ platí opakovaně: za každou funkci, změnu designu, experiment, opravu chyby, zlepšení přístupnosti i optimalizaci výkonu.
S Electronem se velká část této práce udělá jen jednou.
Electron optimalizuje rychlost iterací
Produkty se málokdy stanou skvělými proto, že jejich první implementace byla dokonalá. Skvělými se stávají díky opakovanému vylepšování.
Tým něco vydá. Zákazníci to používají. Tým získá nové poznatky. Upraví funkci. Začne ji používat více lidí. Objeví se další problém. Tým ji znovu vylepší.
Čím kratší je cyklus mezi nápadem, implementací, zpětnou vazbou a vylepšením, tím rychleji se produkt zlepšuje.
Electron tento cyklus zkracuje mimořádně dobře, protože stojí na technologiích, které softwarové firmy už používají všude: JavaScriptu, TypeScriptu, HTML, CSS, Reactu, Chromiu, Node.js a npm.
To znamená, že firmy mohou sdílet mnohem víc než jen zdrojový kód. Mezi svými webovými a desktopovými produkty mohou sdílet vývojáře, komponenty uživatelského rozhraní, nástroje, knihovny, infrastrukturu, přístupy k testování i znalosti nashromážděné v organizaci.
Frontendový vývojář nepřestane být užitečný jen proto, že firma potřebuje pomoc s klientem pro Windows. Desktopový vývojář může přispívat do webové aplikace. Fullstackový vývojář pracující s TypeScriptem může přecházet mezi produkty podle toho, jak se mění priority.
Pro malou nebo středně velkou firmu může mít tato flexibilita mnohem větší hodnotu než úspora 100 MB RAM.
Podívejte se, kdo Electron skutečně používá
Electron bývá někdy popisován jako zkratka pro firmy, které nechtějí investovat do „pořádné“ desktopové aplikace. Produkty na něm postavené však činí tento argument čím dál obtížněji obhajitelným.
Samotný projekt Electron uvádí jako příklady produkty Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom a Canva. Nejde o jednoduché pomocné nástroje. Mnohé z nich patří mezi nejpropracovanější a nejpoužívanější aplikace pro produktivitu na světě.
Obzvlášť výmluvným příkladem je Visual Studio Code. Microsoft by mohl svůj vlajkový editor kódu postavit prakticky na libovolné technologii pro Windows, kterou by si vybral, a přesto VS Code používá Electron na Windows, macOS i Linuxu. Nabízí terminály, ladění, jazykové servery, integraci Gitu, vzdálený vývoj, notebooky, rozšíření a vysoce přizpůsobené editory.
Zajímavou otázkou není, zda by Microsoft mohl ušetřit paměť vytvořením tří samostatných nativních verzí. Samozřejmě mohl.
Lepší otázkou je, zda by se VS Code vyvíjel stejně rychle, zůstal stejně konzistentní napříč platformami a vybudoval si tak rozsáhlý ekosystém, kdyby každá zásadní funkce vyžadovala několik samostatných implementací.
ChatGPT a Claude ukazují rozdíl v přístupu
Poučné je také srovnání ChatGPT a Claude.
OpenAI pro ChatGPT zpočátku vytvořila samostatnou nativní aplikaci pro macOS. Anthropic naproti tomu postavil Claude Desktop na Electronu a od začátku měl společný desktopový základ napříč platformami.
Tento rozdíl nabýval na významu s tím, jak se produkty rozšiřovaly. Claude Desktop mohl do téže multiplatformní aplikace průběžně přidávat možnosti, jako jsou integrace MCP, rozšíření a Claude Code. Anthropic nyní podporuje Claude Code přímo ve svém desktopovém prostředí, včetně více místních i vzdálených relací.
OpenAI později také nasměrovala svůj novější multiplatformní desktopový vývoj k Electronu a Electron nyní uvádí ChatGPT i Claude mezi významnými aplikacemi, které jej používají.
Bylo by přehnané tvrdit, že rozdíl v tempu vývoje produktů vysvětluje samotný Electron. Důležitá je i velikost týmu, priority, produktová strategie a vnitřní organizace. Architektonická výhoda je ale jasná: společný multiplatformní základ usnadňuje vydávání funkcí napříč operačními systémy, aniž by bylo nutné udržovat samostatné implementace.
Právě tento druh výhody je s růstem desktopového produktu stále cennější.
Evernote poznalo náklady na údržbu samostatných klientů
Evernote je jedním z nejvýraznějších historických příkladů tohoto problému.
Po léta Evernote udržovalo různé aplikace pro Mac, Windows, mobilní zařízení a web. Časem se v těchto produktech nahromadily rozdíly v chování, vykreslování, zastaralé předpoklady a problémy se synchronizací.
V roce 2020 Evernote přestavělo své aplikace pro Windows a Mac na společné kódové základně. Firma uvedla, že nový základ zajistí stabilnější aplikace, umožní rychlejší opravy chyb, častější vydávání funkcí a lepší synchronizaci napříč platformami.
Tento přechod nebyl bezbolestný a některým dlouholetým uživatelům vadila počáteční ztráta funkcí specifických pro jednotlivé platformy. Důvod, proč se Evernote pustilo do tak nákladného přepsání, je však zajímavější než samotné problémy při přechodu.
Jakmile produkt obsahuje pokročilý editor, offline úložiště, vyhledávání, přílohy, spolupráci, úkoly, kalendáře a složitou synchronizaci, údržba několika nezávislých implementací je stále dražší. Chyby se projevují jinak. Vykreslování se liší. Synchronizační logika se potkává s odlišnými lokálními architekturami. Každá významná změna produktu se musí promítnout do několika klientů.
Společná architektura neodstraní obtížné problémy. Umožní firmě vyřešit více z nich jen jednou.
Linux je možná nejvíce podceňovanou výhodou Electronu
Linux argumenty ve prospěch Electronu ještě posiluje.
Zajistit kvalitní podporu Linuxu je obtížné. Na rozdíl od macOS nebo Windows není „linuxový desktop“ jednou přísně kontrolovanou platformou. Vývojáři se musí vypořádávat s různými distribucemi, formáty balíčků, desktopovými prostředími, grafickými stacky, systémovými knihovnami a zobrazovacími protokoly.
Pro mnoho softwarových firem by racionálním obchodním rozhodnutím bylo Linux jednoduše nepodporovat.
Electron mění ekonomiku takového rozhodnutí.
Protože Electron poskytuje společné běhové prostředí pro macOS, Windows a Linux, může být přidání podpory Linuxu výrazně snazší než údržba samostatné nativní implementace pro Linux. To je jeden z důvodů, proč mají dnes uživatelé Linuxu přístup k mnoha významným desktopovým aplikacím, které by se v minulosti možná nikdy nedočkaly oficiálního linuxového klienta.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian a řada dalších nástrojů mohou podporovat Linux, aniž by musely udržovat zcela samostatnou aplikaci v GTK nebo Qt.
Electron také za vývojáře aplikací řeší velkou část složitostí specifických pro Linux. Dobrým příkladem je přechod z X11 na Wayland. Správci Electronu popsali, jak přechod Chromia na Wayland v podstatě přenesl i aplikace postavené na Electronu, čímž snížil množství práce na zobrazovacím stacku, kterou by každý aplikační tým musel udělat samostatně.
Bez frameworků, jako je Electron, by mnoho firem nativní klienty pro Linux nevytvářelo. Jednoduše by podporovaly macOS a Windows a uživatelům Linuxu by zbyla karta v prohlížeči.
Electron pravděpodobně udělal pro komerční desktopový software na Linuxu víc, než se mu přiznává.
I Microsoft stále častěji volí webové technologie
Microsoft je možná nejsilnějším protipříkladem k představě, že seriózní software pro Windows by měl vždy používat nativní frameworky uživatelského rozhraní pro Windows.
Microsoft má pod kontrolou Windows. Má pod kontrolou Win32, .NET, WinUI, WebView2 a velkou část platformy, na které vývojáři stavějí. Kdyby byl plně nativní vývoj pro Windows vždy jasnou volbou, Microsoft by měl ty nejlepší podmínky k tomu, aby jej používal všude.
Nepoužívá.
Visual Studio Code využívá Electron. Teams zůstává postavený na Reactu, TypeScriptu a Chromiu i poté, co Microsoft nahradil Electron optimalizovanějším hostitelským prostředím WebView2. Nový Outlook pro Windows také výrazně spoléhá na webové technologie a Microsoft tuto architekturu výslovně popisuje jako způsob, jak zvýšit agilitu, umožnit rychlejší dodávání funkcí a vytvořit konzistentnější uživatelský zážitek.
Teams je zvlášť poučný. Microsoft chtěl zlepšit výkon a snížit spotřebu prostředků, a tak změnil architekturu. Uživatelské rozhraní ale nepřepsal do podoby tradiční nativní aplikace pro Windows.
Ponechal webový stack a optimalizoval vše kolem něj.
Na tomto rozdílu záleží. Microsoft se rozhodl, že organizační výhody Reactu, TypeScriptu a Chromia stojí za zachování, i když zároveň intenzivně zlepšoval výkon.
Je tu i další poučení. Sám Microsoft v průběhu let představil mnoho generací technologií pro aplikace ve Windows: Win32, WPF, UWP, WinUI a další. Firma, která si vybere „nativní Windows“, si nemusí nutně vybírat nadčasovou platformu. Často sází na jednu generaci frameworku, který Microsoft preferuje.
Webová platforma se poněkud paradoxně stala jednou ze stabilnějších dostupných cílových platforem pro aplikace.
Nábor je součástí architektury
Volba frameworku také určuje, koho můžete najmout.
Vývojáři JavaScriptu a TypeScriptu tvoří jednu z největších skupin vývojářských talentů v oboru. Firma, která staví na Electronu, může nabírat z této skupiny, místo aby potřebovala samostatné týmy zkušených specialistů na macOS, Windows a Linux.
Nativní specialisté zůstávají cenní. Seriózní desktopové produkty stále potřebují vývojáře, kteří do hloubky rozumějí operačním systémům. Electron ale mění počet specialistů, které potřebujete.
Místo toho, aby většinu aplikace museli vytvářet odborníci na konkrétní platformy, můžete udržovat relativně malé množství kódu pro nativní integraci a nechat většinu týmu pracovat na společném produktu.
To je ještě důležitější, když firma už má webovou aplikaci. Komponenty Reactu lze někdy sdílet. Knihovny TypeScriptu lze používat opakovaně. Produktovou logiku lze přesouvat mezi webem a desktopem. Vývojáři mohou přecházet mezi týmy, aniž by se museli učit zcela odlišný ekosystém.
Nábor je také méně zranitelný. Pokud odejde jediný vývojář, který do hloubky rozumí vašemu nativnímu klientovi pro Windows, může být obtížné jeho znalosti nahradit. S Electronem využívá mnohem větší část kódové základny technologie, které zná zbytek organizace.
Framework tedy neurčuje pouze to, jak se vykresluje rozhraní. Ovlivňuje i to, jak může být uspořádána samotná vývojová organizace.
Nativní automaticky neznamená lepší software
Vývojáři často používají slovo „nativní“ téměř jako synonymum slova „rychlý“.
Není tomu tak.
Nativní API dávají vývojářům příležitost vytvořit velmi efektivní aplikaci. To, zda jí výsledný produkt skutečně bude, závisí na architektuře, týmu, rozpočtu a množství optimalizační práce, které si firma může dovolit.
Nativní aplikace může být stále pomalá, chybová, náročná na paměť, nekonzistentní nebo špatně udržovaná.
Ještě důležitější je, že rozdělení omezeného týmu mezi několik nativních implementací znamená méně vývojářských hodin pro každou z nich.
Představte si firmu, která má pro svůj desktopový produkt k dispozici šest vývojářů. Jednou možností je rozdělit je mezi Mac a Windows a Linux možná nechat bez podpory. Druhou je nasadit téměř všech šest na jednu společnou aplikaci v Electronu pro všechny tři platformy.
Který přístup dává firmě větší vývojovou kapacitu ke zkracování doby spouštění, opravování úniků paměti, dolaďování interakcí, zlepšování přístupnosti, snižování počtu pádů a reagování na uživatele?
Není zřejmé, že nativní aplikace povedou k lepšímu produktu.
Vzniká tak zajímavý paradox: framework, který spotřebovává o něco více prostředků počítače, může firmě umožnit vytvořit lépe optimalizovaný produkt, protože spotřebovává mnohem méně vývojových kapacit.
Electron vám dává platformu pod kontrolou
Electron má také další výhodu, kterou lze snadno přehlédnout: dodává se s tím běhovým prostředím Chromium, pro které byla aplikace vytvořena a otestována.
Tím z multiplatformního vývoje odstraňuje jednu zásadní proměnnou.
Frameworky založené na webových pohledech operačního systému mohou vést k menším aplikacím, ale za cenu toho, že stejný frontend může běžet na WebView2 ve Windows, WKWebView v macOS a WebKitGTK v Linuxu. Tyto enginy mají různé možnosti, chyby, harmonogramy vydávání i chování při vykreslování.
Electron volí jiný kompromis: přibalí běhové prostředí a udělá z něj součást aplikace.
Ano, zabírá to místo na disku.
Vývojářům to ale poskytuje mnohem konzistentnější cílové prostředí napříč třemi velmi odlišnými operačními systémy.
Konzistence má pro vývoj obrovskou hodnotu.
Když Electron nestačí, stále můžete použít nativní kód
Volba Electronu neznamená, že se vzdáváte přístupu k nativním možnostem.
Aplikace postavené na Electronu mohou podle potřeby používat nativní moduly a kód specifický pro jednotlivé platformy. Architektonická volba tedy ve skutečnosti nezní:
100 % nativního kódu nebo 100 % JavaScriptu.
Pro mnoho produktů je lepší model:
většina aplikace je společná, s malým množstvím nativního kódu tam, kde ho operační systém skutečně vyžaduje.
Nativní kód se stává záchranným řešením, nikoli základem celého produktu.
Pro mnoho firem je to mnohem lepší způsob rozdělení vývojového úsilí.
Uživatele zajímají produkty, ne frameworky
Existuje malá skupina technicky zdatných uživatelů, kteří otevřou Monitor aktivity, všimnou si několika procesů Chromia a okamžitě si stěžují, že aplikace používá Electron.
Většina uživatelů to nedělá.
Nezajímá je, že Slack používá Electron. Nezajímá je, že VS Code stojí na webových technologiích. Nevědí, jaký framework používá Claude. Zajímá je, jestli jim software pomáhá zvládnout práci.
Pokud se aplikace spouští dostatečně rychle, reaguje svižně, zřídka padá a řeší uživatelův problém, technologie její implementace je do značné míry neviditelná.
Stejně tak platí opak. Nativní aplikace se automaticky nestává dobrým produktem jen proto, že používá Swift nebo WinUI.
Software soutěží na úrovni produktů, nikoli na úrovni frameworků.
Optimalizujte firmu, nejen binární soubor
Electron má skutečné náklady. Zabírá více místa na disku. Jeho základní paměťové nároky jsou obvykle vyšší než u malé nativní aplikace. Rozhodně existují produkty, u nichž tyto náklady činí z Electronu špatnou volbu.
Drobný nástroj v řádku nabídek pravděpodobně nepotřebuje Chromium. Ovladač zařízení ho určitě nepotřebuje. Hry, profesionální audio software a aplikace mimořádně citlivé na latenci mají jiné požadavky. A pokud váš produkt bude vždy běžet jen na jednom operačním systému, nativní vývoj se obhajuje mnohem snáze.
Obrovské procento moderního desktopového softwaru ale do těchto kategorií nepatří.
Jde o složitá rozhraní připojená ke cloudovým službám. Musí běžet na Windows i macOS a uživatelé stále častěji očekávají také podporu Linuxu. Musí se neustále vyvíjet. Soutěží s produkty, které vydávají změny každý týden. A obvykle je vytváří firma s omezeným počtem vývojářů.
U těchto produktů je produktivita vývojářů součástí výkonnosti aplikace.
Electron umožňuje firmě nabírat z mnohem většího okruhu talentů, sdílet vývojáře mezi webem a desktopem, udržovat jednu hlavní aplikaci místo několika, využívat ekosystém JavaScriptu, konzistentněji vydávat funkce napříč operačními systémy, podporovat Linux za náklady, které by se jinak často obtížně ospravedlňovaly, a věnovat více vývojového času zlepšování produktu namísto údržby paralelních implementací.
Náklady Electronu snadno změříte v megabajtech.
Náklady alternativy jsou hůře viditelné. Projevují se jako další vývojáři, duplicitní implementace, delší cykly vydávání, chyby specifické pro jednotlivé platformy, obtíže s náborem, izolované organizační týmy, uživatelé Linuxu bez podpory a funkce, které se ke všem dostanou o měsíce později.
Tyto náklady se v Monitoru aktivity neobjeví.
Pro firmu, která software vytváří, ale mohou být podstatně vyšší.
Cílem vývoje softwaru není vytvořit nejmenší binární soubor.
Je jím vytvořit nejlepší produkt, který vaše organizace dokáže vydávat, udržovat a průběžně zlepšovat.
Pro překvapivě velkou skupinu desktopových aplikací zůstává Electron jedním z nejefektivnějších způsobů, jak přesně toho dosáhnout.