Tilbring nok tid på Hacker News eller Reddit, og du vil etter hvert se den samme kritikken: Electron er oppblåst, Electron bruker for mye minne, og seriøse skrivebordsapplikasjoner bør være native.
Det er noe sannhet i denne kritikken. Electron-applikasjoner har som regel et større grunnleggende ressursforbruk fordi de leveres med Chromium og Node.js. En omhyggelig utviklet native applikasjon kan bruke mindre minne, starte raskere og integreres tettere med operativsystemet.
Men denne debatten fokuserer for mye på datamaskinen og for lite på selskapet som utvikler programvaren.
For de fleste brukere spiller teknologien bak en applikasjon knapt noen rolle. De bryr seg om hvorvidt den fungerer, om den føles responsiv, om feil blir rettet, og om det stadig kommer nyttige funksjoner. For et programvareselskap er derfor en av de viktigste egenskapene ved en teknologistakk noe som sjelden dukker opp i ytelsestabeller: Hvor raskt kan teamet utvikle, levere, lære og forbedre produktet?
For mange moderne skrivebordsapplikasjoner er Electron usedvanlig godt egnet til dette.
Den knappe ressursen er utviklingstid
Det idealiserte selskapet som utvikler native skrivebordsprogramvare, har et fremragende macOS-team, et annet team som bygger Windows-applikasjonen, og kanskje enda et team som støtter Linux. Hver applikasjon er nøye optimalisert for sin plattform, og hver utvikler har inngående kjennskap til operativsystemet de jobber med.
De fleste selskaper har ikke den luksusen.
Et skrivebordsprodukt kan ha fem utviklere. Det kan ha to. De samme utviklerne må bygge funksjoner, rette feil, forbedre ytelsen, svare kunder, vedlikeholde infrastruktur, håndtere endringer i operativsystemer og sørge for at produktet utvikler seg videre.
Native utvikling gjør dette vanskeligere fordi macOS, Windows og Linux faktisk er forskjellige plattformer. De har ulike rammeverk for brukergrensesnitt, API-er, tillatelsessystemer, livssyklusatferd, installasjonsprogrammer, oppdateringsmekanismer, varslingssystemer, vindushåndtering, tilgjengelighets-API-er og årevis med plattformspesifikke særegenheter.
Electron endrer dette regnestykket. Det kombinerer Chromium, Node.js og skrivebords-API-er til en felles applikasjonsmodell på tvers av macOS, Windows og Linux. Den samme TypeScript-utvikleren kan ofte bygge en funksjon fra grensesnitt til applikasjonslogikk og levere den på alle skrivebordsplattformer. Native kode er fortsatt tilgjengelig når det virkelig trengs, men blir unntaket snarere enn fundamentet for produktet. Electron beskriver selv dette som en av sine viktigste fordeler: én JavaScript-kodebase på tvers av alle de tre store skrivebordsplattformene.
Denne forskjellen forsterkes over tid. Hvis hver vesentlige funksjon krever separate implementeringer for Mac og Windows, betaler selskapet denne plattformkostnaden om og om igjen: for hver funksjon, redesign, eksperiment, feilretting, tilgjengelighetsforbedring og ytelsesoptimalisering.
Med Electron gjøres mye av dette arbeidet én gang.
Electron optimaliserer for rask iterasjon
Produkter blir sjelden gode fordi den første implementeringen var perfekt. De blir gode gjennom iterasjon.
Et team leverer noe. Kundene bruker det. Teamet lærer. Det endrer funksjonen. Flere bruker den. Et nytt problem blir synlig. Teamet forbedrer den igjen.
Jo kortere syklusen mellom idé, implementering, tilbakemelding og forbedring er, desto raskere blir produktet bedre.
Electron er uvanlig godt egnet til å forkorte denne syklusen fordi det er bygget rundt teknologier som programvareselskaper allerede bruker overalt: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js og npm.
Det betyr at selskaper kan dele langt mer enn kildekode. De kan dele utviklere, grensesnittkomponenter, verktøy, biblioteker, infrastruktur, testmetoder og organisasjonens samlede kunnskap mellom nett- og skrivebordsproduktene sine.
En frontendutvikler blir ikke plutselig irrelevant fordi selskapet trenger hjelp med Windows-klienten. En skrivebordsutvikler kan bidra til nettapplikasjonen. En fullstackutvikler som bruker TypeScript, kan bevege seg mellom produkter etter hvert som prioriteringene endres.
For et lite eller mellomstort selskap kan denne fleksibiliteten være langt mer verdt enn å spare 100 MB RAM.
Se hvem som faktisk bruker Electron
Electron blir noen ganger beskrevet som en snarvei for selskaper som ikke vil investere i en «ordentlig» skrivebordsapplikasjon. Produktene som er bygget med det, gjør dette argumentet stadig vanskeligere å forsvare.
Electrons eget prosjekt trekker frem produkter som Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom og Canva. Dette er ikke enkle hjelpeprogrammer. Mange av dem er blant verdens mest avanserte og mest brukte produktivitetsapplikasjoner.
Visual Studio Code er et særlig nyttig eksempel. Microsoft kunne ha bygget sitt flaggskip blant kodeeditorer med praktisk talt hvilken som helst Windows-teknologi, men VS Code bruker likevel Electron på Windows, macOS og Linux. Det omfatter terminaler, feilsøking, språkservere, Git-integrasjon, fjernutvikling, notatbøker, utvidelser og svært spesialtilpassede editorer.
Det interessante spørsmålet er ikke om Microsoft kunne spart minne ved å bygge tre separate native versjoner. Det kunne de selvfølgelig.
Det bedre spørsmålet er om VS Code ville ha utviklet seg like raskt, forblitt like konsistent på tvers av plattformer og fått et så stort økosystem hvis hver større funksjonalitet krevde flere separate implementeringer.
ChatGPT og Claude viser forskjellen i tilnærming
Kontrasten mellom ChatGPT og Claude er også lærerik.
OpenAI bygget i utgangspunktet en egen native macOS-applikasjon for ChatGPT. Anthropic bygget derimot Claude Desktop på Electron og hadde et felles skrivebordsfundament på tvers av plattformer fra starten av.
Denne forskjellen ble viktigere etter hvert som produktene vokste. Claude Desktop kunne fortsette å legge til funksjonalitet som MCP-integrasjoner, utvidelser og Claude Code i den samme plattformuavhengige applikasjonen. Anthropic støtter nå Claude Code direkte i skrivebordsapplikasjonen, inkludert flere lokale og eksterne økter.
OpenAI dreide senere også sin nyere satsing på skrivebordsapplikasjoner på tvers av plattformer mot Electron, og Electron oppgir nå både ChatGPT og Claude blant fremtredende Electron-applikasjoner.
Det ville være å gå for langt å hevde at Electron alene forklarer forskjellen i utviklingstempo. Teamstørrelse, prioriteringer, produktstrategi og intern organisering spiller alle en rolle. Men den arkitektoniske fordelen er enkel: Et felles fundament på tvers av plattformer gjør det enklere å levere funksjoner på tvers av operativsystemer uten å vedlikeholde separate implementeringer.
Det er nettopp denne typen fordel som blir mer verdifull etter hvert som et skrivebordsprodukt vokser.
Evernote erfarte kostnaden ved å vedlikeholde separate klienter
Evernote er et av de tydeligste historiske eksemplene på dette problemet.
I årevis vedlikeholdt Evernote ulike applikasjoner for Mac, Windows, mobil og nett. Over tid utviklet disse produktene ulik atferd, forskjeller i gjengivelse, utdaterte forutsetninger og synkroniseringsproblemer.
I 2020 bygget Evernote Windows- og Mac-applikasjonene sine på nytt rundt en felles kodebase. Selskapet sa at det nye fundamentet ville gjøre appene mer stabile, gjøre det mulig å rette feil raskere, levere funksjoner oftere og forbedre synkroniseringen på tvers av plattformer.
Denne overgangen var ikke smertefri, og enkelte mangeårige brukere mislikte at plattformspesifikke funksjoner forsvant i starten. Men grunnen til at Evernote gjennomførte en så kostbar omskriving, er mer interessant enn selve overgangsproblemene.
Når et produkt har en avansert editor, frakoblet lagring, søk, vedlegg, samarbeid, oppgaver, kalendere og kompleks synkronisering, blir det stadig dyrere å vedlikeholde flere uavhengige implementeringer. Feil oppfører seg forskjellig. Gjengivelsen varierer. Synkroniseringslogikken samhandler med ulike lokale arkitekturer. Hver vesentlige produktendring må innføres i flere klienter.
En felles arkitektur får ikke vanskelige problemer til å forsvinne. Den lar selskapet løse flere av dem én gang.
Linux kan være Electrons mest undervurderte fordel
Linux gjør argumentet for Electron enda sterkere.
Det er vanskelig å støtte Linux ordentlig. I motsetning til macOS eller Windows er ikke «Linux på skrivebordet» én strengt kontrollert plattform. Utviklere må håndtere ulike distribusjoner, pakkeformater, skrivebordsmiljøer, grafikkstakker, systembiblioteker og skjermprotokoller.
For mange programvareselskaper ville den rasjonelle forretningsbeslutningen ganske enkelt være å ikke støtte Linux.
Electron endrer det økonomiske regnestykket.
Fordi Electron tilbyr et felles kjøremiljø på tvers av macOS, Windows og Linux, kan det være dramatisk enklere å legge til Linux-støtte enn å vedlikeholde en separat native Linux-implementering. Dette er en av grunnene til at Linux-brukere i dag har tilgang til mange store skrivebordsapplikasjoner som tidligere kanskje aldri ville ha fått en offisiell Linux-klient.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian og mange andre verktøy kan støtte Linux uten å vedlikeholde en helt separat GTK- eller Qt-applikasjon.
Electron tar også hånd om mye av den Linux-spesifikke kompleksiteten på vegne av applikasjonsutviklere. Et godt eksempel er overgangen fra X11 til Wayland. Electrons vedlikeholdere har beskrevet hvordan Chromiums overgang til Wayland i praksis tok Electron-applikasjonene med seg, og dermed reduserte arbeidet hvert applikasjonsteam måtte gjøre på egen hånd med skjermstakken.
Uten rammeverk som Electron ville mange selskaper ikke bygget native Linux-klienter. De ville ganske enkelt støttet macOS og Windows og overlatt Linux-brukerne til en nettleserfane.
Electron har sannsynligvis gjort mer for kommersiell skrivebordsprogramvare på Linux enn det får anerkjennelse for.
Selv Microsoft velger i økende grad webteknologi
Microsoft er kanskje det sterkeste moteksempelet til ideen om at seriøs Windows-programvare alltid bør bruke native Windows-rammeverk for brukergrensesnitt.
Microsoft kontrollerer Windows. De kontrollerer Win32, .NET, WinUI, WebView2 og mye av plattformen utviklere bygger på. Hvis fullt ut native Windows-utvikling alltid var det åpenbare svaret, ville Microsoft vært i den best mulige posisjonen til å bruke det overalt.
Det gjør de ikke.
Visual Studio Code bruker Electron. Teams er fortsatt bygget rundt React, TypeScript og Chromium, selv etter at Microsoft erstattet Electron med en mer optimalisert WebView2-vert. Den nye Outlook for Windows baserer seg også i stor grad på webteknologi, og Microsoft beskriver uttrykkelig denne arkitekturen som en måte å forbedre omstillingsevnen på, muliggjøre raskere levering av funksjoner og skape en mer konsistent opplevelse.
Teams er særlig lærerikt. Microsoft ønsket å forbedre ytelsen og redusere ressursforbruket, så de endret arkitekturen. Men de skrev ikke om brukergrensesnittet til en tradisjonell native Windows-applikasjon.
De beholdt webstakken og optimaliserte rundt den.
Dette skillet er viktig. Microsoft besluttet at de organisatoriske fordelene ved React, TypeScript og Chromium var verdt å bevare, selv mens de jobbet intensivt med å forbedre ytelsen.
Det finnes også en annen lærdom her. Microsoft har selv introdusert mange generasjoner av teknologi for Windows-applikasjoner gjennom årene: Win32, WPF, UWP, WinUI og andre. Et selskap som velger «native Windows», velger ikke nødvendigvis en tidløs plattform. Ofte satser det på én generasjon av Microsofts foretrukne rammeverk.
Webplattformen har, litt ironisk, blitt en av de mer stabile plattformene å utvikle applikasjoner for.
Rekruttering er en del av arkitekturen
Valg av rammeverk avgjør også hvem du kan ansette.
JavaScript- og TypeScript-utviklere utgjør en av de største talentbasene i bransjen. Et selskap som bygger med Electron, kan rekruttere fra denne talentbasen i stedet for å trenge separate team av erfarne macOS-, Windows- og Linux-spesialister.
Spesialister på native utvikling er fortsatt verdifulle. Seriøse skrivebordsprodukter trenger fremdeles utviklere som forstår operativsystemer i dybden. Men Electron endrer hvor mange spesialister du trenger.
I stedet for at det meste av applikasjonen må bygges av plattformeksperter, kan du holde mengden native integrasjonskode relativt liten og la mesteparten av teamet jobbe med det felles produktet.
Dette er enda viktigere når et selskap allerede har en nettapplikasjon. React-komponenter kan noen ganger deles. TypeScript-biblioteker kan gjenbrukes. Produktlogikk kan flyttes mellom nett og skrivebord. Utviklere kan bytte team uten å måtte lære et helt annet økosystem.
Bemanningen blir også mindre sårbar. Hvis den eneste utvikleren med inngående kjennskap til den native Windows-klienten din slutter, kan det være vanskelig å erstatte denne kompetansen. Med Electron bruker en langt større del av kodebasen teknologier som resten av organisasjonen kjenner til.
Et rammeverk avgjør derfor ikke bare hvordan et grensesnitt gjengis. Det påvirker hvordan selve utviklingsorganisasjonen kan struktureres.
Native betyr ikke automatisk bedre programvare
Utviklere bruker ofte «native» nesten som et synonym for «rask».
Det er det ikke.
Native API-er gir utviklere muligheten til å lage en svært effektiv applikasjon. Om sluttproduktet faktisk oppnår dette, avhenger av arkitekturen, teamet, budsjettet og hvor mye optimaliseringsarbeid selskapet har råd til.
En native applikasjon kan fortsatt være treg, full av feil, minnekrevende, inkonsistent eller dårlig vedlikeholdt.
Enda viktigere er det at hvis et begrenset team fordeles på flere native implementeringer, får hver implementering færre utviklingstimer.
Se for deg at et selskap har seks utviklere tilgjengelig for skrivebordsproduktet sitt. Én mulighet er å fordele dem mellom Mac og Windows, og kanskje la Linux stå uten støtte. En annen er å sette nesten alle seks til å jobbe med én felles Electron-applikasjon som betjener alle tre plattformene.
Hvilken tilnærming gir selskapet størst utviklingskapasitet til å forbedre oppstartstiden, rette minnelekkasjer, finpusse interaksjoner, forbedre tilgjengeligheten, redusere krasj og følge opp brukerne?
Det er ikke åpenbart at de native applikasjonene gir det beste produktet.
Dette skaper et interessant paradoks: Et rammeverk som bruker noe mer maskinressurser, kan gjøre det mulig for et selskap å bygge et bedre optimalisert produkt fordi det bruker langt færre utviklingsressurser.
Electron gir deg en kontrollert plattform
Electron har også en annen fordel som er lett å overse: Det leveres med det samme Chromium-kjøremiljøet som applikasjonen ble bygget og testet mot.
Det fjerner en viktig variabel fra utvikling på tvers av plattformer.
Rammeverk basert på operativsystemets webvisningskomponenter kan gi mindre applikasjoner, men avveiningen er at den samme frontenden kan kjøre på WebView2 i Windows, WKWebView på macOS og WebKitGTK på Linux. Disse motorene har ulike muligheter, feil, utgivelsesplaner og måter å gjengi innhold på.
Electron gjør en annen avveining: Pakk kjøremiljøet sammen med applikasjonen og gjør det til en del av den.
Ja, det koster diskplass.
Men det gir utviklere en langt mer konsistent målplattform på tvers av tre svært forskjellige operativsystemer.
Konsistens har enorm verdi i utviklingsarbeidet.
Når Electron ikke er nok, kan du fortsatt bruke native kode
Å velge Electron betyr ikke å gi avkall på tilgang til native funksjonalitet.
Electron-applikasjoner kan bruke native moduler og plattformspesifikk kode der det er nødvendig. Det betyr at det arkitektoniske valget egentlig ikke står mellom:
100 % native eller 100 % JavaScript.
For mange produkter er en bedre modell:
Det meste av applikasjonen er felles, med en liten mengde native kode der operativsystemet faktisk krever det.
Native kode blir en utvei snarere enn fundamentet for hele produktet.
For mange selskaper er dette en langt bedre fordeling av utviklingsinnsatsen.
Brukere bryr seg om produkter, ikke rammeverk
Det finnes en liten gruppe teknisk kyndige brukere som åpner Aktivitetsmonitor, legger merke til flere Chromium-prosesser og umiddelbart klager over at en applikasjon bruker Electron.
De fleste brukere gjør ikke det.
De bryr seg ikke om at Slack bruker Electron. De bryr seg ikke om at VS Code er bygget med webteknologier. De vet ikke hvilket rammeverk Claude bruker. De bryr seg om hvorvidt programvaren hjelper dem med å få jobben gjort.
Hvis en applikasjon starter raskt nok, føles responsiv, sjelden krasjer og løser brukerens problem, er implementeringsteknologien i stor grad usynlig.
Det motsatte er like sant. En native applikasjon blir ikke automatisk et godt produkt fordi den bruker Swift eller WinUI.
Programvare konkurrerer på produktnivå, ikke på rammeverksnivå.
Optimaliser selskapet, ikke bare binærfilen
Electron har reelle kostnader. Det bruker mer diskplass. Det grunnleggende minneforbruket er vanligvis høyere enn i en liten native applikasjon. Det finnes absolutt produkter der disse kostnadene gjør Electron til feil valg.
Et lite verktøy i menylinjen trenger sannsynligvis ikke Chromium. En enhetsdriver gjør det definitivt ikke. Spill, profesjonell lydprogramvare og applikasjoner som er ekstremt følsomme for forsinkelse, har andre krav. Og hvis produktet ditt bare skal kjøre på ett operativsystem, blir native utvikling mye enklere å begrunne.
Men en svært stor andel av moderne skrivebordsprogramvare faller ikke i disse kategoriene.
Den består av komplekse grensesnitt koblet til skytjenester. Den må kjøre på Windows og macOS, og brukerne forventer i økende grad også Linux-støtte. Den må utvikle seg kontinuerlig. Den konkurrerer med produkter som leverer endringer hver uke. Og den bygges vanligvis av et selskap med et begrenset antall utviklere.
For disse produktene er utviklerproduktivitet en del av applikasjonens ytelse.
Electron lar et selskap rekruttere fra en langt større talentbase, dele utviklere mellom nett og skrivebord, vedlikeholde én hovedapplikasjon i stedet for flere, gjenbruke JavaScript-økosystemet, levere funksjoner mer konsistent på tvers av operativsystemer, støtte Linux til en kostnad som ellers ofte ville vært vanskelig å forsvare, og bruke mer utviklingstid på å forbedre produktet i stedet for å vedlikeholde parallelle implementeringer.
Du kan enkelt måle kostnaden ved Electron i megabyte.
Kostnadene ved alternativet er vanskeligere å se. De viser seg som flere utviklere, dupliserte implementeringer, lengre utgivelsessykluser, plattformspesifikke feil, rekrutteringsvansker, organisatoriske siloer, Linux-brukere uten støtte og funksjoner som bruker flere måneder ekstra på å nå alle.
Disse kostnadene vises ikke i Aktivitetsmonitor.
Men for selskapet som bygger programvaren, kan de være betydelig større.
Målet med programvareutvikling er ikke å produsere den minste binærfilen.
Det er å bygge det beste produktet organisasjonen din kan levere, vedlikeholde og forbedre kontinuerlig.
For en overraskende stor gruppe skrivebordsapplikasjoner er Electron fortsatt en av de mest effektive måtene å gjøre nettopp det på.