Le compte à rebours d'un an du runtime est lancé
Deno rejoint Cloudflare, mais le runtime Deno autonome ne sera pas poursuivi par son équipe de développement actuelle. Bien que l'annonce de Cloudflare ait mis en avant une vision partagée, la publication de Deno a confirmé un détail crucial : le Deno runtime a une date d'expiration d'un an.
Au cours des 12 prochains mois, l'équipe Deno fournira des versions mensuelles, apportant des correctifs de bugs essentiels et des mises à jour de sécurité. Après cette période, le développement officiel du runtime Deno cessera. Cela marque un tournant définitif pour un runtime qui avait suscité un intérêt considérable de la part des développeurs.
Il est crucial de noter que le runtime Deno reste open source. Des forks communautaires sont tout à fait possibles, permettant aux utilisateurs dévoués de maintenir leurs propres versions. Cependant, cela est distinct du support continu par l'équipe principale de Deno, dont les ressources sont désormais orientées vers les priorités stratégiques de Cloudflare.
Ce pivot signifie que tout projet construit directement sur Deno, ou ceux utilisant des runtimes compatibles avec Deno comme Supabase Edge Functions et les edge functions de Netlify, font face à une date limite de migration stricte. Le compte à rebours est lancé pour un runtime que beaucoup appréciaient sincèrement.
Cloudflare veut la couche de mise à l'échelle, pas le runtime
Cloudflare n'achète pas Deno pour son runtime autonome ; la cible est la solution architecturale de Deno à un défi de mise à l'échelle persistant. L'incitation principale se concentre sur les Durable Objects, la primitive serverless de Cloudflare qui offre un stockage et une exécution globalement cohérents. Imaginez une salle de chat : chaque canal correspond à son propre Durable Object, un micro-serveur adressable avec un stockage dédié de type SQLite. Plus de canaux signifient simplement plus d'objets, répartis sur des machines, évoluant de manière inhérente.
Le piège ? L'auto-hébergement de Durable Objects à grande échelle en dehors de Cloudflare a été notoirement difficile. Bien que Cloudflare Workersd, le runtime open-source de Cloudflare Workers, prenne en charge les Durable Objects à instance unique, cette configuration est utile pour les tests mais ne parvient pas à monter en charge en production. L'architecte de Cloudflare, Kenton Varda, a même admis que ses propres tentatives pour construire une solution auto-hébergeable multi-instance se sont avérées « embarrassantes ».
La réponse de Deno est celld (anciennement « Deno D »), une couche d'orchestration basée sur Rust. Ce projet combine un binaire unique avec un bucket de stockage d'objets compatible S3, permettant aux applications Cloudflare Workers et aux Durable Objects existants de fonctionner avec une évolutivité multi-machine sur une infrastructure privée.
Deno a conçu la solution que Cloudflare ne pouvait pas créer en interne, fournissant une pièce essentielle pour une stratégie edge auto-hébergée plus large. Cette acquisition ne concerne pas l'avenir du runtime Deno ; il s'agit d'intégrer celld dans Cloudflare Workersd pour débloquer une nouvelle frontière de mise à l'échelle pour l'écosystème de Cloudflare.
L'accord pourrait remodeler l'endroit où les applications avec état s'exécutent
L'acquisition de Deno par Cloudflare cible une lacune stratégique critique : une voie longtemps demandée par les développeurs pour auto-héberger Cloudflare Workers et les Durable Objects à grande échelle. L'entreprise gagne une équipe éprouvée et la technologie celld, qui regroupe l'orchestration distribuée dans un seul binaire Rust. Cette technologie permet des Durable Objects multi-locataires et évolutifs avec un bucket de stockage compatible S3.
Le plan implique l'intégration des capacités de celld directement dans l'écosystème open-source Cloudflare Workersd. Cette initiative permet d'obtenir ce que l'architecte de Cloudflare, Kenton Varda, a admis être difficile à construire en interne : un environnement robuste et multi-instance pour Durable Objects en dehors de l'infrastructure de Cloudflare. Le succès du projet pourrait fondamentalement remodeler la manière dont les applications avec état sont déployées.
Le projet de Deno, initialement baptisé Deno D, résout le problème de mise à l'échelle pour Durable Objects en mappant des identifiants uniques (comme un ID de salon de discussion) directement vers des objets individuels à travers les machines. Cette approche garantit une scalabilité horizontale intégrée, ce qui contraste fortement avec la limitation précédente de Cloudflare Workersd à une instance unique pour les tests.
Pour les développeurs, les retombées pourraient être significatives. Cette intégration promet une plus grande portabilité pour les applications avec état, leur permettant de s'exécuter sur une infrastructure privée tout en tirant parti des puissantes primitives edge de Cloudflare. Alors que le développement du runtime Deno touche à sa fin, son innovation principale — la gestion d'état distribuée — ancre désormais une plateforme centrée sur Cloudflare plus forte et plus flexible. En savoir plus sur la transition ici : Deno is joining Cloudflare.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Les utilisateurs de Deno doivent planifier au-delà de l'annonce
La fin du runtime Deno exige une action immédiate de la part de sa base d'utilisateurs. Les développeurs exécutant des applications sur le runtime Deno autonome sont directement touchés, ainsi que les services construits sur des runtimes compatibles avec Deno. Cela inclut des plateformes comme Supabase Edge Functions et Netlify Edge Functions, qui font désormais face à un changement de dépendance critique.
Les utilisateurs doivent effectuer un inventaire rapide de leurs dépendances de runtime. Suivez attentivement les dates de support officiel, car la fenêtre de 12 mois pour les correctifs de bugs et les mises à jour de sécurité se fermera. Commencez à tester des runtimes alternatifs et surveillez la communauté pour d'éventuels forks open-source ou des kits d'outils de migration.
Cette acquisition n'est pas une consolidation typique où les outils continuent sous une nouvelle propriété. Cloudflare a sécurisé l'équipe Deno et leur technologie de mise à l'échelle Durable Objects (celld), mais pas le runtime autonome lui-même. Cet accord sert de rappel brutal des risques inhérents à la dépendance envers des outils open-source soutenus par des entreprises, surtout lorsque la technologie de base est absorbée plutôt que poursuivie.
Comparez cela à l'adhésion de Bun à Anthropic ou à l'acquisition d'Astro par OpenAI ; ces projets ont maintenu leurs trajectoires indépendantes. Ici, le développement du runtime Deno s'arrête explicitement, forçant une réévaluation fondamentale pour des milliers de développeurs. Le marché vient de démontrer que même des runtimes performants et appréciés sont remplaçables dans la poursuite de l'innovation stratégique des systèmes distribués.
Foire aux questions
Deno ferme-t-il ses portes ?
Non. Deno rejoint Cloudflare, mais le développement officiel du runtime Deno autonome devrait s'arrêter après une période de 12 mois de correctifs de bugs et de mises à jour de sécurité mensuels.
Qu'est-ce que Cloudflare acquiert auprès de Deno ?
L'accord apporte l'équipe de Deno et sa technologie pour mettre à l'échelle Durable Objects au-delà de l'infrastructure de Cloudflare dans l'écosystème de Cloudflare.
Qu'est-ce que Durable Objects ?
Durable Objects sont des unités avec état adressables individuellement qui peuvent coupler la logique d'application avec un stockage persistant, tel que SQLite, et évoluer à travers les machines.
Que doivent faire les utilisateurs de Deno maintenant ?
Examinez le calendrier de support du runtime, identifiez les dépendances vis-à-vis de Deno et planifiez la maintenance communautaire, la migration ou un autre runtime si nécessaire.