Perché Electron pesa: Tauri, React Native e le alternative

Tutto parte da un fastidio di tutti i giorni: Chrome, Arc e gli altri browser basati su Chromium mi mangiano RAM e CPU, al punto da rallentare i processi con cui lavoro davvero. Safari è molto più leggero, ma per sviluppare non basta, perché gli mancano strumenti di DevTools che oggi sono indispensabili.

Da dove nasce l’idea

La prima idea era un browser nativo per macOS, leggero come Safari ma compatibile al 100% con Chromium.

Poi ho scavato, ed è venuto fuori che il peso non sta nell’interfaccia ma nel motore, Blink e V8. Google lo ottimizza un sacco, ma per la velocità e la sicurezza, non per la RAM.

E lì il discorso si è allargato. Anche le app desktop che usiamo tutti i giorni, Slack, Notion, la stessa app di Claude, sono costruite su Electron, e ognuna si porta dietro un Chromium intero. Da qui tre domande:

• perché Electron pesa così tanto;
• perché Tauri e React Native vanno meglio;
• cosa si potrebbe costruire per cambiare le cose.

Electron è un runtime, non un compilatore

Electron non lo puoi «compilare meglio». Ogni app si porta dietro un Chromium intero più Node.js, e il codice dell’app resta JavaScript, HTML e CSS: per girare ha bisogno di un motore web.

Nessun compilatore può togliere Chromium se il codice si aspetta Chromium. Il peso non sta in come è costruita l’app, sta nel motore che le alleghi.

Tauri e React Native: sembrano la stessa cosa, ma non lo sono

Sono due strade diverse: Tauri usa il motore web che c’è già nel sistema, React Native un motore web non lo usa proprio.

Electron

• Motore: Chromium + Node.js dentro l’app.
• Codice: web.
• Peso: pesante, circa 200 MB per app.
• Il prezzo da pagare: ogni app carica il suo Chromium.

Tauri

• Motore: WebView di sistema (WKWebView su Mac), backend in Rust.
• Codice: web.
• Peso: leggero, 5-10 MB per app.
• Il prezzo da pagare: il rendering cambia da un sistema all’altro, e su Mac erediti le stranezze di Safari.

React Native

• Motore: nessun browser, componenti nativi AppKit/UIKit e JavaScript su Hermes.
• Codice: da riscrivere con i componenti di React Native.
• Peso: leggero.
• Il prezzo da pagare: niente DOM né CSS vero, l’interfaccia web non si riusa.

Su Mac WebKit è già nel sistema e già in memoria, ed è per questo che Tauri parte così leggero. E non è roba da hobbisti: Microsoft usa React Native su Mac per parti di Office, con react-native-macos.

Cosa si potrebbe fare davvero

Il compilatore magico non esiste, ma due idee concrete sì, e la prima è la più promettente.

1. Un traduttore da Electron alla webview di sistema

Prende un’app Electron e al posto di Chromium ci mette WKWebView.

• Mappa le API di Electron (finestre, IPC, menu, tray) su quelle native, e Node su un backend leggero.
• Il frontend spesso funziona già in Safari: molte app Electron hanno una versione web che lì gira bene.
• Le parti difficili sono le API di Node e i moduli nativi.
• Uno strumento di conversione automatica rilasciato non l’ho trovato: c’è solo un tentativo annunciato in una issue di VS Code (lo trovi più sotto).

2. Un Chromium condiviso

Oggi cinque app Electron caricano cinque Chromium diversi. Con un runtime comune, come la JRE per Java, il peso si dividerebbe.

Se n’è parlato più volte, ma non si è mai fatto, perché ogni app vuole la sua versione esatta di Chromium.

Tra le due vince il traduttore: ha un problema chiaro, un pubblico che lo sente (gli sviluppatori che odiano Electron, cioè un sacco di gente) e chiede meno lavoro di un browser.

Chi ci ha già provato

Di framework leggeri ce ne sono già tanti, ma sono tutti per app nuove. Un traduttore automatico da Electron rilasciato, ad oggi, non risulta.

Electrobun

WebView di sistema, main process in TypeScript su Bun, ponte nativo in Zig. Versione 1.0 a febbraio 2026, oltre 11.000 stelle su GitHub. È un framework per app nuove: un’app React semplice pesa circa 64 MB contro circa 271 MB con Electron (fonte).

Zero-Native

Shell minima in Zig sopra WKWebView, CEF opzionale. In fase iniziale. Framework per app nuove, binari di pochi MB.

deno desktop

Runtime Deno con CEF incluso oppure WebView di sistema. Disponibile, e ha in programma un runtime CEF condiviso tra app.

Traduttore Electron → Tauri

Conversione in fase di build, senza configurazione. Solo annunciato in una issue di VS Code, nessun rilascio trovato. È la nostra idea 1: lo spazio è ancora vuoto.

WebView2 (Windows)

Chromium di sistema, con runtime condiviso opzionale. Disponibile su Windows: il runtime condiviso esiste già, ma non su Mac.

Runtime Electron condiviso

Un solo Electron per tutte le app. Scartato dal creatore di Electron: chi sceglie Electron taglia i costi di sviluppo, non quelli di chi usa l’app, e Chrome Apps e Adobe AIR sono andati male.

Come lo costruirei

Ok, ma se domani mattina dovessi farlo davvero? Questo è uno studio a tavolino, non un progetto partito: serve a capire dove sono i muri prima di sbatterci contro.

Il principio

Non riscrivere niente che esiste già. Il motore c’è (WKWebView), il guscio leggero c’è (Electrobun o Tauri), un runtime JavaScript leggero che parla quasi tutto Node c’è (Bun). Il traduttore è la colla tra l’app Electron e questi pezzi.

I quattro pezzi

1. Il radiografo. Apre il pacchetto dell’app (l’archivio asar), elenca ogni API di Electron usata, ogni modulo di Node e ogni modulo nativo compilato, e ti dice prima di cominciare cosa si traduce da solo, cosa va sistemato a mano e cosa non si può tradurre.
2. Il finto Electron. Una libreria che risponde a require('electron') con la forma di sempre (BrowserWindow, ipcMain, Menu, Tray, dialog, shell, app), ma sotto chiama le API native del Mac attraverso il guscio leggero. L’app crede di parlare con Electron, e invece parla con il sistema.
3. Il main process su Bun. Il codice Node dell’app gira su Bun, che di Node copre gran parte delle API. I moduli nativi che Bun non digerisce finiscono in un piccolo processo Node a parte, acceso solo quando servono.
4. Il ponte nella pagina. Preload e contextBridge diventano script iniettati in WKWebView (WKUserScript), l’IPC passa da WKScriptMessageHandler e i protocolli personalizzati da WKURLSchemeHandler. Per il frontend non cambia niente.

Dove sbatti

• Le API web che esistono solo in Chromium: WebUSB, WebHID, WebSerial, la cattura dello schermo di desktopCapturer, il tag <webview>. Qui serve una via d’uscita onesta: la finestra che ne ha bisogno si apre con un Chromium (CEF) solo per lei, e il resto dell’app resta leggero.
• Un bersaglio che si muove: Electron esce con una versione nuova ogni otto settimane, quindi il finto Electron deve correrle dietro. Si parte dalle API che usano davvero le app più diffuse, non da tutte.
• Le stranezze di Safari: per accorgersene serve un confronto automatico delle schermate, la stessa app in Chromium e in WebKit, prima di dire che la traduzione è riuscita.

Come lo proverei

Una piattaforma sola, il Mac, e una sola app open source vera da tradurre. Si misura prima e dopo: RAM all’avvio, RAM dopo un’ora di uso, peso del pacchetto. Se i numeri non scendono di brutto, si butta tutto senza rimpianti.

Se scendono, il passo dopo è un comando unico che prende l’app e restituisce il .app tradotto, e solo dopo si apre ad altre app e ad altri sistemi.

Il problema vero non è tecnico

Chi sceglie Electron taglia i costi di sviluppo, non quelli di chi usa l’app, l’abbiamo visto nella tabella qui sopra. Quindi chi lo paga, il traduttore? Lo sviluppatore, che deve volerlo, o chi usa l’app e la vorrebbe leggera? Finché non rispondi a questa domanda hai un esperimento figo, non un prodotto.

Facciamo sempre di più, ottimizziamo sempre meno

Nel 1995 Niklaus Wirth, quello del Pascal, scrisse che il software rallenta più in fretta di quanto l’hardware diventi veloce. Trent’anni dopo ho un Mac che fa cose impensabili, e per tenere aperte cinque chat e due browser va in affanno.

Secondo me il motivo è semplice: una funzione nuova si vede, 150 MB di RAM in meno no. Nessuno sale sul palco per dire che la sua app adesso pesa meno. Anzi, uno l’ha fatto: Apple nel 2008 ha presentato Snow Leopard con una slide che diceva zero funzioni nuove, solo più veloce e più leggero, e la gente se lo ricorda ancora.

Con l’AI che scrive codice a ciclo continuo è ancora peggio, perché aggiungere costa quasi zero, mentre ottimizzare vuol dire capire cosa c’è già, e capire costa tempo.

Io la vedo così: mi viene molto più veloce ideare qualcosa di nuovo partendo da qualcosa che già esiste e funziona. Il traduttore è esattamente questo, non l’ennesimo framework nella lista, ma un modo per rendere leggero quello che usiamo già tutti i giorni.

Quindi?

Il traduttore resta l’idea più promettente, ma per avere senso deve dare più di una migrazione a mano verso Electrobun, che parla già TypeScript. Se no, chi odia Electron fa prima a riscriversi la shell da solo.

E nel frattempo Arc è ancora lì aperto, a mangiarsi la RAM come se niente fosse.