Contexte et annonce
Le 9 octobre 2026, Ryan Dahl, fondateur de Deno, a publié un article indiquant que l’ensemble de l’équipe Deno intègre Cloudflare. Cette décision s’appuie sur plusieurs années de travail visant à simplifier la création de logiciels serveur, à repenser la distribution des modules et à renforcer les garanties de sécurité du runtime JavaScript/TypeScript. L’objectif déclaré est de fusionner les capacités de Deno avec le modèle de programmation de Cloudflare Workers, notamment les Durable Objects, afin de proposer une plateforme unifiée pour le calcul, le stockage et la communication.
Plan de transition
Cloudflare a détaillé un calendrier de migration : le runtime Deno continuera à recevoir des correctifs mensuels pendant douze mois, après quoi le développement actif sera arrêté. Deno Deploy restera opérationnel pendant six mois avant sa fermeture, avec un accompagnement dédié pour les clients payants qui migreront vers Cloudflare Workers. Le registre de paquets JSR maintiendra son service, mais son infrastructure sera hébergée par Cloudflare. Enfin, le projet rusty_v8 sera intégré à workerd, le moteur d’exécution de Workers.
Implications techniques
Le modèle de programmation de Workers, enrichi par les Durable Objects, offre une exécution serveur sans serveur, un état persistant et une interface JavaScript de haut niveau. Cette architecture élimine la nécessité pour chaque application de gérer son propre réseau d’infrastructure, car la mise à l’échelle est gérée par le modèle même. Le nouveau projet interne nommé celld s’appuie sur ce principe : il permet de concevoir des applications distribuées dès le départ, tout en conservant une surface d’opération réduite. L’intégration de rusty_v8, qui expose l’API V8 via Rust, promet d’améliorer les performances d’exécution et la sécurité du sandbox, en tirant parti des vérifications de type Rust avant le passage au moteur JavaScript.
Perspectives et limites
La migration implique que les développeurs devront adapter leurs pipelines CI/CD pour cibler Workers au lieu de Deno Deploy. Les dépendances spécifiques à Deno, notamment les API de permission et le système de modules intégré, devront être remplacées ou émulated. Bien que le code source de Deno reste ouvert, l’absence de développement officiel après un an pourrait ralentir les contributions communautaires, à moins qu’un fork ne prenne le relais. Enfin, la dépendance accrue à l’infrastructure Cloudflare pose la question de la portabilité pour les organisations souhaitant conserver un contrôle total sur leurs environnements d’exécution.
