Cloudflare e Deno: fine di un runtime, inizio di un modello (Workers) davvero mainstream

Negli ultimi anni Deno è stato spesso citato come “il runtime che dovrebbe sostituire Node.js”: TypeScript di prima classe, toolchain integrata (test, lint, format), security model sensato, una visione coerente. Eppure, a livello di adozione reale, la storia è stata molto diversa.

Ora arriva un cambio di rotta netto: Cloudflare integra il team di Deno e dichiara una nuova priorità. Risultato pratico? Il runtime Deno entra in modalità maintenance e Deno Deploy si avvia verso la chiusura, mentre il cuore dell’investimento sembra essere un altro: rendere il modello Workers (e il suo runtime open source workerd) una strada “normale” per costruire server e applicazioni distribuite, anche fuori dall’infrastruttura Cloudflare.

Cosa cambia, concretamente

Le decisioni operative sono chiare:

• Deno Runtime: per circa un anno sono previsti rilasci mensili con sole correzioni di bug e patch di sicurezza. Dopo questo periodo, lo sviluppo del runtime termina. In altre parole: nessuna nuova feature, nessuna re-architettura, nessuna evoluzione di piattaforma.
• Deno Deploy: il servizio viene mantenuto operativo ancora per un periodo limitato (nell’ordine di pochi mesi) prima dello spegnimento.
• GSR (il registry di Deno): continua a esistere e, cosa interessante, si sposta sull’infrastruttura Cloudflare, con prospettive migliori di affidabilità e crescita.
• Rusty V8: continua a essere supportato, con l’obiettivo di integrarlo meglio nell’ecosistema di runtime Cloudflare.
• Il team: la parte più importante dell’operazione è qui. La “Deno Company” smette di esistere come entità indipendente; le persone e le competenze confluiscono in Cloudflare per spingere la prossima fase.

Questa non è la classica acquisizione “prendiamo un prodotto e lo monetizziamo”: è più simile a un’operazione per acquisire capacità (runtime, V8, toolchain, distribuzione) e applicarle a un obiettivo più grande.

Perché Deno non è mai esploso (e non era un problema di tecnologia)

La parte frustrante è che Deno era avanti su molti aspetti. Ma la qualità tecnica raramente basta.

I freni principali sono stati:

1) Un salto troppo grande rispetto all’ecosistema Node

Deno nasceva con una visione “ripartiamo da zero e facciamolo bene”. Visione valida, ma con un costo: incompatibilità e attrito.

Per anni, migrare progetti reali dal mondo Node (npm, transitive dependencies, toolchain consolidata) è stato più difficile del previsto. E quando un ecosistema è enorme, “essere meglio” non è sufficiente: serve essere compatibili e ridurre a zero il costo di adozione.

2) Node.js era “abbastanza”

Node non è perfetto, ma è stabile, conosciuto, con un mercato sterminato di librerie e know-how. Se la motivazione per cambiare non è schiacciante, la maggioranza non cambia.

3) Monetizzare con l’hosting è complicato

La spinta su una piattaforma serverless proprietaria (Deno Deploy) non ha raggiunto massa critica. In un mercato dominato da player enormi, differenziarsi è difficile e costoso.

4) GSR: ottime idee, adozione dura

GSR aveva spunti interessanti (validazione più rigorosa, scoping, type-checking, publishing TypeScript più diretto). Ma la compatibilità con npm, soprattutto nei casi complessi e con dipendenze transitive, è un campo minato. Anche qui: attrito.

5) La compatibilità Node arriva… ma arriva anche Bun

Con Deno v2 la compatibilità Node fa un salto importante. Ma nel frattempo Bun diventa l’alternativa “drop-in” super appetibile per chi vuole performance e compatibilità senza cambiare modello mentale.

Il risultato è il classico: la tecnologia migliore non vince automaticamente.

La vera scommessa: rendere Workers il modo “standard” di costruire backend

Il punto non è “Deno vs Node”.

Il punto è: Workers come modello di programmazione.

Cloudflare spinge da anni un paradigma molto specifico:

• esecuzione in isolates (V8) invece che in processi lunghi e pesanti
• applicazioni distribuite vicino all’utente
• primitive di stato come Durable Objects
• servizi “adjacent” (queue, storage, database, scheduler) integrati

Finora questa esperienza era fortemente associata a “Cloudflare come piattaforma”. Ora l’obiettivo diventa più ambizioso: portare quel modello ovunque, con una storia credibile di self-hosting.

E qui entra in gioco workerd, il runtime open source di Cloudflare.

Open source come strategia anti lock-in (che aiuta anche il business)

C’è un aspetto controintuitivo ma fondamentale: ridurre il lock-in può aumentare l’adozione enterprise.

Le aziende grandi ragionano su orizzonti di 5–10 anni e fanno sempre la stessa domanda: “Se domani devo uscire dal vendor, posso?”

• Se la risposta è “no”, spesso non entrano nemmeno.
• Se esiste un’“escape hatch” (runtime open source, possibilità di migrare, compatibilità reale), l’adozione diventa politicamente e tecnicamente difendibile.

Cloudflare ha già reso workerd open source, ma ammettere implicitamente che “pubblichiamo il runtime e speriamo che la community costruisca tutto il resto” non funziona sempre.

Ed è qui che un team come quello di Deno ha un senso: tooling, DX, packaging, runtime expertise.

Dove si inserisce “cell”: self-hosting del modello Workers, sul serio

Negli ultimi tempi era emerso anche un progetto open source (in Rust) pensato come “alternativa” per eseguire il paradigma Workers su infrastruttura propria, con compatibilità su molte primitive tipiche:

• Workers
• Durable Objects
• scheduler/cron triggers
• asset statici
• code + storage orientati a un deployment distribuito

L’idea di base è semplice e potente: un singolo binario che ti permette di gestire un cluster di nodi dove girano isolate V8, con persistenza locale (spesso SQLite per nodo) e un “source of truth” su object storage S3-compatible.

Questa direzione risolve un problema reale: ok, il runtime esiste; ma come lo eseguo bene in produzione, su più nodi, con stato e strumenti operativi?

La nuova fase punta a rafforzare workerd come soluzione self-hosted di prima classe, incorporando idee e componenti maturati in questi progetti.

Resta da vedere un dettaglio importante: quanto di questo lavoro rimarrà come progetto separato e quanto confluirà direttamente in workerd. Ma la traiettoria è chiara: unificazione e consolidamento.

Implicazioni pratiche per chi fa frontend (e full-stack)

Anche se sembra una notizia “da backend runtime nerd”, l’impatto arriva dritto sul lavoro quotidiano di chi costruisce prodotti web:

• Se stai scegliendo un runtime oggi, Deno Runtime non è più un investimento sul futuro: può restare valido per progetti esistenti, ma non è una scommessa a lungo termine.
• Se ti interessa il serverless “edge-style”, il focus si sposta su Workers come modello, più che su un singolo runtime.
• Se lavori in team dove la governance conta, l’idea di poter self-hostare lo stesso modello di esecuzione riduce frizioni interne (“lock-in”, procurement, risk management) e rende la scelta tecnologica più facile da approvare.
• Se ti piace l’idea di un registry più rigoroso e moderno, GSR con infrastruttura Cloudflare potrebbe finalmente avere la solidità e la distribuzione che finora sono mancate.

Sintesi: Deno “muore” come runtime, ma vince come idea di piattaforma

Sì: il runtime Deno entra in congelamento funzionale e si avvia a fine vita come prodotto in evoluzione.

Ma questa mossa può essere positiva per l’open source e per l’ecosistema perché sposta energie e competenze su un problema più grande e più utile oggi: rendere il paradigma Workers operabile ovunque, con strumenti, servizi adiacenti e un’esperienza di self-hosting reale.

Per chi costruisce applicazioni moderne, la lezione è sempre la stessa: non vince il runtime “più bello”, vince la combinazione di ecosistema, compatibilità, operatività e fiducia nel lungo periodo. In questo scenario, la “fine” di Deno come runtime potrebbe essere l’inizio di un’infrastruttura Workers finalmente più aperta, adottabile e sostenibile.