L’arrivo del supporto desktop: cosa cambia per gli sviluppatori

Il progetto Deno, nato per offrire un’alternativa moderna a Node.js, espande il proprio raggio d’azione. Con il prossimo aggiornamento maggiore, il runtime JavaScript/TypeScript includerà nuovi comandi per generare applicazioni desktop multipiattaforma. La promessa è semplice: partire da un file TypeScript o da framework come Next.js, Astro, Deno Fresh, TanStack Start o Vite SSR e ottenere un eseguibile nativo per Windows, macOS e Linux.

La mossa ricalca in parte il terreno già battuto da Electron, ma con una differenza sostanziale: invece di imbarcare sempre una versione completa di Chromium, Deno Desktop utilizza per default il WebView nativo del sistema operativo. Questo cambia le carte in tavola per chi distribuisce software aziendale, utility leggere o tool interni.

WebView, CEF o “Raw”: le tre anime dell’impacchettamento

La compilazione con WebView produce binari sorprendentemente contenuti. In un test rapido su macOS, l’applicazione occupava circa 68,5 MB, contro i 308,9 MB della variante con Chromium Embedded Framework (CEF), opzione comunque disponibile. La documentazione stima una dimensione tipica del CEF intorno ai 150 MB, ma i numeri reali possono essere più alti. L’avvio risulta più rapido con WebView.

Il rovescio della medaglia è la prevedibilità del rendering. Il WebView si appoggia al motore del browser installato sulla macchina, che può essere datato o diverso da piattaforma a piattaforma. Su macOS il legame con Safari introduce particolari criticità. Chi sceglie CEF ottiene invece un comportamento identico ovunque, pagando un sovrapprezzo in termini di megabyte e di risorse.

Esiste una terza via: la modalità “Raw”. Rinuncia del tutto al motore web: Deno fornisce la gestione delle finestre, mentre la UI viene disegnata con WebGPU, la libreria Skia o un sistema di rendering personalizzato. Una scelta estrema, adatta a chi vuole il massimo controllo grafico e nessuna dipendenza da browser.

Leggerezza sotto esame: perché 68 MB valgono più di 300

Le dimensioni contano, e non solo per l’utente finale. In contesti enterprise dove il parco macchine è ampio e l’aggiornamento frequente, ogni megabyte si riflette su banda, tempi di distribuzione e occupazione di storage. Ridurre un pacchetto da oltre 300 a meno di 70 MB può tradursi in un risparmio sensibile sul TCO, specie se moltiplicato per centinaia di postazioni.

Dal punto di vista della sovranità dei dati, Deno Desktop inserisce un server web locale che consente di portare applicazioni web in un eseguibile autosufficiente. Questo avvicina il modello a uno stack on-premise: l’applicazione vive interamente sulla macchina, senza dipendenze da servizi cloud. Per team che operano in ambienti con restrizioni di rete o esigenze di conformità, è un tassello interessante, anche se al momento la maturità degli strumenti di dialogo con il sistema operativo (file picker nativo, clipboard dedicata) è ancora parziale.

Il fardello di Node.js e il costo dell’interoperabilità

Accanto alle novità tecniche, la domanda di fondo è se Deno Desktop aiuterà il progetto a guadagnare quote di mercato. L’ecosistema Node.js è così radicato che Deno ha dovuto progressivamente aggiungere livelli di compatibilità, assorbendo tempo e risorse che potevano andare altrove. Un utente di lunga data, Hong Minhee, ha riassunto il sentimento: inizialmente Deno piaceva perché eliminava il dolore di Node.js: “No configuration files, no node_modules, no agonizing over which package manager to use.” Ora invece sembra rincorrere quel mondo, mentre Node.js stesso ha introdotto funzionalità come la compatibilità con TypeScript.

Il supporto desktop può essere un nuovo argomento a favore di Deno, a patto che funzioni in modo stabile. I primi test mostrano già qualche ruga: su macOS con WebView il pulsante di chiusura della finestra non rispondeva e l’integrazione con alcuni framework web ha richiesto lavoro extra.

Controllo locale e trade-off: cosa osserva AI‑RADAR

Per chi valuta architetture di deployment on-premise, l’approccio di Deno Desktop merita attenzione. La scelta del WebView nativo abbatte l’ingombro e semplifica la gestione, ma introduce un fattore di rischio sulla coerenza dell’esperienza tra macchine diverse. In un parco aziendale standardizzato, con versioni del sistema operativo sotto controllo, questo rischio può essere accettabile. In ambienti più eterogenei, la modalità CEF offre uniformità a fronte di un costo maggiore in risorse.

La modalità “server locale” avvicina il modello a quello di applicazioni self-hosted, un principio caro a chi progetta infrastrutture dove i dati non devono uscire dal perimetro aziendale. Tuttavia, la mancanza di API mature per file system e clipboard indica che la piattaforma è ancora in costruzione. Deno Desktop non è un rivale maturo di Electron o di Tauri, ma un promemoria della tensione tra leggerezza, controllo e compatibilità.

La strada è segnata: se il team riuscirà a bilanciare l’energia spesa per tallonare Node.js con lo sviluppo di funzionalità nuove e robuste, gli sviluppatori potrebbero trovare un motivo in più per guardare a Deno. Altrimenti, il rischio è aggiungere un’altra mattonella su un sentiero dove Node.js e Bun corrono già forte.