Bruger du nok tid på Hacker News eller Reddit, vil du før eller siden støde på den samme kritik: Electron er oppustet, Electron bruger for meget hukommelse, og seriøse desktopapplikationer bør være native.
Der er noget sandt i den kritik. Electron-applikationer har generelt et større grundlæggende ressourceforbrug, fordi de leveres med Chromium og Node.js. En omhyggeligt udviklet native-applikation kan bruge mindre hukommelse, starte hurtigere og integrere tættere med sit operativsystem.
Men denne debat fokuserer for meget på computeren og for lidt på virksomheden, der udvikler softwaren.
For de fleste brugere betyder teknologien bag en applikation næsten ingenting. De går op i, om den virker, om den reagerer hurtigt, om fejl bliver rettet, og om der løbende kommer nyttige funktioner. For en softwarevirksomhed er en af de vigtigste egenskaber ved en teknologistak derfor noget, der sjældent optræder i benchmarktabeller: Hvor hurtigt kan teamet udvikle, udgive, lære og forbedre produktet?
For mange moderne desktopapplikationer er Electron usædvanligt god til netop det.
Den knappe ressource er udviklingstid
Den idealiserede virksomhed, der udvikler native-desktopsoftware, har et fremragende macOS-team, et andet team, der udvikler Windows-applikationen, og måske endnu et team, der understøtter Linux. Hver applikation er omhyggeligt optimeret til sin platform, og hver udvikler har indgående kendskab til det operativsystem, vedkommende arbejder med.
De fleste virksomheder har ikke den luksus.
Et desktopprodukt har måske fem udviklere. Måske har det to. De samme udviklere skal bygge funktioner, rette fejl, forbedre ydeevnen, svare kunder, vedligeholde infrastruktur, håndtere ændringer i operativsystemer og holde produktets udvikling i gang.
Native-udvikling gør dette sværere, fordi macOS, Windows og Linux reelt er forskellige platforme. De har forskellige UI-frameworks, API'er, tilladelsessystemer, livscyklusadfærd, installationsprogrammer, opdateringsmekanismer, notifikationssystemer, vindueshåndtering, tilgængeligheds-API'er og årevis af platformspecifikke særheder.
Electron ændrer det regnestykke. Det kombinerer Chromium, Node.js og desktop-API'er i en fælles applikationsmodel på tværs af macOS, Windows og Linux. Den samme TypeScript-udvikler kan ofte bygge en funktion fra brugergrænseflade til applikationslogik og udgive den på alle desktopplatforme. Native-kode er stadig en mulighed, når der reelt er brug for den, men den bliver undtagelsen frem for produktets fundament. Electron beskriver selv dette som en af sine vigtigste fordele: én JavaScript-kodebase på tværs af alle tre store desktopplatforme.
Den forskel vokser år for år. Hvis hver væsentlig funktion kræver separate implementeringer til Mac og Windows, betaler virksomheden den ekstra platformomkostning igen og igen: for hver funktion, hvert redesign, hvert eksperiment, hver fejlrettelse, hver forbedring af tilgængeligheden og hver optimering af ydeevnen.
Med Electron skal meget af det arbejde kun udføres én gang.
Electron optimerer til hurtig iteration
Produkter bliver sjældent fantastiske, fordi den første implementering var perfekt. De bliver fantastiske gennem iteration.
Et team udgiver noget. Kunderne bruger det. Teamet lærer. Det ændrer funktionen. Flere bruger den. Et nyt problem bliver synligt. Teamet forbedrer den igen.
Jo kortere kredsløbet mellem idé, implementering, feedback og forbedring er, desto hurtigere bliver et produkt bedre.
Electron er usædvanligt god til at forkorte det kredsløb, fordi det er bygget op omkring teknologier, som softwarevirksomheder allerede bruger overalt: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js og npm.
Det betyder, at virksomheder kan dele langt mere end kildekode. De kan dele udviklere, UI-komponenter, værktøjer, biblioteker, infrastruktur, testmetoder og organisatorisk viden mellem deres web- og desktopprodukter.
En frontendudvikler bliver ikke pludselig irrelevant, fordi virksomheden har brug for hjælp til Windows-klienten. En desktopudvikler kan bidrage til webapplikationen. En full-stack TypeScript-udvikler kan skifte mellem produkter, når prioriteterne ændrer sig.
For en lille eller mellemstor virksomhed kan den fleksibilitet være langt mere værd end at spare 100 MB RAM.
Se på, hvem der faktisk bruger Electron
Electron bliver nogle gange beskrevet som en genvej for virksomheder, der ikke vil investere i en »rigtig« desktopapplikation. Produkterne, der er bygget med det, gør det argument stadig sværere at fastholde.
Electrons eget projekt fremhæver produkter som Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom og Canva. Det er ikke simple hjælpeprogrammer. Mange er blandt verdens mest avancerede og mest udbredte produktivitetsapplikationer.
Visual Studio Code er et særligt nyttigt eksempel. Microsoft kunne bygge sin flagskibskodeeditor med praktisk talt enhver Windows-teknologi, virksomheden ønskede, men VS Code bruger Electron på tværs af Windows, macOS og Linux. Den indeholder terminaler, debugging, sprogservere, Git-integration, fjernudvikling, notebooks, udvidelser og stærkt tilpassede editorer.
Det interessante spørgsmål er ikke, om Microsoft kunne spare hukommelse ved at bygge tre separate native-versioner. Det kunne virksomheden selvfølgelig.
Det bedre spørgsmål er, om VS Code ville have udviklet sig lige så hurtigt, været lige så ensartet på tværs af platforme og fået et så stort økosystem, hvis hver større funktionalitet krævede flere separate implementeringer.
ChatGPT og Claude viser forskellen i tilgang
Kontrasten mellem ChatGPT og Claude er også lærerig.
OpenAI byggede i første omgang en dedikeret native-applikation til ChatGPT på macOS. Anthropic byggede derimod Claude Desktop med Electron og havde fra begyndelsen et fælles desktopfundament på tværs af platforme.
Den forskel blev vigtigere, efterhånden som produkterne voksede. Claude Desktop kunne løbende tilføje funktionalitet som MCP-integrationer, udvidelser og Claude Code i den samme applikation på tværs af platforme. Anthropic understøtter nu Claude Code direkte i sin desktopapplikation, herunder flere lokale og eksterne sessioner.
OpenAI bevægede senere også sin nyere desktopstrategi på tværs af platforme i retning af Electron, og Electron opfører nu både ChatGPT og Claude blandt fremtrædende Electron-applikationer.
Det ville være for vidtgående at hævde, at Electron alene forklarer forskellen i produktudviklingens hastighed. Teamstørrelse, prioriteter, produktstrategi og intern organisering spiller alle en rolle. Men den arkitektoniske fordel er ligetil: Et fælles fundament på tværs af platforme gør det lettere at udgive funktioner på tværs af operativsystemer uden at vedligeholde separate implementeringer.
Det er præcis den slags fordel, der bliver mere værdifuld, efterhånden som et desktopprodukt vokser.
Evernote lærte, hvad det koster at vedligeholde separate klienter
Evernote er et af de tydeligste historiske eksempler på dette problem.
I årevis vedligeholdt Evernote forskellige applikationer til Mac, Windows, mobile enheder og web. Med tiden ophobede disse produkter forskellig adfærd, forskelle i rendering, forældede antagelser og synkroniseringsproblemer.
I 2020 genopbyggede Evernote sine Windows- og Mac-applikationer omkring en fælles kodebase. Virksomheden sagde, at det nye fundament ville gøre applikationerne mere stabile, gøre det muligt at rette fejl hurtigere, udgive funktioner oftere og forbedre synkroniseringen på tværs af platforme.
Den overgang var ikke smertefri, og nogle mangeårige brugere var utilfredse med det indledende tab af platformspecifikke funktioner. Men grunden til, at Evernote gennemførte en så dyr omskrivning, er mere interessant end selve overgangsproblemerne.
Når et produkt først har en avanceret editor, offlinelagring, søgning, vedhæftede filer, samarbejde, opgaver, kalendere og kompleks synkronisering, bliver det stadig dyrere at vedligeholde flere uafhængige implementeringer. Fejl opfører sig forskelligt. Renderingen varierer. Synkroniseringslogikken spiller sammen med forskellige lokale arkitekturer. Hver væsentlig produktændring skal føres ud i flere klienter.
En fælles arkitektur får ikke svære problemer til at forsvinde. Den gør det muligt for virksomheden at løse flere af dem én gang.
Linux er måske Electrons mest undervurderede fordel
Linux gør argumentet for Electron endnu stærkere.
Det er svært at understøtte Linux ordentligt. I modsætning til macOS eller Windows er »Linux-desktop« ikke én stramt kontrolleret platform. Udviklere skal håndtere forskellige distributioner, pakkeformater, skrivebordsmiljøer, grafikstakke, systembiblioteker og displayprotokoller.
For mange softwarevirksomheder ville den rationelle forretningsbeslutning ganske enkelt være ikke at understøtte Linux.
Electron ændrer økonomien.
Fordi Electron tilbyder et fælles kørselsmiljø på tværs af macOS, Windows og Linux, kan det være markant lettere at tilføje Linux-understøttelse end at vedligeholde en separat native-implementering til Linux. Det er en af grundene til, at Linux-brugere i dag har adgang til mange store desktopapplikationer, der historisk set måske aldrig ville have fået en officiel Linux-klient.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian og mange andre værktøjer kan understøtte Linux uden at vedligeholde en helt separat GTK- eller Qt-applikation.
Electron håndterer også en stor del af den Linux-specifikke kompleksitet på applikationsudviklernes vegne. Et godt eksempel er overgangen fra X11 til Wayland. Electrons vedligeholdere har beskrevet, hvordan Chromiums overgang til Wayland i praksis tog Electron-applikationerne med sig og dermed reducerede det arbejde med displaystakken, som hvert applikationsteam ellers skulle have udført på egen hånd.
Uden frameworks som Electron ville mange virksomheder ikke bygge native-klienter til Linux. De ville blot understøtte macOS og Windows og efterlade Linux-brugerne med en browserfane.
Electron har sandsynligvis gjort mere for kommerciel Linux-desktopsoftware, end det får anerkendelse for.
Selv Microsoft vælger i stigende grad webteknologi
Microsoft er måske det stærkeste modeksempel på idéen om, at seriøs Windows-software altid bør bruge native UI-frameworks til Windows.
Microsoft kontrollerer Windows. Virksomheden kontrollerer Win32, .NET, WinUI, WebView2 og en stor del af den platform, som udviklere bygger på. Hvis fuldt native Windows-udvikling altid var det indlysende svar, ville Microsoft have de bedst mulige forudsætninger for at bruge det overalt.
Det gør virksomheden ikke.
Visual Studio Code bruger Electron. Teams er fortsat bygget omkring React, TypeScript og Chromium, selv efter at Microsoft erstattede Electron med et mere optimeret WebView2-værtsmiljø. Det nye Outlook til Windows er også i høj grad baseret på webteknologi, og Microsoft beskriver udtrykkeligt den arkitektur som en måde at øge agiliteten, muliggøre hurtigere levering af funktioner og skabe en mere ensartet oplevelse.
Teams er særligt lærerigt. Microsoft ville forbedre ydeevnen og reducere ressourceforbruget, så virksomheden ændrede arkitekturen. Men den omskrev ikke brugergrænsefladen til en traditionel native Windows-applikation.
Den beholdt webstakken og optimerede omkring den.
Den skelnen er vigtig. Microsoft vurderede, at de organisatoriske fordele ved React, TypeScript og Chromium var værd at bevare, selv mens virksomheden målrettet forbedrede ydeevnen.
Der er også en anden lære her. Microsoft har selv introduceret mange generationer af Windows-applikationsteknologi gennem årene: Win32, WPF, UWP, WinUI og andre. En virksomhed, der vælger »native Windows«, vælger ikke nødvendigvis en tidløs platform. Den satser ofte på én generation af Microsofts foretrukne framework.
Webplatformen er, noget ironisk, blevet en af de mere stabile platforme at udvikle applikationer til.
Rekruttering er en del af arkitekturen
Valget af framework afgør også, hvem man kan ansætte.
JavaScript- og TypeScript-udviklere udgør en af branchens største talentpuljer. En virksomhed, der bygger med Electron, kan rekruttere fra den pulje i stedet for at skulle have separate teams af erfarne macOS-, Windows- og Linux-specialister.
Specialister i native-udvikling er stadig værdifulde. Seriøse desktopprodukter har stadig brug for udviklere med indgående kendskab til operativsystemer. Men Electron ændrer, hvor mange specialister der er brug for.
I stedet for at kræve, at det meste af applikationen bygges af platformseksperter, kan man nøjes med en relativt lille mængde native-integrationskode og lade størstedelen af teamet arbejde på det fælles produkt.
Det betyder endnu mere, når en virksomhed allerede har en webapplikation. React-komponenter kan nogle gange deles. TypeScript-biblioteker kan genbruges. Produktlogik kan flyttes mellem web og desktop. Udviklere kan skifte team uden at skulle lære et helt andet økosystem.
Rekrutteringen bliver også mindre sårbar. Hvis den eneste udvikler, der har indgående kendskab til virksomhedens native Windows-klient, forlader virksomheden, kan det være svært at erstatte den ekspertise. Med Electron bruger en langt større del af kodebasen teknologier, som resten af organisationen kender.
Et framework afgør derfor ikke blot, hvordan en brugergrænseflade renderes. Det påvirker også, hvordan selve udviklingsorganisationen kan struktureres.
Native betyder ikke automatisk bedre software
Udviklere bruger ofte »native« næsten som et synonym for »hurtig«.
Det er det ikke.
Native-API'er giver udviklere mulighed for at skabe en meget effektiv applikation. Om det endelige produkt faktisk opnår det, afhænger af arkitekturen, teamet, budgettet og hvor meget optimeringsarbejde virksomheden har råd til.
En native-applikation kan stadig være langsom, fejlbehæftet, hukommelseskrævende, inkonsekvent eller dårligt vedligeholdt.
Endnu vigtigere betyder det, at hver implementering får færre udviklingstimer, når et begrænset team fordeles på flere native-implementeringer.
Forestil dig, at en virksomhed har seks udviklere til rådighed til sit desktopprodukt. Én mulighed er at fordele dem mellem Mac og Windows og måske lade Linux være uden understøttelse. En anden er at sætte næsten alle seks udviklere på én fælles Electron-applikation, der betjener alle tre platforme.
Hvilken tilgang giver virksomheden mere udviklingskapacitet til at forbedre opstartstiden, rette hukommelseslækager, finpudse interaktioner, forbedre tilgængeligheden, reducere nedbrud og reagere på brugernes behov?
Det er ikke indlysende, at native-applikationerne giver det bedste produkt.
Det skaber et interessant paradoks: Et framework, der bruger lidt flere maskinressourcer, kan gøre det muligt for en virksomhed at bygge et bedre optimeret produkt, fordi det bruger langt færre udviklingsressourcer.
Electron giver dig en kontrolleret platform
Electron har også en anden fordel, som er let at overse: Det leveres med det Chromium-kørselsmiljø, som applikationen er bygget og testet med.
Det fjerner en væsentlig variabel fra udvikling på tværs af platforme.
Frameworks baseret på operativsystemets webviews kan give mindre applikationer, men kompromiset er, at den samme frontend måske kører på WebView2 i Windows, WKWebView i macOS og WebKitGTK i Linux. Disse motorer har forskellige muligheder, fejl, udgivelsesplaner og renderingsadfærd.
Electron vælger et andet kompromis: Pak kørselsmiljøet med, og gør det til en del af applikationen.
Ja, det koster diskplads.
Men det giver udviklere en langt mere ensartet platform på tværs af tre meget forskellige operativsystemer.
Ensartethed har enorm værdi i udviklingsarbejdet.
Når Electron ikke er nok, kan du stadig bruge native-kode
At vælge Electron betyder ikke, at man opgiver adgangen til native-funktionalitet.
Electron-applikationer kan bruge native-moduler og platformspecifik kode, hvor det er nødvendigt. Det betyder, at det arkitektoniske valg i virkeligheden ikke er:
100 % native eller 100 % JavaScript.
For mange produkter er en bedre model:
Det meste af applikationen er fælles, med en lille mængde native-kode dér, hvor operativsystemet reelt kræver det.
Native-kode bliver en nødudgang frem for fundamentet for hele produktet.
Det er en langt bedre fordeling af udviklingsindsatsen for mange virksomheder.
Brugerne går op i produkter, ikke frameworks
Der er en lille gruppe teknisk kyndige brugere, som åbner Aktivitetsovervågning, bemærker flere Chromium-processer og straks klager over, at en applikation bruger Electron.
Det gør de fleste brugere ikke.
De er ligeglade med, at Slack bruger Electron. De er ligeglade med, at VS Code er bygget med webteknologier. De ved ikke, hvilket framework Claude bruger. De går op i, om softwaren hjælper dem med at få deres arbejde gjort.
Hvis en applikation starter hurtigt nok, reagerer hurtigt, sjældent går ned og løser brugerens problem, er implementeringsteknologien stort set usynlig.
Det omvendte er lige så sandt. En native-applikation bliver ikke automatisk et godt produkt, fordi den bruger Swift eller WinUI.
Software konkurrerer på produktniveau, ikke på frameworkniveau.
Optimer virksomheden, ikke kun den binære fil
Electron har reelle omkostninger. Det bruger mere diskplads. Dets grundlæggende hukommelsesforbrug er normalt højere end en lille native-applikations. Der findes bestemt produkter, hvor de omkostninger gør Electron til det forkerte valg.
Et lille menulinjeprogram har sandsynligvis ikke brug for Chromium. Det har en enhedsdriver bestemt heller ikke. Spil, professionel lydsoftware og applikationer, der er ekstremt følsomme over for latenstid, har andre krav. Og hvis dit produkt kun nogensinde skal køre på ét operativsystem, bliver native-udvikling langt lettere at retfærdiggøre.
Men en meget stor del af moderne desktopsoftware falder ikke i de kategorier.
Den består af komplekse brugergrænseflader forbundet med cloudtjenester. Den skal køre på Windows og macOS, og brugerne forventer i stigende grad også Linux-understøttelse. Den skal udvikle sig løbende. Den konkurrerer med produkter, der udgiver ændringer hver uge. Og den bliver som regel bygget af en virksomhed med et begrænset antal udviklere.
For de produkter er udviklernes produktivitet en del af applikationens ydeevne.
Electron gør det muligt for en virksomhed at rekruttere fra en langt større talentpulje, dele udviklere mellem web og desktop, vedligeholde én primær applikation i stedet for flere, genbruge JavaScript-økosystemet, udgive funktioner mere ensartet på tværs af operativsystemer, understøtte Linux til en pris, der ellers ofte ville være svær at retfærdiggøre, og bruge mere udviklingstid på at forbedre produktet frem for at vedligeholde parallelle implementeringer.
Man kan let måle Electrons omkostninger i megabyte.
Alternativets omkostninger er sværere at få øje på. De viser sig som ekstra udviklere, dobbeltimplementeringer, længere udgivelsescyklusser, platformspecifikke fejl, rekrutteringsvanskeligheder, organisatoriske siloer, Linux-brugere uden understøttelse og funktioner, der er måneder længere om at nå ud til alle.
De omkostninger dukker ikke op i Aktivitetsovervågning.
Men for virksomheden, der bygger softwaren, kan de være betydeligt større.
Målet med softwareudvikling er ikke at producere den mindste binære fil.
Det er at bygge det bedste produkt, som organisationen kan udgive, vedligeholde og løbende forbedre.
For en overraskende stor gruppe desktopapplikationer er Electron stadig en af de mest effektive måder at gøre netop det på.