Electron e NW.js sono due framework consolidati per la creazione di applicazioni desktop multipiattaforma con tecnologie web. Entrambi combinano Chromium e Node.js, consentendo agli sviluppatori di creare applicazioni con HTML, CSS, JavaScript e framework frontend familiari come React, Vue e Angular.
NW.js è in realtà il framework più vecchio. Originariamente noto come node-webkit, il progetto è nato nel 2011 ed era già disponibile pubblicamente nel 2012. Electron è arrivato nel 2013, inizialmente sviluppato da GitHub per il suo editor di codice Atom. Pur essendo arrivato più tardi, Electron è diventato il framework più ampiamente adottato per le applicazioni desktop di largo utilizzo.
Oggi Electron è alla base di importanti applicazioni come Visual Studio Code, Slack, Discord, Notion e Figma. Beneficia inoltre della partecipazione di grandi aziende tecnologiche e di una governance affidata alla OpenJS Foundation. In WebCatalog abbiamo scelto Electron come base per le nostre applicazioni desktop multipiattaforma.
NW.js, invece, ha una presenza visibile molto più ridotta tra le principali applicazioni aziendali e per la produttività. La sua adozione continua è particolarmente evidente nel settore dei videogiochi, inclusi i giochi indie e i titoli realizzati con RPG Maker.
Come si confrontano quindi i due framework e quale dovrebbero scegliere gli sviluppatori?
Electron e NW.js a colpo d'occhio
Entrambi i framework consentono agli sviluppatori di creare applicazioni desktop con tecnologie web, ma affrontano in modo diverso l'architettura delle applicazioni, l'integrazione nativa e la sicurezza.
| Caratteristica | Electron | NW.js |
|---|---|---|
| Prima introduzione | 2013 | 2011–2012 |
| Sviluppatore originale | GitHub | Intel Open Source Technology Center |
| Governance ed ecosistema | OpenJS Foundation, con importanti contributi aziendali | Gestito dalla comunità, con origini in Intel |
| Motore del browser | Chromium | Chromium |
| Runtime JavaScript | Node.js | Node.js |
| Piattaforme desktop | macOS, Windows, Linux | macOS, Windows, Linux |
| Architettura | Processo principale e processi di rendering | Architettura Chromium con integrazione diretta di Node.js |
| Accesso a Node.js | Processo principale e integrazione controllata nei processi di rendering | Accesso diretto dalle pagine dell'applicazione abilitate |
| Dimensioni dell'applicazione | Relativamente elevate | Relativamente elevate |
| Prestazioni | Dipendono dall'applicazione | Dipendono dall'applicazione |
| Sicurezza | Sandboxing, isolamento del contesto, IPC | Accesso a Node configurabile e isolamento dei frame |
| Adozione | Ampiamente utilizzato nelle applicazioni desktop di largo utilizzo | Ecosistema più piccolo, adozione significativa nei videogiochi |
| Supporto mobile | Nessun supporto ufficiale | Nessun supporto ufficiale |
Le differenze più importanti non riguardano le prestazioni o le dimensioni delle applicazioni. Entrambi i framework includono Chromium e Node.js, quindi i loro requisiti in termini di risorse sono sostanzialmente comparabili. Le differenze principali riguardano invece l'architettura, i confini di sicurezza, gli strumenti di sviluppo e il supporto dell'ecosistema.
Storia: NW.js è arrivato prima, ma Electron è diventato più popolare
NW.js è stato uno dei primi progetti a dimostrare che gli sviluppatori potevano combinare Node.js con le tecnologie dei browser per creare applicazioni desktop. Originariamente chiamato node-webkit, è nato nell'Open Source Technology Center di Intel, con l'avvio dello sviluppo nel 2011 e le prime versioni pubbliche disponibili nel 2012.
La sua idea centrale era semplice: consentire al codice JavaScript eseguito in un ambiente simile a un browser di accedere direttamente ai moduli Node.js. Questo permetteva di sviluppare applicazioni desktop utilizzando tecnologie web familiari, senza creare un'interfaccia nativa tradizionale.
Electron è arrivato nel 2013 con il nome di Atom Shell. GitHub lo ha sviluppato per il proprio editor di codice Atom, entrato in beta pubblica nel 2014. Electron è stato progettato come alternativa ai framework desktop basati sul web disponibili all'epoca, tra cui node-webkit e Chromium Embedded Framework.
Sebbene entrambi i framework condividessero l'obiettivo di rendere lo sviluppo desktop accessibile agli sviluppatori web, Electron ha adottato un'architettura diversa, separando le funzionalità a livello di applicazione dai contenuti web. Questo approccio è diventato sempre più interessante man mano che gli sviluppatori iniziavano a creare applicazioni più complesse.
Electron è stato successivamente adottato da startup e grandi aziende tecnologiche. GitHub, Slack, Microsoft e altre organizzazioni hanno contribuito al suo sviluppo e al suo ecosistema. Nel 2019 Electron è entrato nella OpenJS Foundation, passando dalla proprietà di GitHub a una fondazione open source neutrale.
Oggi Electron opera secondo un modello di governance consolidato, con gruppi di lavoro dedicati a sicurezza, rilasci, API, aggiornamenti di Chromium e Node.js e altre aree. Ingegneri legati a organizzazioni come Microsoft e Slack hanno partecipato alla sua manutenzione e alla sua governance.
Anche NW.js ha origini aziendali, essendo stato creato in Intel. Tuttavia, il suo ecosistema attuale è più piccolo e non presenta la stessa ampiezza di partecipazione visibile da parte delle grandi aziende di software desktop.
Questa storia illustra una distinzione importante: arrivare per primi non garantisce una posizione dominante nel lungo periodo. NW.js ha contribuito ad affermare il concetto di creare applicazioni desktop con Chromium e Node.js, ma Electron ha attirato un ecosistema più ampio di sviluppatori, manutentori e aziende che lo hanno adottato.
Per ulteriori informazioni, consulta la retrospettiva sui 10 anni di Electron, l'ingresso di Electron nella OpenJS Foundation e la storia del progetto node-webkit.
Architettura: processi principali e integrazione diretta di Node.js
Electron utilizza un'architettura multiprocesso ereditata da Chromium. Ogni applicazione Electron ha un processo principale responsabile della gestione delle finestre, degli eventi del ciclo di vita dell'applicazione, delle integrazioni con il sistema operativo e delle funzionalità privilegiate. I contenuti web vengono eseguiti in processi di rendering separati, che comunicano con il processo principale tramite comunicazione tra processi (IPC).
Questo crea una distinzione tra la logica dell'applicazione e il codice dell'interfaccia utente. Un processo di rendering si comporta in genere come un ambiente browser convenzionale, mentre il processo principale gestisce le operazioni che richiedono l'accesso a Node.js o alle API native. Electron fornisce inoltre script di precaricamento e l'API contextBridge, consentendo agli sviluppatori di esporre funzionalità selezionate al processo di rendering senza concedere un accesso illimitato a Node.js.
NW.js adotta un approccio diverso. È stato progettato per rendere le funzionalità di Node.js disponibili direttamente all'interno delle applicazioni web. In una pagina dell'applicazione abilitata, gli sviluppatori possono accedere ai moduli Node.js utilizzando API JavaScript familiari, senza predisporre un'interfaccia IPC separata per ogni operazione.
Ad esempio, un'applicazione NW.js distribuita con file locali può utilizzare Node.js direttamente da uno script eseguito nella sua pagina:
const fs = require('node:fs');
const content = fs.readFileSync('notes.txt', 'utf8');
document.body.textContent = content;
Questa semplicità è uno dei vantaggi distintivi di NW.js. Gli sviluppatori possono combinare le API del browser e le funzionalità di Node.js senza dover necessariamente separare il codice in livelli applicativi distinti. NW.js supporta inoltre contesti JavaScript separati e una modalità a contesto misto, offrendo flessibilità nell'interazione tra le funzionalità del browser e quelle di Node.js.
Electron incoraggia generalmente una separazione più esplicita. Per leggere un file dal processo di rendering, una tipica applicazione Electron sicura espone un'operazione limitata tramite uno script di precaricamento e gestisce l'accesso al file system nel processo principale.
Questo approccio richiede codice aggiuntivo, ma rende più esplicito il confine tra le funzionalità privilegiate dell'applicazione e i contenuti web. Nelle applicazioni complesse, questa separazione può migliorare la manutenibilità e rendere più comprensibili le responsabilità in materia di sicurezza.
Nessuna delle due architetture è universalmente migliore. NW.js può risultare più immediato per applicazioni più piccole o progetti che traggono vantaggio dall'integrazione diretta di Node.js. Electron offre una struttura che può essere particolarmente utile quando un'applicazione cresce in complessità.
Prestazioni, utilizzo della memoria e dimensioni delle applicazioni
Poiché sia Electron sia NW.js includono Chromium e Node.js, nessuno dei due framework presenta un vantaggio architetturale intrinseco paragonabile alla differenza di dimensioni tra Electron e Tauri.
Anche un'applicazione semplice realizzata con uno dei due framework deve distribuire un runtime di dimensioni considerevoli. Entrambi i framework possono inoltre creare più processi Chromium, aumentando il consumo di memoria ma contribuendo a isolare i carichi di lavoro e migliorare la reattività.
L'integrazione diretta di NW.js tra Node.js e l'ambiente browser può ridurre la necessità di IPC in alcune operazioni. A seconda della configurazione dei contesti, il codice JavaScript può interagire direttamente con le funzionalità di Node.js, semplificando alcune operazioni e potenzialmente riducendo il sovraccarico della comunicazione.
Electron separa le operazioni privilegiate dal codice di rendering, introducendo l'IPC quando si attraversano i confini tra processi. Questo, però, non significa che Electron sia intrinsecamente più lento. Il sovraccarico aggiuntivo può essere trascurabile nelle normali interazioni con l'interfaccia utente, e la separazione può aiutare a mantenere le attività backend più onerose lontane dal processo di rendering.
In pratica, le prestazioni dell'applicazione dipendono in larga misura da come gli sviluppatori utilizzano Chromium, gestiscono i processi in background, implementano il rendering e gestiscono lo stato dell'applicazione.
Per confronti significativi, gli sviluppatori dovrebbero valutare:
- Tempo di avvio: quanto rapidamente l'applicazione diventa interattiva.
- Utilizzo della memoria: sia il consumo a riposo sia quello con carichi di lavoro realistici.
- Utilizzo della CPU: il consumo di risorse durante il rendering e le operazioni in background.
- Dimensioni dell'applicazione: dimensioni del download e spazio di archiviazione richiesto dopo l'installazione.
- Reattività: il comportamento dell'interfaccia durante le attività che richiedono molte risorse.
Nessuno dei due framework dovrebbe essere considerato categoricamente più veloce senza effettuare misurazioni su un'applicazione rappresentativa. Le differenze nelle versioni di Chromium, nelle configurazioni di compilazione, nei moduli nativi e nell'architettura dell'applicazione possono influenzare i risultati dei benchmark.
Per gli sviluppatori che puntano soprattutto a ridurre le dimensioni dell'applicazione, passare da Electron a NW.js difficilmente offrirà i risparmi drastici associati al passaggio a un framework basato sulla webview di sistema.
Sicurezza: approcci diversi all'accesso nativo
La sicurezza è una delle differenze più importanti tra Electron e NW.js, in particolare per le applicazioni che visualizzano siti web remoti o altri contenuti non attendibili.
Electron offre diversi meccanismi di sicurezza, tra cui il sandboxing di Chromium, l'isolamento del contesto e la possibilità di disabilitare l'integrazione di Node.js nei processi di rendering. Le versioni moderne di Electron abilitano importanti protezioni per impostazione predefinita, e la documentazione sulla sicurezza del progetto raccomanda vivamente di mantenere le API native privilegiate separate dai contenuti remoti.
NW.js consente un accesso più diretto a Node.js dalle pagine dell'applicazione abilitate, semplificando lo sviluppo ma richiedendo anche un'attenta valutazione dei contenuti a cui vengono concessi tali privilegi.
NW.js distingue tra frame normali e frame con Node abilitato. Supporta inoltre impostazioni come node-remote per controllare quali URL remoti possono accedere alle funzionalità di Node.js. Il suo componente webview può visualizzare contenuti ospitati in un processo separato senza concedere loro automaticamente i privilegi dell'applicazione.
| Aspetto di sicurezza | Electron | NW.js |
|---|---|---|
| Accesso privilegiato a Node.js | Principalmente processo principale e bridge controllati | Disponibile direttamente nei contesti dell'app abilitati |
| Isolamento dei contenuti remoti | Processi di rendering in sandbox e contenuti web | Frame normali e webview isolate |
| Esposizione delle API native | IPC e contextBridge | Contesti Node e accesso configurabile |
| Sandboxing di Chromium | Supportato con impostazioni predefinite sicure | Dipende dal tipo di frame e dalla configurazione |
| Responsabilità dello sviluppatore | Convalidare IPC, navigazione, autorizzazioni e API esposte | Controllare frame privilegiati, accesso a Node e contenuti remoti |
Né Electron né NW.js dovrebbero essere considerati automaticamente browser sicuri per uso generale. Le applicazioni che visualizzano siti web arbitrari di terze parti richiedono controlli di sicurezza aggiuntivi, indipendentemente dal framework.
Per le applicazioni sviluppate interamente attorno a contenuti locali attendibili, l'integrazione diretta di NW.js può essere comoda. Per le applicazioni che richiedono una forte separazione tra codice privilegiato e contenuti web non attendibili, l'architettura di Electron può rendere questi confini più espliciti.
In definitiva, la sicurezza dipende dalla progettazione dell'applicazione, dalla configurazione, dalla gestione delle dipendenze e dalla rapidità con cui gli sviluppatori applicano gli aggiornamenti di sicurezza.
Adozione: Electron domina le applicazioni desktop di largo utilizzo
Una delle differenze più significative tra Electron e NW.js è la loro adozione tra gli sviluppatori di software desktop.
Nonostante sia il progetto più giovane, Electron si è affermato come framework di riferimento per le applicazioni desktop in produzione. La sua adozione comprende strumenti di sviluppo, piattaforme di comunicazione, software per la produttività, applicazioni di progettazione e utilità aziendali.
Alcuni esempi noti includono:
| Azienda | Applicazione Electron |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| GitHub | GitHub Desktop |
| Signal | Signal Desktop |
| Postman | Postman |
Questi prodotti dimostrano che Electron può supportare applicazioni desktop sofisticate utilizzate da milioni di persone. La sua adozione ha inoltre contribuito alla nascita di un ampio ecosistema di librerie, documentazione, strumenti di debug e soluzioni per la creazione di pacchetti.
La partecipazione aziendale è un altro vantaggio. Electron è stato originariamente sviluppato da GitHub e ha successivamente attirato contributi da ingegneri di grandi aziende tecnologiche. La sua governance attraverso la OpenJS Foundation offre una struttura organizzativa per la collaborazione, la manutenzione della sicurezza, la gestione dei rilasci e lo sviluppo a lungo termine.
Questo non significa che ogni azienda che utilizza Electron contribuisca direttamente al framework, né garantisce che Electron sarà sempre mantenuto meglio. Tuttavia, un framework ampiamente utilizzato con un gruppo diversificato di soggetti commerciali coinvolti può beneficiare di investimenti ingegneristici condivisi e dell'esperienza maturata in ambienti di produzione reali.
NW.js presenta un profilo di adozione diverso. Pur essendo stato utilizzato per creare applicazioni desktop, relativamente poche applicazioni moderne di rilievo per la produttività o per le aziende dichiarano pubblicamente di utilizzare NW.js come framework. Molte applicazioni tradizionalmente citate nelle vetrine di NW.js sono progetti datati, il che rende tali elenchi meno utili per valutarne l'adozione attuale.
Questo non significa che NW.js sia abbandonato o inutilizzato. Continua a ricevere versioni che incorporano aggiornamenti di Chromium e Node.js. Tuttavia, il suo ecosistema visibile nel software desktop di largo utilizzo è notevolmente più piccolo di quello di Electron.
Per gli sviluppatori che devono scegliere un framework per una nuova applicazione commerciale, questa distinzione è importante. Un ecosistema più ampio rende generalmente più facile trovare soluzioni esistenti, assumere sviluppatori con esperienza pertinente e risolvere problemi in produzione.
La popolarità di Electron non lo rende tecnicamente superiore sotto ogni aspetto, ma la sua maggiore adozione e la partecipazione aziendale sono vantaggi pratici da non trascurare.
Puoi trovare altri esempi nella vetrina ufficiale delle applicazioni Electron.
Dove NW.js è ancora popolare: i giochi indie
Sebbene NW.js non sia molto rappresentato tra le principali applicazioni moderne per la produttività, continua ad avere una presenza significativa nello sviluppo di videogiochi, in particolare tra gli sviluppatori indipendenti.
Uno dei motivi è la sua integrazione con strumenti di sviluppo di giochi come RPG Maker MV. I giochi creati con RPG Maker MV possono utilizzare NW.js come runtime desktop, consentendo ai giochi basati su HTML5 e JavaScript di essere eseguiti come applicazioni autonome.
Questo significa che gli sviluppatori possono utilizzare NW.js indirettamente attraverso il proprio motore di gioco, anziché sceglierlo come framework desktop per uso generale.
Esistono inoltre riscontri indipendenti del fatto che NW.js continui a essere presente in giochi di nuova pubblicazione. SteamDB tiene traccia dei giochi che utilizzano NW.js esaminando automaticamente le firme tecnologiche nei file distribuiti. Il suo database include giochi pubblicati nel 2025 e nel 2026, fornendo riscontri di un utilizzo continuato senza affidarsi interamente a vetrine di applicazioni potenzialmente obsolete.
Tra gli esempi associati a NW.js figurano:
| Gioco | Genere | Uscita su Steam |
|---|---|---|
| Look Outside | GDR horror | Marzo 2025 |
| OMORI | GDR | Dicembre 2020 |
| CrossCode | GDR d'azione | Settembre 2018 |
| Fear & Hunger | GDR horror | Dicembre 2018 |
| Ib | Avventura horror | Aprile 2022 |
| Saihate Station | Avventura | Marzo 2025 |
| Sheepy: A Short Adventure | Gioco a piattaforme | Febbraio 2024 |
Fonte: rilevamento della tecnologia NW.js di SteamDB.
SteamDB identifica automaticamente le tecnologie dai file dei giochi, quindi i singoli rilevamenti possono contenere errori o rappresentare una dipendenza inclusa anziché un runtime scelto deliberatamente dallo sviluppatore. La presenza di NW.js, inoltre, non permette di stabilire quale versione del framework utilizzi un gioco o se il suo sviluppatore la mantenga attivamente aggiornata.
Ciononostante, questi esempi dimostrano che NW.js rimane parte dell'ecosistema moderno dello sviluppo di videogiochi.
Questo crea una distinzione interessante tra i due framework. Electron è molto visibile nelle applicazioni desktop di largo utilizzo, in particolare negli strumenti di produttività e sviluppo. NW.js ha una presenza minore in queste categorie, ma continua a comparire nei giochi sviluppati in modo indipendente.
Per gli sviluppatori che creano software aziendale, strumenti di comunicazione o applicazioni complesse per la produttività, l'ecosistema di Electron può essere più pertinente. Per chi lavora con RPG Maker o si occupa della manutenzione di giochi costruiti attorno a NW.js, il framework più vecchio rimane una scelta consolidata e pratica.
Esperienza di sviluppo, strumenti e manutenzione a lungo termine
Entrambi i framework supportano tecnologie frontend moderne e pacchetti Node.js, risultando accessibili agli sviluppatori che conoscono lo sviluppo web. Tuttavia, Electron ha un ecosistema considerevolmente più ampio dedicato al software desktop per uso generale.
NW.js offre un modello di sviluppo relativamente semplice. Un'applicazione di base può essere definita utilizzando un manifest package.json e un punto di ingresso HTML. Gli sviluppatori possono accedere ai moduli Node.js direttamente dalle pagine dell'applicazione abilitate e utilizzare le API di NW.js per gestire finestre, menu, icone nell'area di notifica e altre funzionalità desktop.
Electron richiede in genere una maggiore struttura iniziale. Gli sviluppatori creano un punto di ingresso per il processo principale, configurano le finestre dell'applicazione e gestiscono la comunicazione tra il processo principale e quelli di rendering. Questo può sembrare più complicato per le applicazioni piccole, ma incoraggia anche a organizzare le funzionalità dell'applicazione in livelli distinti.
Electron beneficia di strumenti consolidati come Electron Forge ed electron-builder, che forniscono soluzioni per creare pacchetti, firmare, distribuire e aggiornare le applicazioni. La sua ampia adozione significa inoltre che gli sviluppatori possono trovare più esempi e discussioni della comunità sui problemi avanzati dello sviluppo desktop.
NW.js offre strumenti per la creazione di pacchetti come nw-builder e supporta la preparazione manuale dei pacchetti. Espone inoltre API derivate dall'architettura delle applicazioni e delle estensioni di Chromium, che possono essere interessanti per i progetti che utilizzano già tali API.
Entrambi i framework richiedono agli sviluppatori di gestire le differenze tra sistemi operativi, la firma del codice, la compatibilità dei moduli nativi e gli aggiornamenti delle applicazioni. Nessuno dei due elimina la complessità della distribuzione di software desktop in produzione.
Le dimensioni e la composizione dell'ecosistema diventano particolarmente importanti per la manutenzione a lungo termine. I team che sviluppano applicazioni commerciali possono aver bisogno di soluzioni per la firma del codice, gli aggiornamenti automatici, la segnalazione degli arresti anomali, l'accessibilità, le integrazioni native e i bug specifici delle piattaforme.
La maggiore adozione di Electron tra le grandi aziende di software rende più facile trovare pratiche consolidate e soluzioni riutilizzabili per molti di questi requisiti. NW.js rimane valido, ma gli sviluppatori potrebbero trovare meno esempi o integrazioni mantenute per funzionalità desktop specializzate.
Per un progetto destinato a essere mantenuto per molti anni, la maturità dell'ecosistema e gli investimenti continuativi meritano tanta considerazione quanto le API del framework o i risultati dei benchmark.
Perché in WebCatalog scegliamo Electron
In WebCatalog abbiamo scelto Electron perché la sua architettura corrisponde da vicino ai requisiti dei nostri prodotti. WebCatalog consente agli utenti di trasformare i siti web in applicazioni desktop, gestire più account in modo indipendente e organizzare le proprie applicazioni su macOS, Windows e Linux.
A differenza di chi sviluppa un'applicazione desktop convenzionale con un frontend interamente sotto il proprio controllo, noi dobbiamo supportare siti web creati da migliaia di sviluppatori diversi. Questi siti possono basarsi su sistemi di autenticazione, meccanismi di archiviazione, API del browser e funzionalità multimediali differenti, oltre che su applicazioni JavaScript complesse.
Sia Electron sia NW.js utilizzano Chromium, quindi offrono vantaggi simili in termini di compatibilità del motore del browser. Per noi, la differenza riguarda il livello di controllo che il framework offre sulle finestre dell'applicazione, sulle sessioni del browser, sulla navigazione, sulle autorizzazioni e sulla separazione tra codice privilegiato dell'applicazione e contenuti remoti.
Electron fornisce un insieme maturo di API per queste esigenze. Le sue interfacce BrowserWindow, webContents e session ci consentono di gestire il comportamento del browser a un livello relativamente basso. Le partizioni persistenti delle sessioni sono particolarmente importanti, perché consentono agli utenti di mantenere l'accesso a più account sullo stesso sito web senza condividere cookie e altri dati di sessione.
Anche NW.js supporta webview incorporate, gestione dei cookie e partizioni di archiviazione, quindi queste funzionalità non sono esclusive di Electron. Tuttavia, il processo applicativo dedicato di Electron e le sue API consolidate per la gestione del browser offrono un'architettura adatta alle nostre esigenze.
La sicurezza è un altro aspetto importante. Poiché WebCatalog visualizza siti web di terze parti che non controlliamo, dobbiamo separare con attenzione i contenuti remoti dalle funzionalità privilegiate dell'applicazione. Il modello a processi di Electron, l'isolamento del contesto e i meccanismi IPC ci aiutano a mantenere questa separazione, anche se dobbiamo comunque implementare e mantenere autonomamente controlli di sicurezza adeguati.
Infine, l'ecosistema di Electron rende più pratici lo sviluppo e la manutenzione multipiattaforma. Le nostre applicazioni devono funzionare su macOS, Windows e Linux, con supporto per funzionalità specifiche delle piattaforme, creazione di pacchetti, firma e aggiornamenti. Gli strumenti, la documentazione e l'ampia adozione di Electron in contesti reali forniscono una base solida per questo lavoro.
Apprezziamo anche l'ecosistema di sviluppo a lungo termine di Electron. La partecipazione delle grandi aziende tecnologiche e la sua governance attraverso la OpenJS Foundation ci danno maggiore fiducia nella disponibilità di risorse tecniche, manutenzione della sicurezza e supporto della comunità man mano che i nostri prodotti evolvono.
Riconosciamo gli svantaggi di Electron, in particolare le dimensioni delle applicazioni e i requisiti in termini di risorse. Anziché sostituire il framework, continuiamo a esplorare modi per ridurre il sovraccarico non necessario. Ad esempio, abbiamo implementato cloni APFS per ridurre l'utilizzo del disco delle applicazioni Mac generate.
La nostra decisione non si basa sulla convinzione che NW.js sia incapace di supportare software sofisticato. Entrambi i framework offrono l'uniformità di Chromium che apprezziamo. Per WebCatalog, l'architettura di Electron, i controlli di sicurezza, la sua maggiore adozione nelle applicazioni di largo utilizzo e l'ecosistema ingegneristico consolidato lo rendono la soluzione più adatta.
Dove NW.js continua ad avere senso
Sebbene Electron abbia un ecosistema più ampio, NW.js conserva alcuni vantaggi significativi che gli sviluppatori dovrebbero considerare.
La sua caratteristica più distintiva è la possibilità di accedere a Node.js direttamente dai contesti del browser abilitati. Per gli sviluppatori che convertono un'applicazione web esistente in un'applicazione desktop, questo può offrire un modo comodo per introdurre l'accesso al file system, le integrazioni con il sistema operativo e altre funzionalità native senza progettare un livello di comunicazione separato.
NW.js può essere una buona scelta quando:
- Si sviluppano giochi con una toolchain esistente basata su NW.js. Gli sviluppatori che utilizzano RPG Maker MV o mantengono progetti che dipendono da NW.js potrebbero avere pochi motivi per cambiare framework.
- Si desidera un'integrazione diretta di Node.js. L'applicazione può trarre vantaggio dall'accesso diretto alle funzionalità di Node.js all'interno della propria interfaccia attendibile.
- L'applicazione è relativamente semplice. Un progetto più piccolo potrebbe non aver bisogno della separazione più esplicita di Electron tra logica del processo principale e logica di rendering.
- Il progetto utilizza già NW.js. La migrazione a Electron potrebbe offrire pochi vantaggi se l'applicazione esistente è stabile e ben mantenuta.
- Sono importanti specifiche API delle applicazioni Chromium. NW.js fornisce accesso alle API di Chrome supportate, che possono essere utili per particolari applicazioni.
NW.js continua inoltre a essere mantenuto attivamente. I suoi aggiornamenti continui di Chromium dimostrano che evolve insieme alla piattaforma del browser.
Per gli sviluppatori che mantengono un'applicazione o un gioco NW.js esistente, il passaggio a Electron richiederebbe una valutazione delle differenze architetturali, delle modifiche alla creazione dei pacchetti e dei requisiti di compatibilità. In assenza di un chiaro vantaggio tecnico o commerciale, mantenere il framework esistente può essere più pratico.
Electron o NW.js: quale scegliere?
Entrambi i framework sono adatti alla creazione di applicazioni desktop multipiattaforma. Per i nuovi progetti, la scelta dipende in larga misura da come gli sviluppatori vogliono strutturare il codice e da quale ecosistema supporta meglio le loro esigenze.
| La tua priorità | Punto di partenza migliore | Perché |
|---|---|---|
| Applicazioni desktop grandi e complesse | Electron | Architettura ed ecosistema consolidati |
| Software aziendale o per la produttività di largo utilizzo | Electron | Adozione molto più ampia in queste categorie |
| Ecosistema a lungo termine e partecipazione aziendale | Electron | OpenJS Foundation e contributi di importanti aziende del settore |
| Giochi realizzati con RPG Maker MV | NW.js | Integrazione e toolchain consolidate |
| Accesso diretto a Node.js dalle pagine dell'applicazione | NW.js | Caratteristica architetturale fondamentale |
| Separazione esplicita tra interfaccia utente e codice privilegiato | Electron | Modello principale/rendering e IPC |
| Ampia disponibilità di strumenti per la creazione di pacchetti e la distribuzione | Electron | Ecosistema di strumenti maturo |
| Applicazione NW.js esistente | NW.js | Evita migrazioni non necessarie |
| Uniformità di Chromium tra le piattaforme desktop | Entrambi | Entrambi includono Chromium |
| Dimensioni minime dell'applicazione | Nessuno ha un chiaro vantaggio | Entrambi includono Chromium e Node.js |
| Gestione delle sessioni e delle finestre del browser | Electron | API mature e dedicate |
| Ampie risorse ed esempi della comunità | Electron | Maggiore adozione nelle applicazioni di largo utilizzo |
Per la maggior parte dei team che iniziano a sviluppare una nuova applicazione desktop di una certa portata, Electron è la scelta predefinita più solida. La sua architettura, l'ecosistema, le indicazioni sulla sicurezza, la partecipazione aziendale e l'ampia adozione in produzione lo rendono un framework pratico per lo sviluppo a lungo termine.
NW.js merita ancora di essere preso in considerazione per i progetti che traggono vantaggio dall'integrazione diretta di Node.js, per i flussi di sviluppo di videogiochi che già ne dipendono o per basi di codice NW.js consolidate. Può essere più semplice per determinati casi d'uso, e la sua base Chromium offre un'ampia compatibilità con la piattaforma web.
Gli sviluppatori dovrebbero inoltre ricordare che nessuno dei due framework è particolarmente leggero. Se le dimensioni ridotte dell'applicazione e un basso consumo di risorse di base sono le priorità principali, può valere la pena considerare alternative come Tauri.
Considerazioni finali
Electron e NW.js condividono più somiglianze che differenze. Entrambi combinano Chromium e Node.js per consentire agli sviluppatori di creare applicazioni desktop multipiattaforma utilizzando tecnologie web familiari. Entrambi supportano framework JavaScript moderni, l'integrazione nativa con il sistema operativo ed esperienze desktop sofisticate.
NW.js è arrivato per primo, introducendo il proprio approccio alla combinazione di Node.js con le tecnologie web prima che Electron esistesse. Tuttavia, Electron è successivamente diventato il framework più ampiamente adottato per le applicazioni desktop di largo utilizzo, beneficiando dell'investimento iniziale di GitHub, dei contributi di grandi aziende tecnologiche e della governance attraverso la OpenJS Foundation.
I loro modelli di adozione sono nettamente diversi. Electron è alla base di popolari applicazioni per la produttività, la comunicazione e lo sviluppo utilizzate da milioni di persone. NW.js è meno visibile in quel mercato, ma continua ad avere una presenza significativa nei videogiochi indie, inclusi titoli basati su RPG Maker e giochi pubblicati di recente.
In WebCatalog facciamo la stessa scelta di framework di molti importanti sviluppatori di software desktop. Electron ci offre l'uniformità di Chromium, le funzionalità di gestione del browser, l'architettura di sicurezza e gli strumenti multipiattaforma necessari per supportare una grande varietà di applicazioni web su macOS, Windows e Linux.
NW.js non è obsoleto, e il suo utilizzo continuato nello sviluppo di videogiochi dimostra che rimane utile. Ma per gli sviluppatori che iniziano una nuova applicazione desktop per uso generale, l'ecosistema più ampio di Electron, gli strumenti consolidati, la partecipazione aziendale e la comunità più numerosa lo rendono la scelta predefinita più pratica.
In definitiva, la scelta migliore dipende dai requisiti dell'applicazione, dall'esperienza del team di sviluppo e dai costi di manutenzione del software nel lungo periodo.
