Deno viene assorbita, i prodotti vengono dismessi e il vero premio diventa l’infrastruttura distribuibile dei Durable Objects
Negli ultimi anni ci siamo abituati a parlare di “runtime” JavaScript come se fossero prodotti concorrenti alla pari: Node, Deno, Bun, Workers… ognuno con la propria filosofia e il proprio ecosistema. Oggi però il panorama si è chiarito in modo brusco: Node resta lo standard di fatto, mentre molte alternative si stanno riallineando (o venendo inglobate) da attori cloud con un obiettivo diverso dal “fare un runtime migliore”.
La notizia che segna davvero la fine di un’epoca è l’ingresso di Deno dentro Cloudflare. Non perché Cloudflare avesse bisogno di “un altro runtime”, ma perché la partita si è spostata altrove: dalla compatibilità delle API alla distribuzione dello stato.
Deno: nata per correggere Node, rallentata da Node stesso
Deno era partita con un posizionamento chiarissimo: ripensare da zero l’esperienza server-side di JavaScript.
I suoi punti di forza iniziali erano difficili da ignorare:
- TypeScript di prima classe (esperienza developer immediata, senza configurazioni estenuanti)
- toolchain integrata: formatter, linter e test runner inclusi
- sicurezza “by default” con un modello di permessi esplicito
- una gestione delle dipendenze che voleva evitare alcune storture storiche dell’ecosistema Node
Per un periodo l’idea ha funzionato: c’erano casi d’uso reali e un entusiasmo autentico. Ma il vantaggio competitivo di Deno dipendeva anche da una condizione implicita: che Node rimanesse “uguale a se stesso”.
E invece Node ha iniziato a chiudere il gap, incorporando progressivamente proprio quelle caratteristiche che rendevano Deno “diversa”: API moderne come fetch, un modello di permessi, e perfino la possibilità di eseguire file TypeScript in modo più diretto. Quando lo “standard” assorbe le innovazioni dell’alternativa, l’alternativa perde il suo spazio naturale.
Il problema non era solo tecnico: era di prodotto
Nel frattempo, i prodotti che avrebbero dovuto sostenere il business non hanno trovato abbastanza trazione.
- La piattaforma di deploy è stata ridimensionata in modo importante.
- Alcuni servizi sono rimasti a lungo in beta.
- I framework e i progetti collaterali hanno iniziato a dare segnali di rallentamento.
Quando un’azienda costruita attorno a un runtime si ritrova a fare soprattutto compatibilità con Node, il messaggio al mercato è inevitabile: la battaglia principale non si sta più vincendo.
Ed è qui che arriva la svolta interessante: spostare l’attenzione fuori dal runtime.
Dal runtime al “distributed state”: perché Durable Objects cambiano la conversazione
Se guardi ai limiti pratici delle applicazioni moderne, soprattutto lato edge, non è più solo una questione di performance o sintassi. I “problemi difficili” sono:
- distribuire compute su più macchine e region
- coordinare stato e consistenza
- mantenere connessioni real-time (WebSocket) senza impazzire
- scalare senza introdurre una coda di complessità operativa
In questo scenario, il modello dei Durable Objects è attraente: piccoli server single-threaded con stato persistente (spesso associato a un database embedded come SQLite) e la capacità di tenere connessioni vive. È un pattern che piace perché riduce il numero di componenti esterni e rende più naturale gestire sessioni, stanze, code, coordinator e agenti.
Il punto critico? È una feature profondamente legata a una piattaforma.
CellD: la vera ragione dell’acquisizione
La mossa che cambia tutto è la comparsa di CellD: un’implementazione self-hostabile del modello “Durable Objects”, pensata per girare su infrastruttura propria.
Questa è la parte davvero strategica:
- porta fuori dal recinto cloud un paradigma tipicamente “platform-locked”
- rende possibile pensare a Workers + oggetti con stato persistente come stack distribuibile
- sposta il valore dall’ennesimo runtime JS a un modello operativo per costruire sistemi stateful a latenza bassa
Da qui, l’acquisizione diventa più leggibile: Cloudflare non compra “un runtime peggiore”, compra una soluzione concreta a un problema che voleva risolvere da tempo: rendere davvero self-hostable il proprio approccio, con supporto ufficiale.
Cosa succede ora a Deno (runtime, Deploy e resto)
Qui la parte meno piacevole: Deno come runtime entra in modalità mantenimento.
- per un periodo limitato arrivano patch e fix (soprattutto sicurezza)
- poi lo sviluppo si ferma
- per chi usa la piattaforma di deploy, la finestra di migrazione è stretta
In pratica: l’asset che continua a vivere e a ricevere energia è quello allineato con la strategia Cloudflare (Workers runtime open source + CellD/Durable Objects). Il resto viene progressivamente congelato.
Implicazioni pratiche per chi fa frontend e piattaforme
Anche se lavori principalmente lato frontend, questa storia ha conseguenze concrete:
-
Node rimane il denominatore comune
- tool, bundler, SSR, framework, CI: l’ecosistema gravita ancora lì.
-
Le “runtime wars” si trasformano in “state wars”
- la differenza tra piattaforme edge non è più solo “quanto è veloce il runtime”, ma “come gestisci stato, connessioni e coordinamento”.
-
Occhio al lock-in mascherato da feature
- quando una capability ti semplifica la vita (stateful edge, real-time, agenti), chiediti subito quanto sia portabile.
- la direzione verso componenti self-hostable è una buona notizia, ma va verificata nella pratica (API, compatibilità, operatività, costi reali).
-
Se stai su Deno oggi, pianifica una migrazione senza romanticherie
- l’aspetto tecnico è solo metà della storia: conta roadmap, supporto, ecosistema e tempi.
Sintesi: Node ha vinto, ma la partita interessante non era quella
Il risultato netto è che Node non è stato rimpiazzato: è stato rincorso, copiato, e infine superato su un altro asse — quello dell’infrastruttura.
Deno non diventa “il nuovo Node”; diventa (in parte) un acceleratore per rendere Workers + Durable Objects un modello più distribuibile e, potenzialmente, più universale.
La lezione più utile per chi costruisce prodotti web oggi è semplice: scegliere una runtime conta, ma conta di più scegliere un modello di stato e distribuzione che non ti blocchi domani. Quando la complessità vera si sposta su persistenza, real-time e coordinamento, la tecnologia “vincente” non è quella con l’API più pulita: è quella che ti permette di evolvere architettura e deployment senza rifare tutto da capo.
Articolo originale: https://frontendfacile.it/blog/le-runtime-wars-di-javascript-sono-finite-ha-vinto-node-e-cloudflare-si-prende-i
Top comments (0)