Tillbringa tillräckligt mycket tid på Hacker News eller Reddit så kommer du förr eller senare att se samma kritik: Electron är uppsvällt, Electron använder för mycket minne och seriösa skrivbordsapplikationer borde vara native.
Det ligger en del sanning i den kritiken. Electron-applikationer har i allmänhet en större grundläggande resursförbrukning eftersom de levereras med Chromium och Node.js. En omsorgsfullt utvecklad native-applikation kan använda mindre minne, starta snabbare och integreras djupare med sitt operativsystem.
Men den här debatten fokuserar för mycket på datorn och för lite på företaget som bygger programvaran.
För de flesta användare spelar tekniken bakom en applikation knappt någon roll. De bryr sig om huruvida den fungerar, om den känns responsiv, om buggar åtgärdas och om användbara funktioner fortsätter att tillkomma. För ett programvaruföretag är därför en av de viktigaste egenskaperna hos en teknikstack något som sällan syns i prestandatabeller: hur snabbt kan teamet bygga, leverera, lära sig och förbättra produkten?
För många moderna skrivbordsapplikationer är Electron exceptionellt bra på just det.
Den knappa resursen är utvecklartid
Det idealiserade företaget som utvecklar native-applikationer för skrivbordet har ett utmärkt macOS-team, ett annat team som bygger Windows-applikationen och kanske ytterligare ett team som stöder Linux. Varje applikation är noggrant optimerad för sin plattform, och varje utvecklare har djup förståelse för operativsystemet de arbetar med.
De flesta företag har inte den lyxen.
En skrivbordsprodukt kanske har fem utvecklare. Den kanske har två. Samma utvecklare måste bygga funktioner, åtgärda buggar, förbättra prestandan, svara kunder, underhålla infrastrukturen, hantera förändringar i operativsystemen och fortsätta driva produkten framåt.
Native-utveckling gör detta svårare eftersom macOS, Windows och Linux verkligen är olika plattformar. De har olika UI-ramverk, API:er, behörighetssystem, livscykelbeteenden, installationsprogram, uppdateringsmekanismer, aviseringssystem, fönsterhantering, tillgänglighets-API:er och åratal av plattformsspecifika egenheter.
Electron förändrar den ekvationen. Det kombinerar Chromium, Node.js och skrivbords-API:er till en gemensam applikationsmodell för macOS, Windows och Linux. Samma TypeScript-utvecklare kan ofta bygga en funktion från gränssnitt till applikationslogik och leverera den på alla skrivbordsplattformar. Native-kod finns fortfarande tillgänglig när den verkligen behövs, men den blir undantaget snarare än produktens grund. Electron beskriver självt detta som en av sina främsta fördelar: en enda JavaScript-kodbas för alla tre stora skrivbordsplattformar.
Den skillnaden växer över tid. Om varje betydande funktion kräver separata implementationer för Mac och Windows betalar företaget den extra plattformskostnaden om och om igen: för varje funktion, omdesign, experiment, buggfix, tillgänglighetsförbättring och prestandaoptimering.
Med Electron görs mycket av det arbetet en enda gång.
Electron optimerar för snabba iterationer
Produkter blir sällan fantastiska för att den första implementationen var perfekt. De blir fantastiska genom iteration.
Ett team levererar något. Kunderna använder det. Teamet lär sig. Det förändrar funktionen. Fler människor använder den. Ett annat problem blir synligt. Teamet förbättrar den igen.
Ju kortare cykeln mellan idé, implementation, återkoppling och förbättring är, desto snabbare blir en produkt bättre.
Electron är ovanligt bra på att förkorta den cykeln eftersom det bygger på tekniker som programvaruföretag redan använder överallt: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js och npm.
Det innebär att företag kan dela mycket mer än källkod. De kan dela utvecklare, UI-komponenter, verktyg, bibliotek, infrastruktur, testmetoder och organisatorisk kunskap mellan sina webb- och skrivbordsprodukter.
En frontendutvecklare blir inte plötsligt irrelevant för att företaget behöver hjälp med Windows-klienten. En skrivbordsutvecklare kan bidra till webbapplikationen. En fullstackutvecklare som arbetar med TypeScript kan röra sig mellan produkter när prioriteringarna förändras.
För ett litet eller medelstort företag kan den flexibiliteten vara värd betydligt mer än att spara 100 MB RAM.
Titta på vilka som faktiskt använder Electron
Electron beskrivs ibland som en genväg för företag som inte vill investera i en ”riktig” skrivbordsapplikation. Produkterna som byggts med det gör det argumentet allt svårare att upprätthålla.
Electrons eget projekt lyfter fram produkter som Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom och Canva. Det här är inga enkla småverktyg. Många hör till världens mest avancerade och mest använda produktivitetsapplikationer.
Visual Studio Code är ett särskilt användbart exempel. Microsoft skulle kunna bygga sin främsta kodredigerare med praktiskt taget vilken Windows-teknik som helst, men ändå använder VS Code Electron på Windows, macOS och Linux. Det innehåller terminaler, felsökning, språkservrar, Git-integration, fjärrutveckling, notebooks, tillägg och långtgående anpassade redigerare.
Den intressanta frågan är inte om Microsoft skulle kunna spara minne genom att bygga tre separata native-versioner. Det skulle de naturligtvis kunna.
En bättre fråga är om VS Code hade utvecklats lika snabbt, förblivit lika enhetligt mellan plattformarna och fått ett så stort ekosystem om varje viktig funktion hade krävt flera separata implementationer.
ChatGPT och Claude visar skillnaden i tillvägagångssätt
Kontrasten mellan ChatGPT och Claude är också lärorik.
OpenAI byggde till en början en särskild native-applikation för ChatGPT på macOS. Anthropic byggde däremot Claude Desktop med Electron och hade från början en gemensam grund för skrivbordsapplikationen på olika plattformar.
Den skillnaden blev viktigare när produkterna växte. Claude Desktop kunde fortsätta lägga till funktioner som MCP-integrationer, tillägg och Claude Code i samma plattformsoberoende applikation. Anthropic stöder nu Claude Code direkt i sin skrivbordsapplikation, inklusive flera lokala sessioner och fjärrsessioner.
OpenAI styrde senare också sin nyare, plattformsoberoende skrivbordssatsning mot Electron, och Electron listar nu både ChatGPT och Claude bland framstående Electron-applikationer.
Det vore att gå för långt att hävda att Electron ensamt förklarar skillnaden i produktutvecklingstakt. Teamstorlek, prioriteringar, produktstrategi och intern organisation spelar alla roll. Men den arkitektoniska fördelen är tydlig: en gemensam plattformsoberoende grund gör det enklare att leverera funktioner på olika operativsystem utan att underhålla separata implementationer.
Det är precis den sorts fördel som blir mer värdefull när en skrivbordsprodukt växer.
Evernote fick lära sig kostnaden för att underhålla separata klienter
Evernote är ett av de tydligaste historiska exemplen på detta problem.
I många år underhöll Evernote olika applikationer för Mac, Windows, mobila enheter och webben. Med tiden samlade dessa produkter på sig olika beteenden, skillnader i rendering, äldre antaganden och synkroniseringsproblem.
År 2020 byggde Evernote om sina Windows- och Mac-applikationer kring en gemensam kodbas. Företaget sade att den nya grunden skulle göra apparna stabilare, göra det möjligt att åtgärda buggar snabbare, leverera funktioner oftare och förbättra synkroniseringen mellan plattformarna.
Den övergången var inte smärtfri, och vissa långvariga användare ogillade att plattformsspecifika funktioner inledningsvis försvann. Men skälet till att Evernote genomförde en så kostsam omskrivning är mer intressant än själva migrationsproblemen.
När en produkt väl har en avancerad redigerare, offlinelagring, sökning, bilagor, samarbete, uppgifter, kalendrar och komplex synkronisering blir det allt dyrare att underhålla flera oberoende implementationer. Buggar beter sig olika. Renderingen skiljer sig åt. Synkroniseringslogiken samverkar med olika lokala arkitekturer. Varje betydande produktförändring måste föras vidare till flera klienter.
En gemensam arkitektur får inte svåra problem att försvinna. Den gör det möjligt för företaget att lösa fler av dem en enda gång.
Linux kan vara Electrons mest underskattade fördel
Linux gör argumenten för Electron ännu starkare.
Att stödja Linux ordentligt är svårt. Till skillnad från macOS eller Windows är ”Linux på skrivbordet” inte en enda strikt kontrollerad plattform. Utvecklare måste hantera olika distributioner, paketformat, skrivbordsmiljöer, grafikstackar, systembibliotek och visningsprotokoll.
För många programvaruföretag skulle det rationella affärsbeslutet helt enkelt vara att inte stödja Linux.
Electron förändrar de ekonomiska förutsättningarna.
Eftersom Electron tillhandahåller en gemensam körmiljö för macOS, Windows och Linux kan det vara dramatiskt enklare att lägga till Linux-stöd än att underhålla en separat native-implementation för Linux. Det är ett av skälen till att Linux-användare i dag har tillgång till många stora skrivbordsapplikationer som tidigare kanske aldrig skulle ha fått en officiell Linux-klient.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian och många andra verktyg kan stödja Linux utan att underhålla en helt separat GTK- eller Qt-applikation.
Electron tar också hand om en stor del av den Linux-specifika komplexiteten åt applikationsutvecklarna. Ett bra exempel är övergången från X11 till Wayland. De som underhåller Electron har beskrivit hur Chromiums övergång till Wayland i praktiken tog Electron-applikationerna med sig och därmed minskade det arbete med grafiksystemet som varje applikationsteam behövde göra på egen hand.
Utan ramverk som Electron skulle många företag inte bygga native-klienter för Linux. De skulle helt enkelt stödja macOS och Windows och lämna Linux-användarna med en webbläsarflik.
Electron har förmodligen gjort mer för kommersiell skrivbordsprogramvara på Linux än det får erkännande för.
Även Microsoft väljer allt oftare webbteknik
Microsoft är kanske det starkaste motexemplet till idén att seriös Windows-programvara alltid bör använda Windows egna native-ramverk för användargränssnitt.
Microsoft kontrollerar Windows. Det kontrollerar Win32, .NET, WinUI, WebView2 och en stor del av plattformen som utvecklarna bygger på. Om helt native-baserad Windows-utveckling alltid vore det självklara svaret skulle Microsoft ha bästa tänkbara förutsättningar att använda den överallt.
Det gör de inte.
Visual Studio Code använder Electron. Teams är fortfarande byggt kring React, TypeScript och Chromium, även efter att Microsoft ersatte Electron med en mer optimerad WebView2-värdapplikation. Nya Outlook för Windows bygger också i hög grad på webbteknik, och Microsoft beskriver uttryckligen den arkitekturen som ett sätt att öka flexibiliteten, möjliggöra snabbare leverans av funktioner och skapa en mer enhetlig upplevelse.
Teams är särskilt lärorikt. Microsoft ville förbättra prestandan och minska resursförbrukningen, så de förändrade arkitekturen. Men de skrev inte om användargränssnittet till en traditionell native-applikation för Windows.
De behöll webbstacken och optimerade runt den.
Den skillnaden är viktig. Microsoft ansåg att de organisatoriska fördelarna med React, TypeScript och Chromium var värda att bevara, även när de satsade kraftfullt på att förbättra prestandan.
Här finns också en annan lärdom. Microsoft har självt introducerat många generationer av applikationsteknik för Windows genom åren: Win32, WPF, UWP, WinUI och andra. Ett företag som väljer ”native för Windows” väljer inte nödvändigtvis en tidlös plattform. Ofta satsar det på en viss generation av Microsofts föredragna ramverk.
Webbplattformen har, något ironiskt, blivit en av de stabilare plattformarna att bygga applikationer för.
Rekrytering är en del av arkitekturen
Valet av ramverk avgör också vilka du kan rekrytera.
JavaScript- och TypeScript-utvecklare utgör en av branschens största kompetenspooler. Ett företag som bygger med Electron kan rekrytera ur den poolen i stället för att behöva separata team med erfarna specialister på macOS, Windows och Linux.
Native-specialister är fortfarande värdefulla. Seriösa skrivbordsprodukter behöver fortfarande utvecklare med djup förståelse för operativsystem. Men Electron förändrar hur många specialister som behövs.
I stället för att kräva att större delen av applikationen byggs av plattformsexperter kan man hålla mängden native-kod för integration relativt liten och låta större delen av teamet arbeta med den gemensamma produkten.
Detta blir ännu viktigare när ett företag redan har en webbapplikation. React-komponenter kan ibland delas. TypeScript-bibliotek kan återanvändas. Produktlogik kan flyttas mellan webb och skrivbord. Utvecklare kan byta team utan att lära sig ett helt annat ekosystem.
Rekryteringen blir också mindre sårbar. Om den enda utvecklaren som har djup förståelse för din native-klient för Windows slutar kan det vara svårt att ersätta den kompetensen. Med Electron använder en mycket större del av kodbasen tekniker som resten av organisationen känner till.
Ett ramverk avgör därför inte bara hur ett gränssnitt renderas. Det påverkar hur själva utvecklingsorganisationen kan struktureras.
Native betyder inte automatiskt bättre programvara
Utvecklare använder ofta ”native” nästan som en synonym till ”snabb”.
Det är det inte.
Native-API:er ger utvecklare möjlighet att skapa en mycket effektiv applikation. Om slutprodukten faktiskt uppnår det beror på arkitekturen, teamet, budgeten och hur mycket optimeringsarbete företaget har råd med.
En native-applikation kan fortfarande vara långsam, buggig, minneskrävande, inkonsekvent eller dåligt underhållen.
Än viktigare är att om ett begränsat team delas upp mellan flera native-implementationer får varje implementation färre utvecklartimmar.
Föreställ dig att ett företag har sex utvecklare tillgängliga för sin skrivbordsprodukt. Ett alternativ är att dela upp dem mellan Mac och Windows och kanske lämna Linux utan stöd. Ett annat är att låta nästan alla sex utvecklarna arbeta med en gemensam Electron-applikation för alla tre plattformarna.
Vilket tillvägagångssätt ger företaget mer utvecklingskapacitet för att förbättra starttiden, åtgärda minnesläckor, finslipa interaktioner, förbättra tillgängligheten, minska krascher och lyssna på användarna?
Det är inte självklart att native-applikationerna ger den bättre produkten.
Det skapar en intressant paradox: ett ramverk som förbrukar något mer datorresurser kan göra det möjligt för ett företag att bygga en bättre optimerad produkt eftersom det kräver betydligt färre utvecklingsresurser.
Electron ger dig en kontrollerad plattform
Electron har också en annan fördel som är lätt att förbise: det levereras med den Chromium-körmiljö som applikationen byggdes och testades mot.
Det tar bort en viktig variabel från plattformsoberoende utveckling.
Ramverk som bygger på operativsystemens webbvisningskomponenter kan ge mindre applikationer, men avvägningen är att samma frontend kan köras i WebView2 på Windows, WKWebView på macOS och WebKitGTK på Linux. Dessa motorer har olika funktioner, buggar, utgivningsscheman och renderingsbeteenden.
Electron gör en annan avvägning: paketera körmiljön tillsammans med applikationen och gör den till en del av den.
Ja, det kostar diskutrymme.
Men det ger utvecklarna en mycket mer enhetlig målplattform på tre väldigt olika operativsystem.
Enhetlighet har ett enormt värde i utvecklingsarbetet.
När Electron inte räcker kan du fortfarande använda native-kod
Att välja Electron innebär inte att ge upp tillgången till plattformarnas egna funktioner.
Electron-applikationer kan använda native-moduler och plattformsspecifik kod där det behövs. Det innebär att det arkitektoniska valet egentligen inte står mellan:
100 % native och 100 % JavaScript.
För många produkter är en bättre modell:
större delen av applikationen är gemensam, med en liten mängd native-kod där operativsystemet verkligen kräver det.
Native-kod blir en reservlösning snarare än grunden för hela produkten.
Det är en mycket bättre fördelning av utvecklingsarbetet för många företag.
Användare bryr sig om produkter, inte ramverk
Det finns en liten grupp tekniskt kunniga användare som öppnar Aktivitetskontroll, ser flera Chromium-processer och omedelbart klagar på att en applikation använder Electron.
De flesta användare gör inte det.
De bryr sig inte om att Slack använder Electron. De bryr sig inte om att VS Code är byggt med webbteknik. De vet inte vilket ramverk Claude använder. De bryr sig om huruvida programvaran hjälper dem att få sitt arbete gjort.
Om en applikation startar tillräckligt snabbt, känns responsiv, sällan kraschar och löser användarens problem är implementationstekniken i stort sett osynlig.
Det omvända gäller också. En native-applikation blir inte automatiskt en bra produkt för att den använder Swift eller WinUI.
Programvara konkurrerar på produktnivå, inte på ramverksnivå.
Optimera företaget, inte bara binärfilen
Electron har verkliga kostnader. Det använder mer diskutrymme. Dess grundläggande minnesförbrukning är vanligtvis högre än för en liten native-applikation. Det finns absolut produkter där dessa kostnader gör Electron till fel val.
Ett litet verktyg i menyraden behöver förmodligen inte Chromium. En drivrutin gör det definitivt inte. Spel, professionell ljudprogramvara och extremt latenskänsliga applikationer har andra krav. Och om din produkt bara någonsin ska köras på ett operativsystem blir native-utveckling mycket enklare att motivera.
Men en enorm andel av modern skrivbordsprogramvara tillhör inte de kategorierna.
Den består av komplexa gränssnitt kopplade till molntjänster. Den behöver köras på Windows och macOS, och allt oftare förväntar sig användarna stöd för Linux också. Den behöver utvecklas kontinuerligt. Den konkurrerar med produkter som levererar förändringar varje vecka. Och den byggs vanligtvis av ett företag med ett begränsat antal utvecklare.
För dessa produkter är utvecklarnas produktivitet en del av applikationens prestanda.
Electron låter ett företag rekrytera ur en mycket större kompetenspool, dela utvecklare mellan webb och skrivbord, underhålla en huvudsaklig applikation i stället för flera, återanvända JavaScript-ekosystemet, leverera funktioner mer enhetligt på olika operativsystem, stödja Linux till en kostnad som annars ofta vore svår att motivera och lägga mer utvecklartid på att förbättra produkten i stället för att underhålla parallella implementationer.
Det är lätt att mäta Electrons kostnad i megabyte.
Alternativets kostnader är svårare att se. De visar sig i form av fler utvecklare, dubblerade implementationer, längre utgivningscykler, plattformsspecifika buggar, rekryteringssvårigheter, organisatoriska silor, Linux-användare utan stöd och funktioner som tar månader längre att nå alla.
De kostnaderna syns inte i Aktivitetskontroll.
Men för företaget som bygger programvaran kan de vara betydligt större.
Målet med programvaruutveckling är inte att producera den minsta binärfilen.
Det är att bygga den bästa produkt som din organisation kan leverera, underhålla och kontinuerligt förbättra.
För en förvånansvärt stor grupp skrivbordsapplikationer är Electron fortfarande ett av de mest effektiva sätten att göra just det.