Passa abbastanza tempo su Hacker News o Reddit e prima o poi ti imbatterai nella stessa critica: Electron è pesante, Electron usa troppa memoria e le applicazioni desktop serie dovrebbero essere native.
C'è del vero in questa critica. Le applicazioni Electron hanno generalmente un consumo di risorse di base maggiore perché includono Chromium e Node.js. Un'applicazione nativa progettata con cura può usare meno memoria, avviarsi più velocemente e integrarsi più profondamente con il sistema operativo.
Ma questo dibattito si concentra troppo sul computer e troppo poco sull'azienda che sviluppa il software.
Per la maggior parte degli utenti, la tecnologia alla base di un'applicazione conta ben poco. A loro interessa che funzioni, che sia reattiva, che i bug vengano corretti e che continuino ad arrivare funzionalità utili. Per un'azienda software, una delle proprietà più importanti di uno stack tecnologico è quindi qualcosa che compare raramente nelle tabelle dei benchmark: quanto velocemente il team può sviluppare, distribuire, imparare e migliorare il prodotto?
Per molte applicazioni desktop moderne, Electron è eccezionalmente efficace sotto questo aspetto.
La risorsa scarsa è il tempo degli sviluppatori
L'azienda ideale che sviluppa applicazioni desktop native ha un eccellente team macOS, un altro team che realizza l'applicazione Windows e magari un altro ancora che supporta Linux. Ogni applicazione è attentamente ottimizzata per la propria piattaforma e ogni sviluppatore conosce a fondo il sistema operativo su cui lavora.
La maggior parte delle aziende non può permettersi questo lusso.
Un prodotto desktop potrebbe avere cinque sviluppatori. Potrebbe averne due. Quegli stessi sviluppatori devono realizzare funzionalità, correggere bug, migliorare le prestazioni, rispondere ai clienti, mantenere l'infrastruttura, gestire i cambiamenti dei sistemi operativi e far progredire il prodotto.
Lo sviluppo nativo rende tutto questo più difficile perché macOS, Windows e Linux sono piattaforme realmente diverse. Hanno framework per l'interfaccia utente, API, sistemi di autorizzazione, comportamenti del ciclo di vita, programmi di installazione, meccanismi di aggiornamento, sistemi di notifica, gestione delle finestre e API di accessibilità differenti, oltre ad anni di peculiarità specifiche di ciascuna piattaforma.
Electron cambia questa equazione. Combina Chromium, Node.js e API desktop in un modello applicativo condiviso tra macOS, Windows e Linux. Lo stesso sviluppatore TypeScript può spesso realizzare una funzionalità dall'interfaccia alla logica applicativa e distribuirla su ogni piattaforma desktop. Il codice nativo rimane disponibile quando è davvero necessario, ma diventa l'eccezione anziché il fondamento del prodotto. Electron stesso descrive questo aspetto come uno dei suoi vantaggi principali: un'unica base di codice JavaScript per tutte e tre le principali piattaforme desktop.
Questa differenza si accumula nel corso degli anni. Se ogni funzionalità significativa richiede implementazioni separate per Mac e Windows, l'azienda paga ripetutamente quel costo aggiuntivo legato alle piattaforme: per ogni funzionalità, riprogettazione, esperimento, correzione di bug, miglioramento dell'accessibilità e ottimizzazione delle prestazioni.
Con Electron, gran parte di questo lavoro viene svolta una sola volta.
Electron privilegia la velocità di iterazione
Raramente i prodotti diventano eccellenti perché la prima implementazione era perfetta. Diventano eccellenti attraverso l'iterazione.
Un team rilascia qualcosa. I clienti lo usano. Il team impara. Modifica la funzionalità. Altre persone la usano. Emerge un altro problema. Il team la migliora di nuovo.
Più breve è il ciclo tra idea, implementazione, feedback e miglioramento, più velocemente il prodotto migliora.
Electron è particolarmente efficace nell'accorciare questo ciclo perché si basa su tecnologie che le aziende software usano già ovunque: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js e npm.
Questo significa che le aziende possono condividere molto più del codice sorgente. Possono condividere sviluppatori, componenti dell'interfaccia utente, strumenti, librerie, infrastruttura, approcci ai test e conoscenze interne tra i propri prodotti web e desktop.
Uno sviluppatore frontend non diventa improvvisamente inutile perché l'azienda ha bisogno di aiuto con il client Windows. Uno sviluppatore desktop può contribuire all'applicazione web. Uno sviluppatore TypeScript full-stack può passare da un prodotto all'altro al cambiare delle priorità.
Per un'azienda piccola o media, questa flessibilità può valere molto più di un risparmio di 100 MB di RAM.
Guarda chi usa davvero Electron
Electron viene talvolta descritto come una scorciatoia per le aziende che non vogliono investire in un'applicazione desktop «come si deve». I prodotti realizzati con Electron rendono questa tesi sempre più difficile da sostenere.
Il progetto Electron stesso mette in evidenza prodotti come Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom e Canva. Non si tratta di semplici utilità. Molti sono tra le applicazioni di produttività più sofisticate e utilizzate al mondo.
Visual Studio Code è un esempio particolarmente utile. Microsoft potrebbe realizzare il suo editor di codice di punta con praticamente qualsiasi tecnologia Windows desideri, eppure VS Code usa Electron su Windows, macOS e Linux. Include terminali, debug, server di linguaggio, integrazione con Git, sviluppo remoto, notebook, estensioni ed editor altamente personalizzati.
La domanda interessante non è se Microsoft potrebbe risparmiare memoria realizzando tre versioni native separate. Certo che potrebbe.
La domanda migliore è se VS Code si sarebbe evoluto altrettanto rapidamente, sarebbe rimasto così uniforme tra le piattaforme e avrebbe sviluppato un ecosistema così vasto se ogni funzionalità importante avesse richiesto diverse implementazioni separate.
ChatGPT e Claude mostrano la differenza di approccio
Anche il contrasto tra ChatGPT e Claude è istruttivo.
OpenAI ha inizialmente realizzato per ChatGPT un'applicazione nativa dedicata a macOS. Anthropic, invece, ha sviluppato Claude Desktop su Electron, disponendo fin dall'inizio di una base desktop condivisa tra le piattaforme.
Questa differenza è diventata più importante man mano che i prodotti si sono ampliati. Claude Desktop ha potuto continuare ad aggiungere funzionalità come integrazioni MCP, estensioni e Claude Code nella stessa applicazione multipiattaforma. Anthropic ora supporta Claude Code direttamente nella propria esperienza desktop, comprese più sessioni locali e remote.
In seguito, anche OpenAI ha orientato verso Electron la sua nuova strategia desktop multipiattaforma, ed Electron ora elenca sia ChatGPT sia Claude tra le applicazioni Electron di rilievo.
Sarebbe eccessivo affermare che Electron da solo spieghi la differenza nella velocità di evoluzione dei prodotti. Le dimensioni del team, le priorità, la strategia di prodotto e l'organizzazione interna contano tutte. Ma il vantaggio architetturale è chiaro: una base multipiattaforma condivisa rende più facile distribuire funzionalità su diversi sistemi operativi senza mantenere implementazioni separate.
È esattamente il tipo di vantaggio che acquista più valore man mano che un prodotto desktop cresce.
Evernote ha imparato quanto costa mantenere client separati
Evernote è uno degli esempi storici più chiari di questo problema.
Per anni, Evernote ha mantenuto applicazioni diverse per Mac, Windows, dispositivi mobili e web. Nel tempo, questi prodotti hanno accumulato comportamenti diversi, differenze di rendering, presupposti ereditati dal passato e problemi di sincronizzazione.
Nel 2020, Evernote ha ricostruito le proprie applicazioni Windows e Mac attorno a una base di codice condivisa. L'azienda ha dichiarato che la nuova base avrebbe reso le app più stabili, consentito di correggere i bug più velocemente, permesso di rilasciare funzionalità più spesso e migliorato la sincronizzazione tra le piattaforme.
Quella migrazione non è stata indolore, e alcuni utenti di lunga data non hanno gradito la perdita iniziale di funzionalità specifiche delle singole piattaforme. Ma il motivo per cui Evernote ha intrapreso una riscrittura così costosa è più interessante dei problemi della migrazione stessa.
Quando un prodotto dispone di un editor avanzato, archiviazione offline, ricerca, allegati, collaborazione, attività, calendari e una sincronizzazione complessa, mantenere diverse implementazioni indipendenti diventa sempre più costoso. I bug si manifestano in modo diverso. Il rendering differisce. La logica di sincronizzazione interagisce con architetture locali differenti. Ogni cambiamento significativo del prodotto deve essere propagato attraverso diversi client.
Un'architettura condivisa non fa scomparire i problemi difficili. Permette all'azienda di risolverne di più una sola volta.
Linux potrebbe essere il vantaggio più sottovalutato di Electron
Linux rende ancora più convincente la scelta di Electron.
Supportare Linux adeguatamente è difficile. A differenza di macOS o Windows, il «desktop Linux» non è un'unica piattaforma strettamente controllata. Gli sviluppatori devono gestire distribuzioni, formati di pacchetto, ambienti desktop, stack grafici, librerie di sistema e protocolli di visualizzazione differenti.
Per molte aziende software, la decisione economicamente razionale sarebbe semplicemente non supportare Linux.
Electron cambia il rapporto tra costi e benefici.
Poiché Electron fornisce un ambiente di esecuzione comune per macOS, Windows e Linux, aggiungere il supporto a Linux può essere enormemente più semplice che mantenere un'implementazione nativa separata per Linux. Questo è uno dei motivi per cui oggi gli utenti Linux hanno accesso a molte importanti applicazioni desktop che, in passato, avrebbero potuto non ricevere mai un client Linux ufficiale.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian e molti altri strumenti possono supportare Linux senza mantenere un'applicazione GTK o Qt completamente separata.
Electron si fa inoltre carico di gran parte della complessità specifica di Linux per conto degli sviluppatori di applicazioni. Un buon esempio è il passaggio da X11 a Wayland. I manutentori di Electron hanno descritto come la transizione di Chromium a Wayland abbia di fatto trascinato con sé le applicazioni Electron, riducendo il lavoro sullo stack di visualizzazione che ogni team applicativo avrebbe dovuto svolgere autonomamente.
Senza framework come Electron, molte aziende non realizzerebbero client nativi per Linux. Supporterebbero semplicemente macOS e Windows, lasciando agli utenti Linux una scheda del browser.
Electron ha probabilmente fatto per il software desktop commerciale su Linux più di quanto gli venga riconosciuto.
Anche Microsoft sceglie sempre più spesso le tecnologie web
Microsoft è forse il controesempio più forte all'idea che il software Windows serio debba sempre usare framework nativi Windows per l'interfaccia utente.
Microsoft controlla Windows. Controlla Win32, .NET, WinUI, WebView2 e gran parte della piattaforma su cui lavorano gli sviluppatori. Se lo sviluppo Windows completamente nativo fosse sempre la risposta ovvia, Microsoft sarebbe nella posizione migliore possibile per usarlo ovunque.
Non lo fa.
Visual Studio Code usa Electron. Teams continua a basarsi su React, TypeScript e Chromium anche dopo che Microsoft ha sostituito Electron con un host WebView2 più ottimizzato. Anche il nuovo Outlook per Windows si affida ampiamente alle tecnologie web, e Microsoft descrive esplicitamente questa architettura come un modo per migliorare l'agilità, consentire una distribuzione più rapida delle funzionalità e creare un'esperienza più uniforme.
Teams è particolarmente istruttivo. Microsoft voleva migliorare le prestazioni e ridurre il consumo di risorse, quindi ha cambiato l'architettura. Ma non ha riscritto l'interfaccia utente come un'applicazione tradizionale nativa per Windows.
Ha mantenuto lo stack web e ottimizzato ciò che gli sta attorno.
Questa distinzione conta. Microsoft ha deciso che valeva la pena preservare i vantaggi organizzativi di React, TypeScript e Chromium, pur migliorando le prestazioni in modo deciso.
C'è anche un'altra lezione. Microsoft stessa ha introdotto negli anni molte generazioni di tecnologie per le applicazioni Windows: Win32, WPF, UWP, WinUI e altre. Un'azienda che sceglie il «nativo Windows» non sta necessariamente scegliendo una piattaforma senza tempo. Spesso sta scommettendo su una generazione del framework preferito da Microsoft.
La piattaforma web è diventata, con una certa ironia, uno degli ambienti di destinazione più stabili disponibili per le applicazioni.
Le assunzioni fanno parte dell'architettura
Le scelte dei framework determinano anche chi puoi assumere.
Gli sviluppatori JavaScript e TypeScript rappresentano uno dei bacini di talenti tecnici più grandi del settore. Un'azienda che sviluppa con Electron può attingere a quel bacino anziché aver bisogno di team separati di specialisti esperti in macOS, Windows e Linux.
Gli specialisti dello sviluppo nativo restano preziosi. I prodotti desktop seri hanno ancora bisogno di sviluppatori che conoscano a fondo i sistemi operativi. Ma Electron cambia il numero di specialisti necessari.
Anziché richiedere che la maggior parte dell'applicazione venga realizzata da esperti di piattaforma, puoi mantenere una quantità relativamente piccola di codice di integrazione nativo e lasciare che la maggior parte del team lavori sul prodotto condiviso.
Questo conta ancora di più quando un'azienda ha già un'applicazione web. A volte i componenti React possono essere condivisi. Le librerie TypeScript possono essere riutilizzate. La logica di prodotto può essere trasferita tra web e desktop. Gli sviluppatori possono cambiare team senza imparare un ecosistema completamente diverso.
Anche la gestione del personale diventa meno fragile. Se l'unico sviluppatore che conosce a fondo il tuo client nativo Windows se ne va, sostituire quelle competenze può essere difficile. Con Electron, una parte molto maggiore della base di codice usa tecnologie familiari al resto dell'organizzazione.
Un framework, quindi, non determina soltanto come viene renderizzata un'interfaccia. Influisce su come può essere strutturata l'organizzazione di sviluppo stessa.
Nativo non significa automaticamente software migliore
Gli sviluppatori usano spesso «nativo» quasi come sinonimo di «veloce».
Non lo è.
Le API native danno agli sviluppatori la possibilità di creare un'applicazione molto efficiente. Che il prodotto finale raggiunga davvero questo risultato dipende dall'architettura, dal team, dal budget e dalla quantità di lavoro di ottimizzazione che l'azienda può permettersi.
Un'applicazione nativa può comunque essere lenta, piena di bug, vorace di memoria, incoerente o mantenuta male.
Soprattutto, suddividere un team limitato tra diverse implementazioni native significa dedicare meno ore di sviluppo a ciascuna implementazione.
Immagina che un'azienda abbia sei sviluppatori disponibili per il proprio prodotto desktop. Un'opzione è dividerli tra Mac e Windows, magari lasciando Linux senza supporto. Un'altra è assegnarli quasi tutti e sei a un'unica applicazione Electron condivisa che serva tutte e tre le piattaforme.
Quale approccio dà all'azienda più capacità di sviluppo per migliorare i tempi di avvio, correggere le perdite di memoria, rifinire le interazioni, migliorare l'accessibilità, ridurre gli arresti anomali e rispondere agli utenti?
Non è affatto scontato che le applicazioni native producano il prodotto migliore.
Questo crea un paradosso interessante: un framework che consuma un po' più risorse della macchina può consentire a un'azienda di realizzare un prodotto meglio ottimizzato perché consuma molte meno risorse di sviluppo.
Electron ti offre una piattaforma controllata
Electron ha anche un altro vantaggio facile da trascurare: include l'ambiente di esecuzione Chromium per cui l'applicazione è stata realizzata e su cui è stata testata.
Questo elimina una variabile importante dallo sviluppo multipiattaforma.
I framework basati sulle webview del sistema operativo possono produrre applicazioni più piccole, ma il compromesso è che lo stesso frontend può essere eseguito su WebView2 in Windows, WKWebView in macOS e WebKitGTK in Linux. Questi motori hanno capacità, bug, calendari di rilascio e comportamenti di rendering differenti.
Electron fa una scelta diversa: includere l'ambiente di esecuzione e renderlo parte dell'applicazione.
Sì, questo occupa spazio su disco.
Ma offre agli sviluppatori un ambiente di destinazione molto più uniforme su tre sistemi operativi molto diversi.
L'uniformità ha un enorme valore per lo sviluppo.
Quando Electron non basta, puoi comunque ricorrere al codice nativo
Scegliere Electron non significa rinunciare all'accesso alle funzionalità native.
Le applicazioni Electron possono usare moduli nativi e codice specifico per la piattaforma quando necessario. Questo significa che la scelta architetturale non è davvero tra:
100% nativo e 100% JavaScript.
Per molti prodotti, un modello migliore è:
gran parte dell'applicazione condivisa, con una piccola quantità di codice nativo dove il sistema operativo lo richiede davvero.
Il codice nativo diventa una via d'uscita anziché il fondamento dell'intero prodotto.
Per molte aziende, questa è un'allocazione molto migliore del lavoro di sviluppo.
Agli utenti interessano i prodotti, non i framework
Esiste un piccolo gruppo di utenti tecnicamente esperti che apre Monitoraggio Attività, nota diversi processi Chromium e si lamenta immediatamente del fatto che un'applicazione usi Electron.
La maggior parte degli utenti non lo fa.
Non importa loro che Slack usi Electron. Non importa loro che VS Code sia realizzato con tecnologie web. Non sanno quale framework usi Claude. A loro interessa che il software li aiuti a svolgere il proprio lavoro.
Se un'applicazione si avvia abbastanza velocemente, è reattiva, si arresta raramente in modo anomalo e risolve il problema dell'utente, la tecnologia usata per implementarla è in gran parte invisibile.
È altrettanto vero il contrario. Un'applicazione nativa non diventa automaticamente un buon prodotto perché usa Swift o WinUI.
Il software compete a livello di prodotto, non a livello di framework.
Ottimizza l'azienda, non soltanto il binario
Electron ha costi reali. Usa più spazio su disco. Il suo consumo di memoria di base è solitamente più elevato di quello di una piccola applicazione nativa. Esistono senza dubbio prodotti per i quali questi costi rendono Electron la scelta sbagliata.
Una minuscola utilità nella barra dei menu probabilmente non ha bisogno di Chromium. Un driver di dispositivo certamente no. I giochi, il software audio professionale e le applicazioni estremamente sensibili alla latenza hanno requisiti diversi. E se il tuo prodotto verrà eseguito soltanto su un sistema operativo, lo sviluppo nativo diventa molto più facile da giustificare.
Ma una percentuale enorme del software desktop moderno non rientra in queste categorie.
È costituito da interfacce complesse collegate a servizi cloud. Deve funzionare su Windows e macOS, e sempre più spesso gli utenti si aspettano anche il supporto a Linux. Deve evolversi continuamente. Compete con prodotti che rilasciano cambiamenti ogni settimana. E di solito viene realizzato da un'azienda con un numero finito di sviluppatori.
Per questi prodotti, la produttività degli sviluppatori è parte delle prestazioni dell'applicazione.
Electron permette a un'azienda di assumere attingendo a un bacino di talenti molto più ampio, condividere sviluppatori tra web e desktop, mantenere un'unica applicazione principale anziché diverse, riutilizzare l'ecosistema JavaScript, distribuire funzionalità sui diversi sistemi operativi in modo più uniforme, supportare Linux a un costo che altrimenti sarebbe spesso difficile da giustificare e dedicare più tempo di sviluppo al miglioramento del prodotto anziché al mantenimento di implementazioni parallele.
Puoi misurare facilmente il costo di Electron in megabyte.
I costi dell'alternativa sono più difficili da vedere. Si manifestano sotto forma di sviluppatori aggiuntivi, implementazioni duplicate, cicli di rilascio più lunghi, bug specifici delle piattaforme, difficoltà di assunzione, compartimenti stagni organizzativi, utenti Linux non supportati e funzionalità che impiegano mesi in più per arrivare a tutti.
Questi costi non compaiono in Monitoraggio Attività.
Ma per l'azienda che realizza il software, possono essere considerevolmente maggiori.
L'obiettivo dello sviluppo software non è produrre il binario più piccolo.
È realizzare il miglior prodotto che la tua organizzazione possa distribuire, mantenere e migliorare continuamente.
Per una categoria sorprendentemente ampia di applicazioni desktop, Electron rimane uno dei modi più efficienti per fare esattamente questo.