Als je genoeg tijd doorbrengt op Hacker News of Reddit, kom je uiteindelijk steeds dezelfde kritiek tegen: Electron is log, Electron gebruikt te veel geheugen en serieuze desktopapplicaties zouden native moeten zijn.
Er zit een kern van waarheid in die kritiek. Electron-applicaties hebben doorgaans een groter basisverbruik omdat ze Chromium en Node.js meeleveren. Een zorgvuldig ontwikkelde native applicatie kan minder geheugen gebruiken, sneller starten en nauwer integreren met het besturingssysteem.
Maar dit debat richt zich te veel op de computer en te weinig op het bedrijf dat de software bouwt.
Voor de meeste gebruikers doet de technologie achter een applicatie er nauwelijks toe. Ze vinden het belangrijk dat de applicatie werkt, vlot reageert, dat bugs worden opgelost en dat er steeds nuttige functies bijkomen. Voor een softwarebedrijf is een van de belangrijkste eigenschappen van een technologiestack daarom iets wat zelden in benchmarktabellen voorkomt: hoe snel kan het team het product bouwen, uitbrengen, ervan leren en verbeteren?
Voor veel moderne desktopapplicaties is Electron daar uitzonderlijk goed in.
Ontwikkeltijd is het schaarse middel
In het ideale plaatje heeft een bedrijf dat native desktopsoftware maakt een uitstekend macOS-team, een ander team dat de Windows-applicatie bouwt en misschien nog een team dat Linux ondersteunt. Elke applicatie is zorgvuldig geoptimaliseerd voor het platform en elke ontwikkelaar kent het besturingssysteem waarop die werkt door en door.
De meeste bedrijven hebben die luxe niet.
Een desktopproduct heeft misschien vijf ontwikkelaars. Misschien zijn het er twee. Diezelfde ontwikkelaars moeten functies bouwen, bugs oplossen, de prestaties verbeteren, klanten te woord staan, infrastructuur onderhouden, omgaan met wijzigingen in besturingssystemen en het product verder ontwikkelen.
Native ontwikkeling maakt dit lastiger, omdat macOS, Windows en Linux daadwerkelijk verschillende platforms zijn. Ze hebben verschillende UI-frameworks, API's, machtigingssystemen, gedrag tijdens de levenscyclus van applicaties, installatieprogramma's, updatemechanismen, meldingssystemen, vensterbeheer, toegankelijkheids-API's en een jarenlange opeenstapeling van platformspecifieke eigenaardigheden.
Electron verandert die afweging. Het combineert Chromium, Node.js en desktop-API's tot een gedeeld applicatiemodel voor macOS, Windows en Linux. Dezelfde TypeScript-ontwikkelaar kan vaak een functie bouwen van interface tot applicatielogica en die op elk desktopplatform uitbrengen. Native code blijft beschikbaar wanneer die echt nodig is, maar wordt de uitzondering in plaats van de basis van het product. Electron zelf beschrijft dit als een van zijn belangrijkste voordelen: één JavaScript-codebase voor alle drie de grote desktopplatforms.
Dat verschil telt in de loop der jaren steeds zwaarder mee. Als elke wezenlijke functie afzonderlijke implementaties voor Mac en Windows vereist, betaalt het bedrijf die extra platformkosten telkens opnieuw: bij elke functie, elk herontwerp, elk experiment, elke bugfix, elke verbetering van de toegankelijkheid en elke prestatieoptimalisatie.
Met Electron hoeft veel van dat werk maar één keer te gebeuren.
Electron optimaliseert voor snelle iteratie
Producten worden zelden geweldig doordat de eerste implementatie perfect was. Ze worden geweldig door iteratie.
Een team brengt iets uit. Klanten gebruiken het. Het team leert ervan. Het past de functie aan. Meer mensen gebruiken die. Een ander probleem wordt zichtbaar. Het team verbetert de functie opnieuw.
Hoe korter de cyclus tussen idee, implementatie, feedback en verbetering, hoe sneller een product beter wordt.
Electron is uitzonderlijk goed in het verkorten van die cyclus, omdat het is gebouwd rond technologieën die softwarebedrijven overal al gebruiken: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js en npm.
Dat betekent dat bedrijven veel meer kunnen delen dan broncode. Ze kunnen ontwikkelaars, UI-componenten, ontwikkeltools, bibliotheken, infrastructuur, testmethoden en interne kennis delen tussen hun web- en desktopproducten.
Een frontendontwikkelaar kan niet opeens niets meer bijdragen omdat het bedrijf hulp nodig heeft met de Windows-client. Een desktopontwikkelaar kan bijdragen aan de webapplicatie. Een full-stack TypeScript-ontwikkelaar kan tussen producten wisselen wanneer de prioriteiten veranderen.
Voor een klein of middelgroot bedrijf kan die flexibiliteit veel meer waard zijn dan een besparing van 100 MB RAM.
Kijk wie Electron daadwerkelijk gebruikt
Electron wordt soms omschreven als een gemakkelijke uitweg voor bedrijven die niet willen investeren in een ‘echte’ desktopapplicatie. De producten die ermee worden gebouwd, maken dat argument steeds moeilijker vol te houden.
Het Electron-project zelf noemt producten als Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom en Canva. Dat zijn geen eenvoudige hulpprogramma's. Veel ervan behoren tot de meest geavanceerde en meest gebruikte productiviteitsapplicaties ter wereld.
Visual Studio Code is een bijzonder bruikbaar voorbeeld. Microsoft zou zijn toonaangevende code-editor kunnen bouwen met vrijwel elke Windows-technologie die het maar wil, maar toch gebruikt VS Code Electron op Windows, macOS en Linux. De applicatie omvat terminals, debugging, taalservers, Git-integratie, ontwikkeling op afstand, notebooks, extensies en sterk aangepaste editors.
De interessante vraag is niet of Microsoft geheugen zou kunnen besparen door drie afzonderlijke native versies te bouwen. Natuurlijk zou dat kunnen.
De betere vraag is of VS Code zich net zo snel zou hebben ontwikkeld, net zo consistent zou zijn gebleven op verschillende platforms en zo'n groot ecosysteem zou hebben opgebouwd als elke belangrijke functionaliteit meerdere afzonderlijke implementaties vereiste.
ChatGPT en Claude laten het verschil in aanpak zien
Ook het contrast tussen ChatGPT en Claude is verhelderend.
OpenAI bouwde aanvankelijk een speciaal ontwikkelde native macOS-applicatie voor ChatGPT. Anthropic bouwde Claude Desktop daarentegen op Electron en had vanaf het begin een gedeelde desktopbasis voor meerdere platforms.
Dat verschil werd belangrijker naarmate de producten uitgebreider werden. Claude Desktop kon mogelijkheden zoals MCP-integraties, extensies en Claude Code blijven toevoegen aan dezelfde platformoverschrijdende applicatie. Anthropic ondersteunt Claude Code nu rechtstreeks binnen zijn desktopomgeving, inclusief meerdere lokale sessies en sessies op afstand.
OpenAI koos later voor zijn nieuwe platformoverschrijdende desktopaanpak eveneens de richting van Electron, en Electron noemt nu zowel ChatGPT als Claude als prominente Electron-applicaties.
Het zou te ver gaan om te beweren dat Electron alleen het verschil in ontwikkeltempo verklaart. Teamgrootte, prioriteiten, productstrategie en interne organisatie spelen allemaal een rol. Maar het architectuurvoordeel is duidelijk: een gedeelde, platformoverschrijdende basis maakt het eenvoudiger om functies op verschillende besturingssystemen uit te brengen zonder afzonderlijke implementaties te onderhouden.
Dat is precies het soort voordeel dat waardevoller wordt naarmate een desktopproduct groeit.
Evernote ondervond de kosten van het onderhouden van afzonderlijke clients
Evernote is een van de duidelijkste historische voorbeelden van dit probleem.
Jarenlang onderhield Evernote verschillende applicaties voor Mac, Windows, mobiele apparaten en het web. In de loop van de tijd ontstonden er tussen die producten verschillen in gedrag en weergave, naast verouderde uitgangspunten en synchronisatieproblemen.
In 2020 bouwde Evernote zijn Windows- en Mac-applicaties opnieuw op rond een gedeelde codebase. Het bedrijf stelde dat de nieuwe basis de apps stabieler zou maken, bugs sneller zou laten oplossen, frequentere releases van functies mogelijk zou maken en de synchronisatie tussen platforms zou verbeteren.
Die migratie verliep niet zonder problemen, en sommige trouwe gebruikers waren ontevreden over het aanvankelijke verlies van platformspecifieke functies. Maar de reden waarom Evernote zo'n kostbare herschrijving ondernam, is interessanter dan de migratieproblemen zelf.
Zodra een product een uitgebreide editor, offline opslag, een zoekfunctie, bijlagen, samenwerking, taken, agenda's en complexe synchronisatie heeft, wordt het onderhouden van meerdere onafhankelijke implementaties steeds duurder. Bugs gedragen zich anders. De weergave verschilt. Synchronisatielogica werkt samen met verschillende lokale architecturen. Elke wezenlijke productwijziging moet in meerdere clients worden doorgevoerd.
Een gedeelde architectuur laat moeilijke problemen niet verdwijnen. Ze stelt het bedrijf in staat om meer van die problemen slechts één keer op te lossen.
Linux is misschien wel het meest onderschatte voordeel van Electron
Linux maakt de argumenten voor Electron nog sterker.
Linux goed ondersteunen is moeilijk. Anders dan macOS of Windows is ‘de Linux-desktop’ niet één strak beheerd platform. Ontwikkelaars moeten rekening houden met verschillende distributies, pakketformaten, desktopomgevingen, grafische stacks, systeembibliotheken en weergaveprotocollen.
Voor veel softwarebedrijven zou de rationele zakelijke beslissing simpelweg zijn om Linux niet te ondersteunen.
Electron verandert die economische afweging.
Omdat Electron een gemeenschappelijke runtime biedt voor macOS, Windows en Linux, kan het toevoegen van Linux-ondersteuning aanzienlijk eenvoudiger zijn dan het onderhouden van een afzonderlijke native Linux-implementatie. Dat is een van de redenen waarom Linux-gebruikers tegenwoordig toegang hebben tot veel grote desktopapplicaties waarvoor vroeger misschien nooit een officiële Linux-client zou zijn verschenen.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian en veel andere tools kunnen Linux ondersteunen zonder een volledig afzonderlijke GTK- of Qt-applicatie te onderhouden.
Electron neemt applicatieontwikkelaars bovendien veel Linux-specifieke complexiteit uit handen. Een goed voorbeeld is de overstap van X11 naar Wayland. De beheerders van Electron hebben beschreven hoe de overgang van Chromium naar Wayland Electron-applicaties feitelijk meenam, waardoor elk applicatieteam minder werk aan de weergavestack zelfstandig hoefde te verrichten.
Zonder frameworks zoals Electron zouden veel bedrijven geen native Linux-clients bouwen. Ze zouden simpelweg macOS en Windows ondersteunen en Linux-gebruikers met een browsertabblad laten zitten.
Electron heeft waarschijnlijk meer voor commerciële Linux-desktopsoftware gedaan dan doorgaans wordt erkend.
Zelfs Microsoft kiest steeds vaker voor webtechnologie
Microsoft is misschien wel het sterkste tegenvoorbeeld voor het idee dat serieuze Windows-software altijd native Windows-UI-frameworks zou moeten gebruiken.
Microsoft beheert Windows. Het beheert Win32, .NET, WinUI, WebView2 en een groot deel van het platform waarop ontwikkelaars bouwen. Als volledig native Windows-ontwikkeling altijd de voor de hand liggende keuze was, zou Microsoft in de best mogelijke positie verkeren om die overal toe te passen.
Dat doet het niet.
Visual Studio Code gebruikt Electron. Teams is nog steeds gebouwd rond React, TypeScript en Chromium, zelfs nadat Microsoft Electron verving door een beter geoptimaliseerde WebView2-host. Ook het nieuwe Outlook voor Windows leunt sterk op webtechnologie, en Microsoft beschrijft die architectuur expliciet als een manier om wendbaarder te worden, functies sneller uit te brengen en een consistentere ervaring te creëren.
Vooral Teams is een leerzaam voorbeeld. Microsoft wilde de prestaties verbeteren en het resourcegebruik verminderen, en veranderde daarom de architectuur. Maar het herschreef de UI niet als een traditionele native Windows-applicatie.
Het behield de webstack en optimaliseerde de architectuur daaromheen.
Dat onderscheid is belangrijk. Microsoft besloot dat de organisatorische voordelen van React, TypeScript en Chromium het waard waren om te behouden, zelfs terwijl het de prestaties ingrijpend verbeterde.
Er valt hier nog iets te leren. Microsoft heeft door de jaren heen zelf vele generaties Windows-applicatietechnologie geïntroduceerd: Win32, WPF, UWP, WinUI en andere. Een bedrijf dat voor ‘native Windows’ kiest, kiest niet noodzakelijk voor een tijdloos platform. Vaak zet het in op één generatie van het framework waaraan Microsoft op dat moment de voorkeur geeft.
Het webplatform is, enigszins ironisch, een van de stabielere platforms geworden om applicaties voor te bouwen.
Personeelswerving is onderdeel van de architectuur
Frameworkkeuzes bepalen ook wie je kunt aannemen.
JavaScript- en TypeScript-ontwikkelaars vormen een van de grootste groepen technisch talent in de sector. Een bedrijf dat met Electron bouwt, kan uit die groep werven in plaats van afzonderlijke teams met ervaren macOS-, Windows- en Linux-specialisten nodig te hebben.
Native specialisten blijven waardevol. Serieuze desktopproducten hebben nog steeds ontwikkelaars nodig die besturingssystemen door en door begrijpen. Maar Electron verandert hoeveel specialisten je nodig hebt.
In plaats van het grootste deel van de applicatie door platformexperts te laten bouwen, kun je een relatief kleine hoeveelheid code voor native integratie behouden en het merendeel van het team aan het gedeelde product laten werken.
Dit is nog belangrijker wanneer een bedrijf al een webapplicatie heeft. React-componenten kunnen soms worden gedeeld. TypeScript-bibliotheken kunnen worden hergebruikt. Productlogica kan tussen web en desktop worden uitgewisseld. Ontwikkelaars kunnen van team wisselen zonder een volledig ander ecosysteem te hoeven leren kennen.
Ook wordt de personeelsbezetting minder kwetsbaar. Als de enige ontwikkelaar die je native Windows-client door en door begrijpt vertrekt, kan het lastig zijn om die expertise te vervangen. Met Electron gebruikt een veel groter deel van de codebase technologieën die de rest van de organisatie al kent.
Een framework bepaalt dus niet alleen hoe een interface wordt weergegeven. Het beïnvloedt ook hoe de ontwikkelorganisatie zelf kan worden ingericht.
Native betekent niet automatisch betere software
Ontwikkelaars gebruiken ‘native’ vaak bijna als synoniem voor ‘snel’.
Dat is het niet.
Native API's bieden ontwikkelaars de mogelijkheid om een zeer efficiënte applicatie te maken. Of het uiteindelijke product dat daadwerkelijk waarmaakt, hangt af van de architectuur, het team, het budget en de hoeveelheid optimalisatiewerk die het bedrijf zich kan veroorloven.
Een native applicatie kan nog steeds traag zijn, vol bugs zitten, veel geheugen gebruiken, inconsistent zijn of slecht worden onderhouden.
Belangrijker nog: als je een beperkt team verdeelt over meerdere native implementaties, krijgt elke implementatie minder ontwikkeluren.
Stel dat een bedrijf zes ontwikkelaars beschikbaar heeft voor zijn desktopproduct. Eén optie is om ze te verdelen over Mac en Windows, waarbij Linux mogelijk niet wordt ondersteund. Een andere optie is om vrijwel alle zes ontwikkelaars aan één gedeelde Electron-applicatie te laten werken die alle drie de platforms bedient.
Welke aanpak geeft het bedrijf meer ontwikkelcapaciteit om de opstarttijd te verbeteren, geheugenlekken op te lossen, interacties te verfijnen, de toegankelijkheid te verbeteren, crashes te verminderen en op gebruikers te reageren?
Het is niet vanzelfsprekend dat de native applicaties het betere product opleveren.
Dat creëert een interessante paradox: een framework dat wat meer computerresources verbruikt, kan een bedrijf in staat stellen een beter geoptimaliseerd product te bouwen, omdat het veel minder ontwikkelcapaciteit vergt.
Electron geeft je een beheerst platform
Electron heeft nog een ander voordeel dat gemakkelijk over het hoofd wordt gezien: het levert de Chromium-runtime mee waarvoor de applicatie is gebouwd en waarmee die is getest.
Dat neemt een belangrijke variabele weg uit platformoverschrijdende ontwikkeling.
Frameworks die zijn gebaseerd op de webviews van besturingssystemen kunnen kleinere applicaties opleveren, maar daar staat tegenover dat dezelfde frontend op WebView2 in Windows, WKWebView in macOS en WebKitGTK in Linux kan draaien. Die engines hebben verschillende mogelijkheden, bugs, releaseschema's en weergavegedrag.
Electron maakt een andere afweging: bundel de runtime en maak die onderdeel van de applicatie.
Ja, dat kost schijfruimte.
Maar het geeft ontwikkelaars een veel consistentere basis voor drie zeer verschillende besturingssystemen.
Consistentie heeft enorme waarde bij softwareontwikkeling.
Wanneer Electron niet genoeg is, kun je nog steeds native code gebruiken
Kiezen voor Electron betekent niet dat je de toegang tot native mogelijkheden opgeeft.
Electron-applicaties kunnen waar nodig native modules en platformspecifieke code gebruiken. Dat betekent dat de architectuurkeuze niet echt neerkomt op:
100% native of 100% JavaScript.
Voor veel producten is een beter model:
het grootste deel van de applicatie gedeeld, met een kleine hoeveelheid native code waar het besturingssysteem die echt vereist.
Native code wordt een uitweg voor bijzondere gevallen in plaats van de basis van het hele product.
Voor veel bedrijven is dat een veel betere inzet van ontwikkelinspanningen.
Gebruikers geven om producten, niet om frameworks
Er is een kleine groep technisch onderlegde gebruikers die Activiteitenweergave openen, meerdere Chromium-processen opmerken en meteen klagen dat een applicatie Electron gebruikt.
De meeste gebruikers doen dat niet.
Het maakt ze niet uit dat Slack Electron gebruikt. Het maakt ze niet uit dat VS Code met webtechnologieën is gebouwd. Ze weten niet welk framework Claude gebruikt. Ze vinden het belangrijk of de software hen helpt hun werk te doen.
Als een applicatie snel genoeg start, vlot reageert, zelden crasht en het probleem van de gebruiker oplost, is de gebruikte implementatietechnologie grotendeels onzichtbaar.
Het omgekeerde is net zo goed waar. Een native applicatie wordt niet automatisch een goed product omdat die Swift of WinUI gebruikt.
Software concurreert op productniveau, niet op frameworkniveau.
Optimaliseer het bedrijf, niet alleen het uitvoerbare bestand
Electron heeft echte nadelen. Het gebruikt meer schijfruimte. Het basisgeheugenverbruik ligt doorgaans hoger dan dat van een kleine native applicatie. Er zijn absoluut producten waarvoor die nadelen Electron tot de verkeerde keuze maken.
Een klein menubalkhulpprogramma heeft waarschijnlijk geen Chromium nodig. Een apparaatstuurprogramma zeker niet. Games, professionele audiosoftware en applicaties die extreem gevoelig zijn voor vertraging hebben andere vereisten. En als je product altijd maar op één besturingssysteem zal draaien, wordt native ontwikkeling veel eenvoudiger te rechtvaardigen.
Maar een enorm deel van de moderne desktopsoftware valt niet in die categorieën.
Het bestaat uit complexe interfaces die met clouddiensten zijn verbonden. Het moet op Windows en macOS draaien, en gebruikers verwachten steeds vaker ook Linux-ondersteuning. Het moet voortdurend evolueren. Het concurreert met producten die elke week wijzigingen uitbrengen. En het wordt doorgaans gebouwd door een bedrijf met een beperkt aantal ontwikkelaars.
Voor die producten maakt de productiviteit van ontwikkelaars deel uit van de applicatieprestaties.
Electron stelt een bedrijf in staat om uit een veel grotere groep talent te werven, ontwikkelaars te delen tussen web en desktop, één hoofdapplicatie te onderhouden in plaats van meerdere, het JavaScript-ecosysteem te hergebruiken, functies consistenter op verschillende besturingssystemen uit te brengen, Linux te ondersteunen tegen kosten die anders vaak moeilijk te rechtvaardigen zouden zijn, en meer ontwikkeltijd te besteden aan het verbeteren van het product in plaats van het onderhouden van parallelle implementaties.
Je kunt de kosten van Electron gemakkelijk in megabytes meten.
De kosten van de alternatieven zijn moeilijker te zien. Ze komen tot uiting in extra ontwikkelaars, dubbel uitgevoerde implementaties, langere releasecycli, platformspecifieke bugs, problemen bij de personeelswerving, organisatorische silo's, Linux-gebruikers die niet worden ondersteund en functies die iedereen pas maanden later bereiken.
Die kosten verschijnen niet in Activiteitenweergave.
Maar voor het bedrijf dat de software bouwt, kunnen ze aanzienlijk hoger zijn.
Het doel van softwareontwikkeling is niet om het kleinste uitvoerbare bestand te produceren.
Het is om het beste product te bouwen dat je organisatie kan uitbrengen, onderhouden en voortdurend verbeteren.
Voor een verrassend grote categorie desktopapplicaties blijft Electron een van de efficiëntste manieren om precies dat te doen.