Electron en NW.js zijn twee gevestigde frameworks voor het bouwen van platformonafhankelijke desktopapplicaties met webtechnologieën. Beide combineren Chromium en Node.js, waardoor ontwikkelaars applicaties kunnen maken met HTML, CSS, JavaScript en vertrouwde frontendframeworks zoals React, Vue en Angular.
NW.js is eigenlijk het oudste framework. Het project, dat oorspronkelijk node-webkit heette, ging in 2011 van start en was in 2012 publiek beschikbaar. Electron volgde in 2013 en werd aanvankelijk door GitHub ontwikkeld voor de code-editor Atom. Hoewel Electron later verscheen, werd het uiteindelijk het meest gebruikte framework voor gangbare desktopapplicaties.
Tegenwoordig vormt Electron de basis voor grote applicaties zoals Visual Studio Code, Slack, Discord, Notion en Figma. Het profiteert ook van de betrokkenheid van grote technologiebedrijven en het beheer door de OpenJS Foundation. Bij WebCatalog hebben we gekozen voor Electron als basis voor onze platformonafhankelijke desktopapplicaties.
NW.js is daarentegen veel minder zichtbaar bij grote productiviteits- en bedrijfsapplicaties. Het voortdurende gebruik ervan is vooral duidelijk in de gamesector, waaronder indiegames en titels die met RPG Maker zijn gemaakt.
Hoe verhouden de twee frameworks zich tot elkaar, en welk framework kunnen ontwikkelaars het beste kiezen?
Electron versus NW.js in één oogopslag
Met beide frameworks kunnen ontwikkelaars desktopapplicaties bouwen met webtechnologieën, maar ze benaderen applicatiearchitectuur, native integratie en beveiliging op verschillende manieren.
| Kenmerk | Electron | NW.js |
|---|---|---|
| Voor het eerst geïntroduceerd | 2013 | 2011–2012 |
| Oorspronkelijke ontwikkelaar | GitHub | Intel Open Source Technology Center |
| Beheer en ecosysteem | OpenJS Foundation, met grote bedrijven als bijdragers | Onderhouden door de community, met oorsprong bij Intel |
| Browserengine | Chromium | Chromium |
| JavaScript-runtime | Node.js | Node.js |
| Desktopplatforms | macOS, Windows, Linux | macOS, Windows, Linux |
| Architectuur | Hoofd- en rendererprocessen | Chromium-architectuur met directe Node.js-integratie |
| Toegang tot Node.js | Hoofdproces en gecontroleerde integratie in rendererprocessen | Directe toegang vanuit daarvoor toegestane applicatiepagina's |
| Applicatiegrootte | Relatief groot | Relatief groot |
| Prestaties | Afhankelijk van de applicatie | Afhankelijk van de applicatie |
| Beveiliging | Sandboxing, contextisolatie, IPC | Configureerbare Node-toegang en frame-isolatie |
| Gebruik | Veelgebruikt in gangbare desktopapplicaties | Kleiner ecosysteem, opvallend gebruik in games |
| Ondersteuning voor mobiele apparaten | Geen officiële ondersteuning | Geen officiële ondersteuning |
De belangrijkste verschillen zitten niet in de prestaties of de applicatiegrootte. Beide frameworks bundelen Chromium en Node.js, waardoor hun resourcevereisten grotendeels vergelijkbaar zijn. De grootste verschillen betreffen juist de architectuur, beveiligingsgrenzen, ontwikkeltools en ondersteuning vanuit het ecosysteem.
Geschiedenis: NW.js kwam eerst, maar Electron werd populairder
NW.js was een van de eerste projecten die aantoonden dat ontwikkelaars Node.js konden combineren met browsertechnologieën om desktopapplicaties te maken. Het project heette oorspronkelijk node-webkit en kwam voort uit Intels Open Source Technology Center. De ontwikkeling begon in 2011 en in 2012 verschenen de eerste openbare releases.
Het centrale idee was eenvoudig: JavaScript dat in een browserachtige omgeving draait rechtstreeks toegang geven tot Node.js-modules. Hierdoor werd het mogelijk om desktopapplicaties te ontwikkelen met vertrouwde webtechnologieën, zonder een traditionele native interface te bouwen.
Electron verscheen in 2013 onder de naam Atom Shell. GitHub ontwikkelde het als basis voor zijn code-editor Atom, waarvan in 2014 een openbare bètaversie verscheen. Electron was ontworpen als alternatief voor de toen beschikbare webgebaseerde desktopframeworks, waaronder node-webkit en Chromium Embedded Framework.
Hoewel beide frameworks als doel hadden desktopontwikkeling toegankelijk te maken voor webontwikkelaars, koos Electron voor een andere architectuur die functionaliteit op applicatieniveau scheidde van webcontent. Deze aanpak werd steeds aantrekkelijker naarmate ontwikkelaars complexere applicaties begonnen te bouwen.
Electron werd vervolgens in gebruik genomen door startups en grote technologiebedrijven. GitHub, Slack, Microsoft en andere organisaties droegen bij aan de ontwikkeling en het ecosysteem. In 2019 sloot Electron zich aan bij de OpenJS Foundation en ging het over van eigendom van GitHub naar een neutrale opensourcestichting.
Tegenwoordig werkt Electron met een gevestigd bestuursmodel met werkgroepen voor onder meer beveiliging, releases, API's en upgrades van Chromium en Node.js. Engineers die verbonden zijn aan organisaties zoals Microsoft en Slack hebben deelgenomen aan het onderhoud en het bestuur ervan.
NW.js heeft ook een zakelijke oorsprong, aangezien het bij Intel is ontwikkeld. Het huidige ecosysteem is echter kleiner en kent niet dezelfde brede, zichtbare betrokkenheid van grote desktopsoftwarebedrijven.
Deze geschiedenis illustreert een belangrijk onderscheid: als eerste komen, garandeert geen dominantie op de lange termijn. NW.js hielp het concept van desktopapplicaties bouwen met Chromium en Node.js op de kaart te zetten, maar Electron trok een breder ecosysteem van ontwikkelaars, beheerders en commerciële gebruikers aan.
Zie voor meer achtergrondinformatie Electrons terugblik op tien jaar, de toetreding van Electron tot de OpenJS Foundation en de geschiedenis van het node-webkit-project.
Architectuur: hoofdprocessen versus directe Node.js-integratie
Electron gebruikt een architectuur met meerdere processen die is overgenomen van Chromium. Elke Electron-applicatie heeft een hoofdproces dat verantwoordelijk is voor het beheer van vensters, gebeurtenissen in de applicatielevenscyclus, integraties met het besturingssysteem en functionaliteit met verhoogde rechten. Webcontent draait in afzonderlijke rendererprocessen, die via interprocescommunicatie (IPC) met het hoofdproces communiceren.
Hierdoor ontstaat een onderscheid tussen applicatielogica en code voor de gebruikersinterface. Een rendererproces gedraagt zich doorgaans als een conventionele browseromgeving, terwijl het hoofdproces bewerkingen afhandelt waarvoor toegang tot Node.js of native API's nodig is. Electron biedt ook preloadscripts en de contextBridge-API, waarmee ontwikkelaars geselecteerde functionaliteit beschikbaar kunnen stellen aan het rendererproces zonder onbeperkte toegang tot Node.js te verlenen.
NW.js kiest een andere aanpak. Het is ontworpen om Node.js-functionaliteit rechtstreeks beschikbaar te maken binnen webapplicaties. Op een daarvoor toegestane applicatiepagina kunnen ontwikkelaars via vertrouwde JavaScript-API's toegang krijgen tot Node.js-modules, zonder voor elke bewerking een afzonderlijke IPC-interface op te zetten.
Een lokaal verpakte NW.js-applicatie kan Node.js bijvoorbeeld rechtstreeks gebruiken vanuit een script dat op de pagina draait:
const fs = require('node:fs');
const content = fs.readFileSync('notes.txt', 'utf8');
document.body.textContent = content;
Deze eenvoud is een van de kenmerkende voordelen van NW.js. Ontwikkelaars kunnen browser-API's en Node.js-functionaliteit combineren zonder hun code noodzakelijkerwijs op te splitsen in afzonderlijke applicatielagen. NW.js ondersteunt ook afzonderlijke JavaScript-contexten en een modus met gemengde contexten, wat flexibiliteit biedt in de manier waarop browser- en Node.js-functionaliteit samenwerken.
Electron stimuleert doorgaans een explicietere scheiding. Om vanuit het rendererproces een bestand te lezen, zou een typische, veilig ingerichte Electron-applicatie een beperkte bewerking beschikbaar stellen via een preloadscript en de toegang tot het bestandssysteem in het hoofdproces afhandelen.
Die aanpak vereist extra code, maar maakt de grens tussen applicatiefunctionaliteit met verhoogde rechten en webcontent duidelijker. Bij complexe applicaties kan deze scheiding de onderhoudbaarheid verbeteren en beveiligingsverantwoordelijkheden inzichtelijker maken.
Geen van beide architecturen is in alle gevallen beter. NW.js kan eenvoudiger aanvoelen voor kleinere applicaties of projecten die baat hebben bij directe Node.js-integratie. Electron biedt een structuur die bijzonder nuttig kan zijn naarmate een applicatie complexer wordt.
Prestaties, geheugengebruik en applicatiegrootte
Omdat zowel Electron als NW.js Chromium en Node.js bundelen, heeft geen van beide frameworks een inherent architectonisch voordeel dat vergelijkbaar is met het verschil in omvang tussen Electron en Tauri.
Zelfs een eenvoudige applicatie die met een van beide frameworks is gebouwd, moet een omvangrijke runtime meeleveren. Beide frameworks kunnen ook meerdere Chromium-processen aanmaken, wat het geheugengebruik verhoogt, maar helpt om werklasten te isoleren en de responsiviteit te verbeteren.
De directe integratie tussen Node.js en de browseromgeving in NW.js kan bij bepaalde bewerkingen de behoefte aan IPC verminderen. Afhankelijk van de contextconfiguratie kan JavaScript-code rechtstreeks met Node.js-functionaliteit werken, wat sommige bewerkingen eenvoudiger maakt en mogelijk de communicatieoverhead vermindert.
Electron scheidt bewerkingen met verhoogde rechten van renderercode, waardoor IPC nodig is wanneer procesgrenzen worden overschreden. Dit betekent echter niet dat Electron inherent trager is. De extra overhead kan bij gewone interacties met de gebruikersinterface verwaarloosbaar zijn, en de scheiding kan helpen om zware backendtaken buiten het rendererproces te houden.
In de praktijk hangen applicatieprestaties sterk af van de manier waarop ontwikkelaars Chromium gebruiken, achtergrondprocessen beheren, rendering implementeren en de applicatiestatus afhandelen.
Voor zinvolle vergelijkingen moeten ontwikkelaars het volgende beoordelen:
- Opstarttijd: Hoe snel de applicatie interactief wordt.
- Geheugengebruik: Zowel het verbruik in rust als het geheugengebruik bij realistische werklasten.
- CPU-gebruik: Resourceverbruik tijdens rendering en achtergrondbewerkingen.
- Applicatiegrootte: Downloadgrootte en benodigde opslagruimte na installatie.
- Responsiviteit: Hoe goed de interface reageert tijdens resource-intensieve taken.
Geen van beide frameworks mag zonder metingen aan een representatieve applicatie als categorisch sneller worden beschouwd. Verschillen in Chromium-versies, buildconfiguraties, native modules en applicatiearchitectuur kunnen allemaal van invloed zijn op benchmarkresultaten.
Voor ontwikkelaars die vooral de applicatiegrootte willen verkleinen, zal een overstap van Electron naar NW.js waarschijnlijk niet de ingrijpende besparingen opleveren die gepaard gaan met een overstap naar een framework dat de webview van het besturingssysteem gebruikt.
Beveiliging: verschillende benaderingen van native toegang
Beveiliging is een van de belangrijkste verschillen tussen Electron en NW.js, vooral bij applicaties die externe websites of andere niet-vertrouwde content weergeven.
Electron biedt verschillende beveiligingsmechanismen, waaronder Chromium-sandboxing, contextisolatie en de mogelijkheid om Node.js-integratie in rendererprocessen uit te schakelen. Moderne Electron-versies schakelen belangrijke beschermingsmaatregelen standaard in, en de beveiligingsdocumentatie van het project raadt sterk aan om native API's met verhoogde rechten gescheiden te houden van externe content.
NW.js biedt directere toegang tot Node.js vanuit daarvoor toegestane applicatiepagina's. Dat kan de ontwikkeling vereenvoudigen, maar vereist ook een zorgvuldige afweging van welke content die rechten krijgt.
NW.js maakt onderscheid tussen normale frames en frames waarin Node is ingeschakeld. Het ondersteunt ook instellingen zoals node-remote om te bepalen welke externe URL's toegang krijgen tot Node.js-functionaliteit. De webviewcomponent kan gastcontent in een afzonderlijk proces weergeven zonder die automatisch de rechten van de applicatie te geven.
| Beveiligingsaspect | Electron | NW.js |
|---|---|---|
| Node.js-toegang met verhoogde rechten | Voornamelijk via het hoofdproces en gecontroleerde bruggen | Rechtstreeks beschikbaar in daarvoor toegestane applicatiecontexten |
| Isolatie van externe content | Rendererprocessen en webcontent in een sandbox | Normale frames en geïsoleerde webviews |
| Beschikbaar stellen van native API's | IPC en contextBridge | Node-contexten en configureerbare toegang |
| Chromium-sandboxing | Ondersteund met veilige standaardinstellingen | Afhankelijk van frametype en configuratie |
| Verantwoordelijkheid van de ontwikkelaar | IPC, navigatie, machtigingen en beschikbaar gestelde API's valideren | Frames met verhoogde rechten, Node-toegang en externe content beheren |
Noch Electron, noch NW.js mag automatisch worden beschouwd als een veilige browser voor algemeen gebruik. Applicaties die willekeurige websites van derden weergeven, vereisen aanvullende beveiligingsmaatregelen, ongeacht het framework.
Voor applicaties die volledig rond vertrouwde lokale content zijn ontwikkeld, kan de directe integratie van NW.js handig zijn. Voor applicaties die een sterke scheiding nodig hebben tussen code met verhoogde rechten en niet-vertrouwde webcontent, kan de architectuur van Electron die grenzen explicieter maken.
Uiteindelijk hangt beveiliging af van het applicatieontwerp, de configuratie, het beheer van afhankelijkheden en de snelheid waarmee ontwikkelaars beveiligingsupdates toepassen.
Gebruik: Electron domineert gangbare desktopapplicaties
Een van de belangrijkste verschillen tussen Electron en NW.js is de mate waarin ze worden gebruikt door ontwikkelaars van desktopsoftware.
Hoewel Electron het jongere project is, heeft het zich gevestigd als een gangbaar framework voor desktopapplicaties die daadwerkelijk in productie worden gebruikt. Het wordt toegepast in ontwikkeltools, communicatieplatforms, productiviteitssoftware, ontwerpapplicaties en zakelijke hulpprogramma's.
Enkele bekende voorbeelden zijn:
| Bedrijf | Electron-applicatie |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| GitHub | GitHub Desktop |
| Signal | Signal Desktop |
| Postman | Postman |
Deze producten laten zien dat Electron geavanceerde desktopapplicaties kan ondersteunen die door miljoenen mensen worden gebruikt. Het brede gebruik heeft ook bijgedragen aan een uitgebreid ecosysteem van bibliotheken, documentatie, debuggingtools en oplossingen voor het verpakken van applicaties.
De betrokkenheid van bedrijven is een ander voordeel. Electron werd oorspronkelijk ontwikkeld door GitHub en trok later bijdragen aan van engineers bij grote technologiebedrijven. Het beheer via de OpenJS Foundation biedt een organisatorische structuur voor samenwerking, beveiligingsonderhoud, releasebeheer en ontwikkeling op de lange termijn.
Dit betekent niet dat elk bedrijf dat Electron gebruikt rechtstreeks bijdraagt aan het framework, en het garandeert evenmin dat Electron altijd beter onderhouden zal worden. Een veelgebruikt framework met een diverse groep commerciële belanghebbenden kan echter profiteren van gedeelde investeringen in ontwikkeling en praktijkervaring met productieomgevingen.
NW.js heeft een ander gebruiksprofiel. Hoewel het is gebruikt om desktopapplicaties te bouwen, vermelden relatief weinig prominente moderne productiviteits- of bedrijfsapplicaties publiekelijk dat ze NW.js als framework gebruiken. Veel applicaties die traditioneel in NW.js-overzichten worden genoemd, zijn oudere projecten, waardoor die lijsten minder bruikbaar zijn om het huidige gebruik te beoordelen.
Dit betekent niet dat NW.js is verlaten of niet meer wordt gebruikt. Er blijven releases verschijnen met bijgewerkte versies van Chromium en Node.js. Het zichtbare ecosysteem is binnen gangbare desktopsoftware echter aanzienlijk kleiner dan dat van Electron.
Voor ontwikkelaars die een framework kiezen voor een nieuwe commerciële applicatie, is dit onderscheid belangrijk. Een groter ecosysteem maakt het doorgaans gemakkelijker om bestaande oplossingen te vinden, ontwikkelaars met relevante ervaring aan te trekken en problemen in productie op te lossen.
De populariteit van Electron maakt het niet in elk opzicht technisch superieur, maar het bredere gebruik en de betrokkenheid van bedrijven zijn praktische voordelen die niet over het hoofd mogen worden gezien.
Meer voorbeelden vind je in het officiële overzicht van Electron-applicaties.
Waar NW.js nog steeds populair is: indiegames
Hoewel NW.js niet breed vertegenwoordigd is onder grote moderne productiviteitsapplicaties, blijft het een duidelijke rol spelen in gameontwikkeling, vooral bij onafhankelijke ontwikkelaars.
Een van de redenen is de integratie met gameontwikkeltools zoals RPG Maker MV. Games die met RPG Maker MV zijn gemaakt, kunnen NW.js als desktopruntime gebruiken, waardoor op HTML5 en JavaScript gebaseerde games als zelfstandige applicaties kunnen draaien.
Dit betekent dat ontwikkelaars NW.js mogelijk indirect via hun game-engine gebruiken, in plaats van het te kiezen als desktopframework voor algemeen gebruik.
Er zijn ook onafhankelijke aanwijzingen dat NW.js nog steeds voorkomt in nieuw uitgebrachte games. SteamDB houdt games bij die NW.js gebruiken door automatisch technologische kenmerken in de gedistribueerde bestanden te onderzoeken. De database bevat games die in 2025 en 2026 zijn uitgebracht en levert daarmee bewijs van voortdurend gebruik, zonder uitsluitend af te gaan op mogelijk verouderde applicatieoverzichten.
Voorbeelden die met NW.js in verband worden gebracht, zijn:
| Game | Genre | Release op Steam |
|---|---|---|
| Look Outside | Horror-RPG | Maart 2025 |
| OMORI | RPG | December 2020 |
| CrossCode | Actie-RPG | September 2018 |
| Fear & Hunger | Horror-RPG | December 2018 |
| Ib | Horroravontuur | April 2022 |
| Saihate Station | Avontuur | Maart 2025 |
| Sheepy: A Short Adventure | Platformgame | Februari 2024 |
Bron: Technologiedetectie van NW.js door SteamDB.
SteamDB identificeert technologieën automatisch aan de hand van gamebestanden. Individuele detecties kunnen daardoor fouten bevatten of betrekking hebben op een meegeleverde afhankelijkheid in plaats van een runtime die de ontwikkelaar bewust heeft gekozen. De aanwezigheid van NW.js zegt ook niet welke frameworkversie een game gebruikt of of de ontwikkelaar die actief onderhoudt.
Desondanks laten deze voorbeelden zien dat NW.js nog steeds deel uitmaakt van het moderne ecosysteem voor gameontwikkeling.
Dit zorgt voor een interessant onderscheid tussen de twee frameworks. Electron is zeer zichtbaar in gangbare desktopapplicaties, vooral in productiviteits- en ontwikkeltools. NW.js is in die categorieën minder aanwezig, maar blijft voorkomen in onafhankelijk ontwikkelde games.
Voor ontwikkelaars die bedrijfssoftware, communicatietools of complexe productiviteitsapplicaties bouwen, kan het ecosysteem van Electron relevanter zijn. Voor ontwikkelaars die met RPG Maker werken of games onderhouden die rond NW.js zijn gebouwd, blijft het oudere framework een gevestigde en praktische keuze.
Ontwikkelervaring, tools en onderhoud op de lange termijn
Beide frameworks ondersteunen moderne frontendtechnologieën en Node.js-pakketten, waardoor ze toegankelijk zijn voor ontwikkelaars die vertrouwd zijn met webontwikkeling. Electron heeft echter een aanzienlijk groter ecosysteem dat is gericht op desktopsoftware voor algemeen gebruik.
NW.js biedt een relatief eenvoudig ontwikkelmodel. Een eenvoudige applicatie kan worden gedefinieerd met een package.json-manifest en een HTML-startpagina. Ontwikkelaars kunnen rechtstreeks vanuit daarvoor toegestane applicatiepagina's toegang krijgen tot Node.js-modules en NW.js-API's gebruiken voor het beheren van vensters, menu's, systeemvakpictogrammen en andere desktopfunctionaliteit.
Electron vereist doorgaans meer structuur aan het begin. Ontwikkelaars maken een toegangspunt voor het hoofdproces, configureren applicatievensters en beheren de communicatie tussen het hoofdproces en de rendererprocessen. Dit kan ingewikkelder aanvoelen voor kleine applicaties, maar stimuleert ontwikkelaars ook om applicatiefunctionaliteit in afzonderlijke lagen te organiseren.
Electron profiteert van gevestigde tools zoals Electron Forge en electron-builder, die oplossingen bieden voor het verpakken, ondertekenen, distribueren en bijwerken van applicaties. Door het brede gebruik kunnen ontwikkelaars ook meer voorbeelden en communitydiscussies vinden over geavanceerde problemen bij desktopontwikkeling.
NW.js biedt tools voor het verpakken van applicaties, zoals nw-builder, en ondersteunt handmatige verpakking. Het stelt ook API's beschikbaar die zijn afgeleid van de applicatie- en extensiearchitectuur van Chromium, wat aantrekkelijk kan zijn voor projecten die deze API's al gebruiken.
Beide frameworks vereisen dat ontwikkelaars omgaan met verschillen tussen besturingssystemen, codeondertekening, compatibiliteit van native modules en applicatie-updates. Geen van beide neemt de complexiteit weg van het distribueren van desktopsoftware voor productiegebruik.
De omvang en samenstelling van het ecosysteem worden vooral belangrijk bij onderhoud op de lange termijn. Teams die commerciële applicaties bouwen, hebben mogelijk oplossingen nodig voor codeondertekening, automatische updates, crashrapportage, toegankelijkheid, native integraties en platformspecifieke bugs.
Het bredere gebruik van Electron door grote softwarebedrijven maakt het gemakkelijker om gevestigde werkwijzen en herbruikbare oplossingen te vinden voor veel van deze vereisten. NW.js blijft capabel, maar ontwikkelaars kunnen minder voorbeelden of onderhouden integraties tegenkomen voor gespecialiseerde desktopfunctionaliteit.
Voor een project dat naar verwachting jarenlang onderhouden zal worden, verdienen de volwassenheid van het ecosysteem en voortdurende investeringen evenveel aandacht als de API's van het framework of benchmarkresultaten.
Waarom we bij WebCatalog voor Electron kiezen
Bij WebCatalog hebben we gekozen voor Electron omdat de architectuur nauw aansluit bij de vereisten van onze producten. Met WebCatalog kunnen gebruikers websites omzetten in desktopapplicaties, meerdere accounts onafhankelijk beheren en hun applicaties organiseren op macOS, Windows en Linux.
Anders dan ontwikkelaars die een conventionele desktopapplicatie bouwen met een frontend waarover ze volledige controle hebben, moeten wij websites ondersteunen die door duizenden verschillende ontwikkelaars zijn gemaakt. Deze websites kunnen gebruikmaken van uiteenlopende authenticatiesystemen, opslagmechanismen, browser-API's, mediafuncties en complexe JavaScript-applicaties.
Zowel Electron als NW.js gebruikt Chromium, waardoor ze vergelijkbare voordelen bieden op het gebied van compatibiliteit van de browserengine. Het onderscheid zit voor ons in de mate van controle die het framework biedt over applicatievensters, browsersessies, navigatie, machtigingen en de scheiding tussen applicatiecode met verhoogde rechten en externe content.
Electron biedt een volwassen reeks API's voor deze vereisten. De interfaces BrowserWindow, webContents en session stellen ons in staat browsergedrag op een relatief laag niveau te beheren. Permanente sessiepartities zijn bijzonder belangrijk, omdat gebruikers daarmee met meerdere accounts tegelijk aangemeld kunnen blijven bij dezelfde website zonder dat cookies en andere sessiegegevens tussen die accounts worden gedeeld.
NW.js ondersteunt ook ingebedde webviews, cookiebeheer en opslagpartities, dus deze mogelijkheden zijn niet exclusief voor Electron. Het afzonderlijke applicatieproces van Electron en de gevestigde API's voor browserbeheer bieden echter een architectuur die goed aansluit bij onze behoeften.
Beveiliging is een andere belangrijke overweging. Omdat WebCatalog websites van derden weergeeft waarover wij geen controle hebben, moeten we externe content zorgvuldig scheiden van applicatiefunctionaliteit met verhoogde rechten. Het procesmodel, de contextisolatie en de IPC-mechanismen van Electron helpen ons die scheiding te handhaven, al moeten we zelf nog steeds passende beveiligingsmaatregelen implementeren en onderhouden.
Tot slot maakt het ecosysteem van Electron platformonafhankelijke ontwikkeling en onderhoud praktischer. Onze applicaties moeten draaien op macOS, Windows en Linux, met ondersteuning voor platformspecifieke functies, verpakking, ondertekening en updates. De tools, documentatie en uitgebreide toepassing in de praktijk van Electron vormen een sterke basis voor dit werk.
We waarderen ook het ontwikkelecosysteem van Electron voor de lange termijn. De betrokkenheid van grote technologiebedrijven en het beheer via de OpenJS Foundation geven ons meer vertrouwen in de beschikbaarheid van technische middelen, beveiligingsonderhoud en ondersteuning vanuit de community naarmate onze producten zich ontwikkelen.
We erkennen de nadelen van Electron, met name de applicatiegrootte en de resourcevereisten. In plaats van het framework te vervangen, blijven we zoeken naar manieren om onnodige overhead te verminderen. Zo hebben we APFS-klonen geïmplementeerd om het schijfgebruik van gegenereerde Mac-applicaties te verminderen.
Onze beslissing is niet gebaseerd op de overtuiging dat NW.js geen geavanceerde software zou kunnen ondersteunen. Beide frameworks bieden de consistentie van Chromium die wij waarderen. Voor WebCatalog maken de architectuur, beveiligingsmaatregelen, bredere toepassing in gangbare software en het gevestigde ontwikkelecosysteem van Electron het de betere keuze.
Wanneer NW.js nog steeds een logische keuze is
Hoewel Electron een groter ecosysteem heeft, behoudt NW.js enkele belangrijke voordelen die ontwikkelaars in overweging moeten nemen.
Het meest onderscheidende kenmerk is de mogelijkheid om Node.js rechtstreeks te benaderen vanuit daarvoor toegestane browsercontexten. Voor ontwikkelaars die een bestaande webapplicatie omzetten in een desktopapplicatie, kan dit een handige manier zijn om toegang tot het bestandssysteem, integraties met het besturingssysteem en andere native functionaliteit toe te voegen zonder een afzonderlijke communicatielaag te ontwerpen.
NW.js kan een goede keuze zijn in de volgende situaties:
- Games bouwen met een bestaande, op NW.js gebaseerde toolchain. Ontwikkelaars die RPG Maker MV gebruiken of projecten onderhouden die afhankelijk zijn van NW.js, hebben mogelijk weinig reden om van framework te wisselen.
- Directe Node.js-integratie is gewenst. De applicatie kan profiteren van rechtstreekse toegang tot Node.js-functionaliteit binnen de vertrouwde interface.
- De applicatie is relatief eenvoudig. Een kleiner project heeft mogelijk geen behoefte aan de explicietere scheiding tussen hoofd- en rendererlogica van Electron.
- Het project gebruikt al NW.js. Migreren naar Electron levert mogelijk weinig voordeel op als de bestaande applicatie stabiel is en goed wordt onderhouden.
- Specifieke Chromium-applicatie-API's zijn belangrijk. NW.js biedt toegang tot ondersteunde Chrome-API's die nuttig kunnen zijn voor bepaalde applicaties.
NW.js wordt bovendien nog steeds actief onderhouden. De voortdurende Chromium-updates laten zien dat het zich blijft ontwikkelen samen met het browserplatform.
Voor ontwikkelaars die een bestaande NW.js-applicatie of -game onderhouden, vereist een overstap naar Electron een beoordeling van architectuurverschillen, wijzigingen in de verpakking en compatibiliteitsvereisten. Tenzij er een duidelijk technisch of zakelijk voordeel is, kan het praktischer zijn om bij het bestaande framework te blijven.
Electron versus NW.js: welk framework moet je kiezen?
Beide frameworks zijn geschikt voor het bouwen van platformonafhankelijke desktopapplicaties. Bij nieuwe projecten hangt de keuze grotendeels af van hoe ontwikkelaars hun code willen structureren en welk ecosysteem hun vereisten het beste ondersteunt.
| Jouw prioriteit | Beter uitgangspunt | Waarom |
|---|---|---|
| Grote, complexe desktopapplicaties | Electron | Gevestigde architectuur en ecosysteem |
| Gangbare productiviteits- of bedrijfssoftware | Electron | Veel breder gebruik in deze categorieën |
| Een ecosysteem voor de lange termijn en betrokkenheid van bedrijven | Electron | OpenJS Foundation en grote bijdragers uit de sector |
| Games gebouwd met RPG Maker MV | NW.js | Gevestigde integratie en toolchain |
| Directe Node.js-toegang vanuit applicatiepagina's | NW.js | Kernkenmerk van de architectuur |
| Expliciete scheiding tussen gebruikersinterface en code met verhoogde rechten | Electron | Hoofd-/renderermodel en IPC |
| Uitgebreide tools voor verpakking en distributie | Electron | Volwassen ecosysteem van tools |
| Bestaande NW.js-applicatie | NW.js | Onnodige migratie vermijden |
| Chromium-consistentie op verschillende desktopplatforms | Beide | Beide bundelen Chromium |
| Minimale applicatiegrootte | Geen van beide heeft een duidelijk voordeel | Beide bundelen Chromium en Node.js |
| Beheer van browsersessies en vensters | Electron | Volwassen, speciaal hiervoor bedoelde API's |
| Uitgebreide communitybronnen en voorbeelden | Electron | Groter gebruik in gangbare applicaties |
Voor de meeste teams die aan een omvangrijke nieuwe desktopapplicatie beginnen, is Electron de sterkere standaardkeuze. De architectuur, het ecosysteem, de beveiligingsrichtlijnen, de betrokkenheid van bedrijven en het uitgebreide gebruik in productie maken het een praktisch framework voor ontwikkeling op de lange termijn.
NW.js blijft het overwegen waard voor projecten die profiteren van directe Node.js-integratie, workflows voor gameontwikkeling die er al van afhankelijk zijn, of bestaande NW.js-codebases. Voor bepaalde toepassingen kan het eenvoudiger zijn, en de Chromium-basis biedt brede compatibiliteit met het webplatform.
Ontwikkelaars moeten ook bedenken dat geen van beide frameworks bijzonder lichtgewicht is. Als een kleine applicatiegrootte en een laag basisverbruik van systeembronnen de belangrijkste aandachtspunten zijn, verdienen alternatieven zoals Tauri mogelijk een nadere blik.
Tot slot
Electron en NW.js hebben meer overeenkomsten dan verschillen. Beide combineren Chromium en Node.js om ontwikkelaars platformonafhankelijke desktopapplicaties te laten bouwen met vertrouwde webtechnologieën. Beide ondersteunen moderne JavaScript-frameworks, native integratie met het besturingssysteem en geavanceerde desktopervaringen.
NW.js was er als eerste en introduceerde zijn aanpak om Node.js met webtechnologieën te combineren voordat Electron bestond. Electron werd daarna echter het meest gebruikte framework voor gangbare desktopapplicaties, dankzij de oorspronkelijke investering van GitHub, bijdragen van grote technologiebedrijven en het beheer via de OpenJS Foundation.
De gebruikspatronen verschillen duidelijk. Electron vormt de basis voor populaire productiviteits-, communicatie- en ontwikkelapplicaties die door miljoenen mensen worden gebruikt. NW.js is in die markt minder zichtbaar, maar blijft een betekenisvolle rol spelen in indiegames, waaronder titels op basis van RPG Maker en recent uitgebrachte games.
Bij WebCatalog maken we dezelfde frameworkkeuze als veel grote ontwikkelaars van desktopsoftware. Electron biedt ons de Chromium-consistentie, mogelijkheden voor browserbeheer, beveiligingsarchitectuur en platformonafhankelijke tools die nodig zijn om een grote verscheidenheid aan webapplicaties te ondersteunen op macOS, Windows en Linux.
NW.js is niet achterhaald, en het voortdurende gebruik in gameontwikkeling toont aan dat het nuttig blijft. Maar voor ontwikkelaars die beginnen aan een nieuwe desktopapplicatie voor algemeen gebruik, maken het bredere ecosysteem, de gevestigde tools, de betrokkenheid van bedrijven en de grotere community van Electron het tot de praktischere standaardkeuze.
Uiteindelijk hangt de beste keuze af van de vereisten van de applicatie, de ervaring van het ontwikkelteam en de kosten van het onderhoud van de software op de lange termijn.
