Electron og NW.js er to etablerte rammeverk for å bygge skrivebordsapplikasjoner på tvers av plattformer ved hjelp av webteknologier. Begge kombinerer Chromium og Node.js, slik at utviklere kan lage applikasjoner med HTML, CSS, JavaScript og kjente frontend-rammeverk som React, Vue og Angular.
NW.js er faktisk det eldste rammeverket. Prosjektet, som opprinnelig het node-webkit, startet i 2011 og var offentlig tilgjengelig i 2012. Electron fulgte i 2013, og ble opprinnelig utviklet av GitHub for koderedigereren Atom. Selv om Electron kom senere, ble det etter hvert det mest utbredte rammeverket for skrivebordsapplikasjoner rettet mot et bredt marked.
I dag driver Electron store applikasjoner som Visual Studio Code, Slack, Discord, Notion og Figma. Det nyter også godt av deltakelse fra store teknologiselskaper og forvaltning gjennom OpenJS Foundation. Hos WebCatalog har vi valgt Electron som grunnlag for skrivebordsapplikasjonene våre på tvers av plattformer.
NW.js har på sin side en langt mindre synlig tilstedeværelse blant store produktivitets- og forretningsapplikasjoner. Den fortsatte bruken er særlig tydelig i spillbransjen, blant annet i indiespill og titler bygget med RPG Maker.
Så hvordan står de to rammeverkene seg mot hverandre, og hvilket bør utviklere velge?
Electron vs. NW.js i korte trekk
Begge rammeverkene lar utviklere bygge skrivebordsapplikasjoner med webteknologier, men de har ulike tilnærminger til applikasjonsarkitektur, integrasjon med operativsystemet og sikkerhet.
| Egenskap | Electron | NW.js |
|---|---|---|
| Først introdusert | 2013 | 2011–2012 |
| Opprinnelig utvikler | GitHub | Intel Open Source Technology Center |
| Forvaltning og økosystem | OpenJS Foundation, med store selskaper som bidragsytere | Vedlikeholdt av fellesskapet, med opprinnelse hos Intel |
| Nettlesermotor | Chromium | Chromium |
| Kjøremiljø for JavaScript | Node.js | Node.js |
| Skrivebordsplattformer | macOS, Windows, Linux | macOS, Windows, Linux |
| Arkitektur | Hovedprosess og gjengivelsesprosesser | Chromium-arkitektur med direkte Node.js-integrasjon |
| Node.js-tilgang | Hovedprosess og kontrollert integrasjon i gjengivelsesprosesser | Direkte tilgang fra applikasjonssider som har tillatelse |
| Applikasjonsstørrelse | Relativt stor | Relativt stor |
| Ytelse | Avhenger av applikasjonen | Avhenger av applikasjonen |
| Sikkerhet | Sandkasseisolering, kontekstisolering, IPC | Konfigurerbar Node-tilgang og rammeisolering |
| Utbredelse | Mye brukt i skrivebordsapplikasjoner for et bredt marked | Mindre økosystem, betydelig bruk i spill |
| Mobilstøtte | Ingen offisiell støtte | Ingen offisiell støtte |
De viktigste forskjellene gjelder ikke ytelse eller applikasjonsstørrelse. Begge rammeverkene inkluderer Chromium og Node.js, så ressurskravene er stort sett sammenlignbare. De vesentlige forskjellene gjelder i stedet arkitektur, sikkerhetsgrenser, utviklerverktøy og støtte i økosystemet.
Historikk: NW.js kom først, men Electron ble mer populært
NW.js var et av de første prosjektene som viste at utviklere kunne kombinere Node.js med nettleserteknologier for å lage skrivebordsapplikasjoner. Det het opprinnelig node-webkit og sprang ut av Intels Open Source Technology Center. Utviklingen begynte i 2011, og offentlige utgivelser var tilgjengelige i 2012.
Hovedideen var enkel: La JavaScript som kjører i et nettleserlignende miljø, få direkte tilgang til Node.js-moduler. Dette gjorde det mulig å utvikle skrivebordsapplikasjoner med kjente webteknologier uten å bygge et tradisjonelt plattformspesifikt grensesnitt.
Electron kom i 2013 under navnet Atom Shell. GitHub utviklet det som grunnlag for koderedigereren Atom, som ble tilgjengelig i offentlig beta i 2014. Electron ble utformet som et alternativ til de webbaserte skrivebordsrammeverkene som fantes på den tiden, blant annet node-webkit og Chromium Embedded Framework.
Selv om begge rammeverkene hadde som mål å gjøre skrivebordsutvikling tilgjengelig for webutviklere, valgte Electron en annen arkitektur som skilte funksjonalitet på applikasjonsnivå fra webinnhold. Denne tilnærmingen ble stadig mer attraktiv etter hvert som utviklere begynte å bygge mer komplekse applikasjoner.
Electron ble deretter tatt i bruk av både oppstartsbedrifter og store teknologiselskaper. GitHub, Slack, Microsoft og andre organisasjoner bidro til utviklingen og økosystemet. I 2019 ble Electron en del av OpenJS Foundation og gikk dermed fra GitHub-eierskap til en nøytral stiftelse for åpen kildekode.
I dag drives Electron etter en etablert styringsmodell med arbeidsgrupper for sikkerhet, utgivelser, API-er, oppgraderinger av Chromium og Node.js og andre områder. Utviklere tilknyttet organisasjoner som Microsoft og Slack har deltatt i vedlikeholdet og forvaltningen.
NW.js har også sitt opphav i et selskap, ettersom det ble utviklet hos Intel. Det nåværende økosystemet er imidlertid mindre og har ikke den samme bredden av synlig deltakelse fra store selskaper som utvikler skrivebordsprogramvare.
Denne historien illustrerer en viktig forskjell: Å være først er ingen garanti for langsiktig dominans. NW.js bidro til å etablere konseptet med å bygge skrivebordsapplikasjoner med Chromium og Node.js, men Electron tiltrakk seg et bredere økosystem av utviklere, vedlikeholdere og kommersielle brukere.
Du finner mer bakgrunnsinformasjon i Electrons tilbakeblikk på de første ti årene, Electron blir en del av OpenJS Foundation og historien om node-webkit-prosjektet.
Arkitektur: Hovedprosesser vs. direkte Node.js-integrasjon
Electron bruker en flerprosessarkitektur arvet fra Chromium. Hver Electron-applikasjon har en hovedprosess som har ansvar for å håndtere vinduer, hendelser i applikasjonens livssyklus, integrasjoner med operativsystemet og privilegert funksjonalitet. Webinnhold kjører i separate gjengivelsesprosesser, som kommuniserer med hovedprosessen gjennom interprosesskommunikasjon (IPC).
Dette skaper et skille mellom applikasjonslogikk og kode for brukergrensesnittet. En gjengivelsesprosess oppfører seg vanligvis som et konvensjonelt nettlesermiljø, mens hovedprosessen håndterer operasjoner som krever tilgang til Node.js eller plattformspesifikke API-er. Electron tilbyr også forhåndslastingsskript og API-et contextBridge, slik at utviklere kan gjøre utvalgt funksjonalitet tilgjengelig for gjengivelsesprosessen uten å gi ubegrenset tilgang til Node.js.
NW.js har en annen tilnærming. Det ble utformet for å gjøre Node.js-funksjonalitet tilgjengelig direkte i webapplikasjoner. På en applikasjonsside som har tillatelse, kan utviklere få tilgang til Node.js-moduler gjennom kjente JavaScript-API-er uten å etablere et separat IPC-grensesnitt for hver operasjon.
En lokalt pakket NW.js-applikasjon kan for eksempel bruke Node.js direkte fra et skript som kjører på siden:
const fs = require('node:fs');
const content = fs.readFileSync('notes.txt', 'utf8');
document.body.textContent = content;
Denne enkelheten er en av de fremste fordelene ved NW.js. Utviklere kan kombinere nettleser-API-er og Node.js-funksjonalitet uten nødvendigvis å dele koden inn i separate applikasjonslag. NW.js støtter også separate JavaScript-kontekster og en modus med blandede kontekster, noe som gir fleksibilitet i samspillet mellom nettleser- og Node.js-funksjonalitet.
Electron oppmuntrer generelt til et tydeligere skille. For å lese en fil fra gjengivelsesprosessen vil en typisk sikker Electron-applikasjon gjøre en avgrenset operasjon tilgjengelig gjennom et forhåndslastingsskript og håndtere tilgangen til filsystemet i hovedprosessen.
Denne tilnærmingen krever mer kode, men gjør grensen mellom privilegert applikasjonsfunksjonalitet og webinnhold tydeligere. For komplekse applikasjoner kan dette skillet gjøre vedlikehold enklere og sikkerhetsansvaret lettere å forstå.
Ingen av arkitekturene er best i alle tilfeller. NW.js kan oppleves som mer rett frem for mindre applikasjoner eller prosjekter som har nytte av direkte Node.js-integrasjon. Electron gir en struktur som kan være spesielt nyttig etter hvert som en applikasjon blir mer kompleks.
Ytelse, minnebruk og applikasjonsstørrelse
Fordi både Electron og NW.js inkluderer Chromium og Node.js, har ingen av rammeverkene en iboende arkitektonisk fordel som kan sammenlignes med størrelsesforskjellen mellom Electron og Tauri.
Selv en enkel applikasjon bygget med et av rammeverkene må distribueres med et omfattende kjøremiljø. Begge rammeverkene kan også opprette flere Chromium-prosesser, noe som øker minnebruken, men bidrar til å isolere arbeidsoppgaver og forbedre responsen.
Den direkte integrasjonen mellom Node.js og nettlesermiljøet i NW.js kan redusere behovet for IPC i enkelte operasjoner. Avhengig av kontekstkonfigurasjonen kan JavaScript-kode samhandle direkte med Node.js-funksjonalitet, noe som gjør enkelte operasjoner enklere og potensielt reduserer kommunikasjonskostnadene.
Electron skiller privilegerte operasjoner fra koden i gjengivelsesprosessen, noe som innfører IPC når prosessgrenser krysses. Dette betyr imidlertid ikke at Electron i seg selv er tregere. Den ekstra belastningen kan være ubetydelig ved vanlig samhandling med brukergrensesnittet, og skillet kan bidra til å holde krevende bakgrunnsarbeid borte fra gjengivelsesprosessen.
I praksis avhenger applikasjonsytelsen i stor grad av hvordan utviklere bruker Chromium, administrerer bakgrunnsprosesser, implementerer gjengivelse og håndterer applikasjonstilstand.
For å gjøre meningsfulle sammenligninger bør utviklere vurdere:
- Oppstartstid: Hvor raskt applikasjonen blir klar til bruk.
- Minnebruk: Både forbruk i hvile og minnebruk under realistiske arbeidsbelastninger.
- CPU-bruk: Ressursforbruk under gjengivelse og bakgrunnsoperasjoner.
- Applikasjonsstørrelse: Nedlastingsstørrelse og lagringsbehov etter installasjon.
- Respons: Hvor godt grensesnittet fungerer under ressurskrevende oppgaver.
Ingen av rammeverkene bør regnes som kategorisk raskere uten at man måler en representativ applikasjon. Forskjeller i Chromium-versjoner, byggkonfigurasjoner, native moduler og applikasjonsarkitektur kan alle påvirke resultatene i ytelsestester.
For utviklere som først og fremst ønsker å redusere applikasjonsstørrelsen, vil et bytte fra Electron til NW.js neppe gi de store besparelsene man kan oppnå ved å gå over til et rammeverk som bruker operativsystemets webvisning.
Sikkerhet: Ulike tilnærminger til tilgang til systemfunksjoner
Sikkerhet er en av de viktigste forskjellene mellom Electron og NW.js, særlig for applikasjoner som viser eksterne nettsteder eller annet innhold som ikke er klarert.
Electron tilbyr flere sikkerhetsmekanismer, blant annet Chromium-sandkasseisolering, kontekstisolering og muligheten til å deaktivere Node.js-integrasjon i gjengivelsesprosesser. Moderne Electron-versjoner aktiverer viktige beskyttelsestiltak som standard, og prosjektets sikkerhetsdokumentasjon anbefaler på det sterkeste å holde privilegerte system-API-er atskilt fra eksternt innhold.
NW.js tillater mer direkte tilgang til Node.js fra applikasjonssider som har tillatelse. Dette kan forenkle utviklingen, men krever også nøye vurdering av hvilket innhold som får disse privilegiene.
NW.js skiller mellom vanlige rammer og rammer med Node aktivert. Det støtter også innstillinger som node-remote for å styre hvilke eksterne URL-er som får tilgang til Node.js-funksjonalitet. Webvisningskomponenten kan vise gjesteinnhold i en separat prosess uten automatisk å gi det applikasjonens privilegier.
| Sikkerhetshensyn | Electron | NW.js |
|---|---|---|
| Privilegert Node.js-tilgang | Primært hovedprosessen og kontrollerte broer | Tilgjengelig direkte i applikasjonskontekster som har tillatelse |
| Isolering av eksternt innhold | Gjengivelsesprosesser og webinnhold i sandkasse | Vanlige rammer og isolerte webvisninger |
| Tilgjengeliggjøring av system-API-er | IPC og contextBridge | Node-kontekster og konfigurerbar tilgang |
| Chromium-sandkasseisolering | Støttes med sikre standardinnstillinger | Avhenger av rammetype og konfigurasjon |
| Utviklerens ansvar | Validere IPC, navigasjon, tillatelser og tilgjengeliggjorte API-er | Kontrollere privilegerte rammer, Node-tilgang og eksternt innhold |
Verken Electron eller NW.js bør automatisk behandles som en sikker allmenn nettleser. Applikasjoner som viser vilkårlige tredjepartsnettsteder, krever ytterligere sikkerhetstiltak, uavhengig av rammeverket.
For applikasjoner som utelukkende er bygget rundt klarert lokalt innhold, kan den direkte integrasjonen i NW.js være praktisk. For applikasjoner som trenger et tydelig skille mellom privilegert kode og webinnhold som ikke er klarert, kan Electrons arkitektur gjøre disse grensene mer eksplisitte.
Til syvende og sist avhenger sikkerheten av applikasjonsdesign, konfigurasjon, håndtering av avhengigheter og hvor raskt utviklerne tar i bruk sikkerhetsoppdateringer.
Utbredelse: Electron dominerer skrivebordsapplikasjoner for et bredt marked
En av de mest betydningsfulle forskjellene mellom Electron og NW.js er utbredelsen blant utviklere av skrivebordsprogramvare.
Til tross for at Electron er det yngste prosjektet, har det etablert seg som et utbredt rammeverk for skrivebordsapplikasjoner i produksjon. Det brukes i utviklingsverktøy, kommunikasjonsplattformer, produktivitetsprogramvare, designapplikasjoner og verktøy for virksomheter.
Noen kjente eksempler er:
| Selskap | Electron-applikasjon |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| GitHub | GitHub Desktop |
| Signal | Signal Desktop |
| Postman | Postman |
Disse produktene viser at Electron kan støtte avanserte skrivebordsapplikasjoner som brukes av millioner av mennesker. Utbredelsen har også bidratt til et omfattende økosystem av biblioteker, dokumentasjon, feilsøkingsverktøy og pakkeløsninger.
Deltakelse fra selskaper er en annen fordel. Electron ble opprinnelig utviklet av GitHub og tiltrakk seg senere bidrag fra utviklere i store teknologiselskaper. Forvaltningen gjennom OpenJS Foundation gir en organisatorisk struktur for samarbeid, sikkerhetsvedlikehold, utgivelseshåndtering og langsiktig utvikling.
Dette betyr ikke at alle selskaper som bruker Electron, bidrar direkte til rammeverket, og det garanterer heller ikke at Electron alltid vil være bedre vedlikeholdt. Et mye brukt rammeverk med en variert gruppe kommersielle interessenter kan imidlertid dra nytte av felles utviklingsinnsats og erfaring fra praktisk bruk i produksjon.
NW.js har en annen utbredelsesprofil. Selv om det har blitt brukt til å bygge skrivebordsapplikasjoner, er det relativt få fremtredende moderne produktivitets- eller forretningsapplikasjoner som offentlig oppgir NW.js som rammeverk. Mange applikasjoner som tradisjonelt nevnes i oversikter over NW.js-applikasjoner, er eldre prosjekter, noe som gjør disse listene mindre nyttige for å vurdere dagens utbredelse.
Dette betyr ikke at NW.js er forlatt eller ubrukt. Det kommer fortsatt utgivelser med oppdaterte versjoner av Chromium og Node.js. Det synlige økosystemet er imidlertid betydelig mindre enn Electrons innen skrivebordsprogramvare for et bredt marked.
For utviklere som velger rammeverk til en ny kommersiell applikasjon, er dette skillet viktig. Et større økosystem gjør det generelt enklere å finne eksisterende løsninger, rekruttere utviklere med relevant erfaring og løse problemer i produksjon.
Electrons popularitet gjør det ikke teknisk overlegent på alle områder, men den bredere utbredelsen og deltakelsen fra selskaper er praktiske fordeler som ikke bør overses.
Du kan utforske flere eksempler i den offisielle oversikten over Electron-applikasjoner.
Der NW.js fortsatt er populært: Indiespill
Selv om NW.js ikke er bredt representert blant store moderne produktivitetsapplikasjoner, har det fortsatt en betydelig tilstedeværelse innen spillutvikling, særlig blant uavhengige utviklere.
En av grunnene er integrasjonen med spillutviklingsverktøy som RPG Maker MV. Spill laget med RPG Maker MV kan bruke NW.js som kjøremiljø på skrivebordet, slik at HTML5- og JavaScript-baserte spill kan kjøre som selvstendige applikasjoner.
Dette betyr at utviklere kan bruke NW.js indirekte gjennom spillmotoren i stedet for å velge det som et generelt skrivebordsrammeverk.
Det finnes også uavhengige holdepunkter for at NW.js fortsatt dukker opp i nyutgitte spill. SteamDB registrerer spill som bruker NW.js ved automatisk å undersøke teknologisignaturer i de distribuerte filene. Databasen inneholder spill utgitt i 2025 og 2026, noe som dokumenterer fortsatt bruk fremfor å basere seg utelukkende på potensielt utdaterte applikasjonsoversikter.
Eksempler knyttet til NW.js inkluderer:
| Spill | Sjanger | Utgivelse på Steam |
|---|---|---|
| Look Outside | Skrekkrollespill | Mars 2025 |
| OMORI | Rollespill | Desember 2020 |
| CrossCode | Actionrollespill | September 2018 |
| Fear & Hunger | Skrekkrollespill | Desember 2018 |
| Ib | Skrekkeventyr | April 2022 |
| Saihate Station | Eventyr | Mars 2025 |
| Sheepy: A Short Adventure | Plattformspill | Februar 2024 |
Kilde: SteamDBs registrering av NW.js-teknologi.
SteamDB identifiserer teknologier automatisk fra spillfiler, så enkelte registreringer kan inneholde feil eller representere en inkludert avhengighet snarere enn et kjøremiljø som utvikleren bevisst har valgt. At NW.js finnes i et spill, fastslår heller ikke hvilken versjon av rammeverket spillet bruker, eller om utvikleren aktivt vedlikeholder det.
Likevel viser disse eksemplene at NW.js fortsatt er en del av det moderne spillutviklingsøkosystemet.
Dette skaper et interessant skille mellom de to rammeverkene. Electron er svært synlig i skrivebordsapplikasjoner for et bredt marked, særlig produktivitets- og utviklingsverktøy. NW.js har en mindre tilstedeværelse i disse kategoriene, men dukker fortsatt opp i uavhengig utviklede spill.
For utviklere som bygger forretningsprogramvare, kommunikasjonsverktøy eller komplekse produktivitetsapplikasjoner, kan Electrons økosystem være mer relevant. For utviklere som arbeider med RPG Maker eller vedlikeholder spill bygget rundt NW.js, er det eldre rammeverket fortsatt et etablert og praktisk valg.
Utvikleropplevelse, verktøy og langsiktig vedlikehold
Begge rammeverkene støtter moderne frontend-teknologier og Node.js-pakker, noe som gjør dem tilgjengelige for utviklere som er kjent med webutvikling. Electron har imidlertid et betydelig større økosystem rettet mot generell skrivebordsprogramvare.
NW.js tilbyr en relativt enkel utviklingsmodell. En enkel applikasjon kan defineres med en package.json-manifestfil og et HTML-inngangspunkt. Utviklere kan få tilgang til Node.js-moduler direkte fra applikasjonssider som har tillatelse, og bruke NW.js-API-er til å håndtere vinduer, menyer, ikoner i systemstatusfeltet og annen skrivebordsfunksjonalitet.
Electron krever vanligvis mer struktur i starten. Utviklere oppretter et inngangspunkt for hovedprosessen, konfigurerer applikasjonsvinduer og håndterer kommunikasjon mellom hovedprosessen og gjengivelsesprosessene. Dette kan oppleves som mer komplisert for små applikasjoner, men oppmuntrer også utviklere til å organisere applikasjonens funksjonalitet i tydelig atskilte lag.
Electron nyter godt av etablerte verktøy som Electron Forge og electron-builder, som tilbyr løsninger for pakking, signering, distribusjon og oppdatering av applikasjoner. Den store utbredelsen betyr også at utviklere kan finne flere eksempler og diskusjoner i fellesskapet om avanserte problemer innen skrivebordsutvikling.
NW.js tilbyr pakkeverktøy som nw-builder og støtter manuell pakking. Det gjør også API-er avledet fra Chromiums applikasjons- og utvidelsesarkitektur tilgjengelige, noe som kan være attraktivt for prosjekter som allerede bruker disse API-ene.
Begge rammeverkene krever at utviklere håndterer forskjeller mellom operativsystemer, kodesignering, kompatibilitet med native moduler og applikasjonsoppdateringer. Ingen av dem fjerner kompleksiteten ved å distribuere produksjonsklar skrivebordsprogramvare.
Økosystemets størrelse og sammensetning blir særlig viktig for langsiktig vedlikehold. Team som bygger kommersielle applikasjoner, kan trenge løsninger for kodesignering, automatiske oppdateringer, krasjrapportering, universell utforming, integrasjoner med operativsystemet og plattformspesifikke feil.
Electrons bredere utbredelse blant store programvareselskaper gjør det enklere å finne etablert praksis og gjenbrukbare løsninger for mange av disse behovene. NW.js er fortsatt et kapabelt rammeverk, men utviklere kan finne færre eksempler eller vedlikeholdte integrasjoner for spesialisert skrivebordsfunksjonalitet.
For et prosjekt som forventes å bli vedlikeholdt i mange år, fortjener økosystemets modenhet og fortsatt investering like mye oppmerksomhet som rammeverkets API-er eller resultater fra ytelsestester.
Hvorfor vi velger Electron hos WebCatalog
Hos WebCatalog har vi valgt Electron fordi arkitekturen samsvarer godt med kravene til produktene våre. WebCatalog lar brukere gjøre nettsteder om til skrivebordsapplikasjoner, administrere flere kontoer uavhengig av hverandre og organisere applikasjonene sine på tvers av macOS, Windows og Linux.
I motsetning til utviklere som bygger en konvensjonell skrivebordsapplikasjon med en frontend de har full kontroll over, må vi støtte nettsteder laget av tusenvis av forskjellige utviklere. Disse nettstedene kan benytte ulike autentiseringssystemer, lagringsmekanismer, nettleser-API-er, mediefunksjoner og komplekse JavaScript-applikasjoner.
Både Electron og NW.js bruker Chromium, så de tilbyr lignende fordeler når det gjelder kompatibilitet med nettlesermotoren. Forskjellen for oss ligger i hvor mye kontroll rammeverket gir over applikasjonsvinduer, nettleserøkter, navigasjon, tillatelser og skillet mellom privilegert applikasjonskode og eksternt innhold.
Electron tilbyr et modent sett med API-er for disse behovene. Grensesnittene BrowserWindow, webContents og session lar oss håndtere nettleseratferd på et relativt lavt nivå. Vedvarende øktpartisjoner er spesielt viktige fordi de lar brukere være logget inn med flere kontoer på samme nettsted uten at kontoene deler informasjonskapsler og andre øktdata.
NW.js støtter også innebygde webvisninger, håndtering av informasjonskapsler og lagringspartisjoner, så disse funksjonene er ikke eksklusive for Electron. Electrons dedikerte applikasjonsprosess og veletablerte API-er for nettleseradministrasjon gir imidlertid en arkitektur som passer godt til behovene våre.
Sikkerhet er et annet viktig hensyn. Fordi WebCatalog viser tredjepartsnettsteder som vi ikke kontrollerer, må vi nøye skille eksternt innhold fra privilegert applikasjonsfunksjonalitet. Electrons prosessmodell, kontekstisolering og IPC-mekanismer hjelper oss med å opprettholde dette skillet, selv om vi fortsatt må implementere og vedlikeholde egnede sikkerhetstiltak selv.
Til slutt gjør Electrons økosystem utvikling og vedlikehold på tvers av plattformer mer praktisk. Applikasjonene våre må kjøre på macOS, Windows og Linux, med støtte for plattformspesifikke funksjoner, pakking, signering og oppdateringer. Electrons verktøy, dokumentasjon og omfattende bruk i praksis gir et solid grunnlag for dette arbeidet.
Vi verdsetter også Electrons langsiktige utviklingsøkosystem. Deltakelsen fra store teknologiselskaper og forvaltningen gjennom OpenJS Foundation gir oss større trygghet for tilgangen til tekniske ressurser, sikkerhetsvedlikehold og støtte fra fellesskapet etter hvert som produktene våre utvikler seg.
Vi erkjenner Electrons ulemper, særlig applikasjonsstørrelsen og ressurskravene. I stedet for å erstatte rammeverket fortsetter vi å utforske måter å redusere unødvendig ressursbruk på. Vi har for eksempel tatt i bruk APFS-kloner for å redusere diskbruken til genererte Mac-applikasjoner.
Beslutningen vår bygger ikke på en oppfatning om at NW.js ikke er i stand til å støtte avansert programvare. Begge rammeverkene gir den ensartede Chromium-opplevelsen vi verdsetter. For WebCatalog gjør Electrons arkitektur, sikkerhetstiltak, bredere utbredelse i det generelle markedet og etablerte utviklingsøkosystem det til det beste valget.
Der NW.js fortsatt er et godt valg
Selv om Electron har et større økosystem, har NW.js fortsatt noen vesentlige fordeler som utviklere bør vurdere.
Det mest særegne trekket er muligheten til å få direkte tilgang til Node.js fra nettleserkontekster som har tillatelse. For utviklere som gjør en eksisterende webapplikasjon om til en skrivebordsapplikasjon, kan dette være en praktisk måte å innføre tilgang til filsystemet, integrasjoner med operativsystemet og annen systemfunksjonalitet på uten å utforme et separat kommunikasjonslag.
NW.js kan være et godt valg når:
- Du bygger spill med en eksisterende NW.js-basert verktøykjede. Utviklere som bruker RPG Maker MV eller vedlikeholder prosjekter som er avhengige av NW.js, kan ha liten grunn til å bytte rammeverk.
- Direkte Node.js-integrasjon er ønskelig. Applikasjonen kan dra nytte av direkte tilgang til Node.js-funksjonalitet i det klarerte grensesnittet.
- Applikasjonen er relativt enkel. Et mindre prosjekt trenger kanskje ikke Electrons tydeligere skille mellom hovedprosesslogikk og gjengivelseslogikk.
- Prosjektet allerede bruker NW.js. En overgang til Electron kan gi liten gevinst hvis den eksisterende applikasjonen er stabil og godt vedlikeholdt.
- Bestemte Chromium-applikasjons-API-er er viktige. NW.js gir tilgang til støttede Chrome-API-er som kan være nyttige for enkelte applikasjoner.
NW.js blir også fortsatt aktivt vedlikeholdt. De løpende Chromium-oppdateringene viser at det fortsetter å utvikle seg i takt med nettleserplattformen.
For utviklere som vedlikeholder en eksisterende NW.js-applikasjon eller et spill, vil et bytte til Electron kreve en vurdering av arkitektoniske forskjeller, endringer i pakking og kompatibilitetskrav. Med mindre det finnes en tydelig teknisk eller forretningsmessig gevinst, kan det være mer praktisk å beholde det eksisterende rammeverket.
Electron vs. NW.js: Hvilket bør du velge?
Begge rammeverkene kan brukes til å bygge skrivebordsapplikasjoner på tvers av plattformer. For nye prosjekter avhenger valget i stor grad av hvordan utviklerne ønsker å strukturere koden, og hvilket økosystem som best støtter behovene deres.
| Din prioritet | Beste utgangspunkt | Hvorfor |
|---|---|---|
| Store, komplekse skrivebordsapplikasjoner | Electron | Etablert arkitektur og økosystem |
| Produktivitets- eller forretningsprogramvare for et bredt marked | Electron | Langt bredere utbredelse i disse kategoriene |
| Langsiktig økosystem og deltakelse fra selskaper | Electron | OpenJS Foundation og store bidragsytere fra bransjen |
| Spill bygget med RPG Maker MV | NW.js | Etablert integrasjon og verktøykjede |
| Direkte Node.js-tilgang fra applikasjonssider | NW.js | Grunnleggende arkitektonisk egenskap |
| Tydelig skille mellom brukergrensesnitt og privilegert kode | Electron | Modell med hovedprosess og gjengivelsesprosesser samt IPC |
| Omfattende verktøy for pakking og distribusjon | Electron | Modent verktøyøkosystem |
| Eksisterende NW.js-applikasjon | NW.js | Unngå unødvendig migrering |
| Ensartet Chromium-opplevelse på tvers av skrivebordsplattformer | Begge | Begge inkluderer Chromium |
| Minst mulig applikasjonsstørrelse | Ingen har en klar fordel | Begge inkluderer Chromium og Node.js |
| Håndtering av nettleserøkter og vinduer | Electron | Modne, dedikerte API-er |
| Et bredt utvalg av fellesskapsressurser og eksempler | Electron | Større utbredelse i det generelle markedet |
For de fleste team som starter på en større ny skrivebordsapplikasjon, er Electron det sterkeste standardvalget. Arkitekturen, økosystemet, sikkerhetsveiledningen, deltakelsen fra selskaper og den omfattende bruken i produksjon gjør det til et praktisk rammeverk for langsiktig utvikling.
NW.js er fortsatt verdt å vurdere for prosjekter som har nytte av direkte Node.js-integrasjon, arbeidsflyter for spillutvikling som allerede er avhengige av det, eller etablerte NW.js-kodebaser. Det kan være enklere for enkelte bruksområder, og Chromium-grunnlaget gir bred kompatibilitet med webplattformen.
Utviklere bør også huske at ingen av rammeverkene er spesielt lettvekts. Hvis liten applikasjonsstørrelse og lavt ressursforbruk i utgangspunktet er de viktigste hensynene, kan alternativer som Tauri være verdt å vurdere.
Avsluttende tanker
Electron og NW.js har flere likheter enn forskjeller. Begge kombinerer Chromium og Node.js slik at utviklere kan bygge skrivebordsapplikasjoner på tvers av plattformer med kjente webteknologier. Begge støtter moderne JavaScript-rammeverk, integrasjon med operativsystemet og avanserte skrivebordsopplevelser.
NW.js kom først og introduserte sin tilnærming til å kombinere Node.js med webteknologier før Electron eksisterte. Electron ble imidlertid senere det mest utbredte rammeverket for skrivebordsapplikasjoner rettet mot et bredt marked, hjulpet av GitHubs opprinnelige investering, bidrag fra store teknologiselskaper og forvaltning gjennom OpenJS Foundation.
Bruksmønstrene deres er merkbart forskjellige. Electron driver populære produktivitets-, kommunikasjons- og utviklingsapplikasjoner som brukes av millioner av mennesker. NW.js er mindre synlig i det markedet, men har fortsatt en betydelig tilstedeværelse i indiespill, blant annet RPG Maker-baserte titler og nylig utgitte spill.
Hos WebCatalog velger vi samme rammeverk som mange store utviklere av skrivebordsprogramvare. Electron gir oss den ensartede Chromium-opplevelsen, funksjonene for nettleseradministrasjon, sikkerhetsarkitekturen og verktøyene på tvers av plattformer som trengs for å støtte et stort utvalg av webapplikasjoner på macOS, Windows og Linux.
NW.js er ikke utdatert, og den fortsatte bruken innen spillutvikling viser at det fortsatt er nyttig. Men for utviklere som starter på en ny generell skrivebordsapplikasjon, gjør Electrons bredere økosystem, etablerte verktøy, deltakelse fra selskaper og større fellesskap det til det mest praktiske standardvalget.
Til syvende og sist avhenger det beste valget av kravene til applikasjonen, erfaringen til utviklingsteamet og de langsiktige kostnadene ved å vedlikeholde programvaren.
