- Ces derniers temps, des critiques et des inquiétudes ont émergé au sujet de Deno Deploy, KV, Fresh, ainsi que de la dynamique globale de l’entreprise et des projets
- Une partie de ces critiques est fondée, et le manque de communication suffisante sur l’avancement a aussi alimenté la confusion, mais une grande partie de ces rumeurs et critiques repose sur des spéculations sans fondement ou des informations inexactes
- Depuis la sortie de Deno 2 (après octobre 2023), l’adoption a plus que doublé selon l’indicateur des utilisateurs actifs mensuels
- La forte compatibilité avec Node de Deno 2 a supprimé un obstacle majeur à l’adoption réelle, et la plateforme est devenue plus rapide, plus puissante et plus simple
Les changements et l’évolution de Deno Deploy
- L’une des questions les plus fréquentes concerne la raison de la réduction récente des régions disponibles dans Deno Deploy
- Au-delà des coûts, cette réduction s’explique aussi par l’évolution des usages réels et des besoins
- Pour la plupart des applications, ce qui compte n’est pas la présence dans toutes les régions, mais la vitesse, le debug et la conformité à proximité des données
- Depuis le lancement de Deploy, le nombre de régions est passé de 25 à 35, puis à 6 aujourd’hui
- De nombreuses régions étaient en réalité très peu utilisées, et une dispersion excessive entraînait au contraire une baisse de performance (latence, problèmes de capacité)
- L’équipe reconstruit une vision de l’« edge » plus réaliste, alignée sur les besoins des utilisateurs
- Une nouvelle version de Deploy est en cours de développement, et la plateforme évolue vers l’hébergement d’applications complètes
- Elle prendra en charge les sous-processus, tâches en arrière-plan, OpenTelemetry, pipelines de build, régions auto-hébergées, etc.
- Il sera bientôt possible d’épingler une application à une région ou de l’exécuter dans son propre cloud
Orientation de KV (stockage clé-valeur)
- Deno KV est un store à API simple qui offre une consistance globale garantie sans configuration ainsi que des fonctionnalités temps réel
- Il convient aux données de session, aux feature flags, aux états collaboratifs, mais n’est pas destiné à servir de base de données généraliste
- Deux efforts sont en cours pour répondre à des besoins plus larges en gestion des données
- Renforcer l’intégration des bases de données relationnelles existantes dans Deno Deploy
- Faire avancer un nouveau projet visant à simplifier le lien entre compute et état (inspiré de Cloudflare Durable Objects)
- Dans cette logique, KV reste en bêta, avec un traitement continu limité aux bugs critiques et aux problèmes de sécurité
- Le rôle central ou l’évolution au sein de la solution globale de gestion d’état devrait à l’avenir être porté par d’autres projets
État du framework Fresh
- Fresh reste la base de toutes les applications et de tous les sites web internes, tout en étant activement maintenu et amélioré
- L’équipe est consciente des fortes attentes autour de Fresh 2 et de la longue attente
- Plutôt que de le sortir dans la précipitation, elle privilégie d’abord la qualité de base et l’affinage de la structure
- Voir le récent article de blog détaillant les améliorations
- Un déploiement stable de Fresh 2 est prévu dans le courant de l’année
Deno, une plateforme au-delà du runtime
- Deno est plus qu’un simple runtime : c’est une plateforme système JavaScript complète
- Avec une seule chaîne d’outils, il est possible d’intégrer écriture, exécution, tests, déploiement, monitoring, etc.
- L’intégration, la configuration par défaut, les flags et les connexions entre outils continuent d’être renforcés
- L’objectif n’est pas une simple équivalence fonctionnelle, mais la création d’un écosystème intégré
- Deno vise une amélioration fondamentale de la qualité du développement JavaScript et étend son périmètre dans cette direction
Les objectifs de cette plateforme et leur raison d’être
- Les langages de script jouent un rôle indispensable dans le développement pratique rapide
- L’avenir de JavaScript est encore plus prometteur du point de vue de la standardisation, de l’ampleur de l’écosystème et de la capacité d’extension générale
- Une plateforme « batteries included » est nécessaire, et c’est ce que vise Deno (gestion des permissions, serveur web, observabilité, lint, vérification de types, etc. fournis par défaut)
- Elle propose une expérience unifiée plutôt qu’un assemblage d’outils fragmentés
Plans futurs et renforcement de la communication
- Deno n’entre pas dans une phase de repli, mais dans une phase d’expansion
- La vitesse, la compatibilité et la maturité de la plateforme continuent de progresser, tandis que la gouvernance indépendante de JSR se développe
- En parallèle, Deno poursuit diverses activités pour l’écosystème JavaScript et la collaboration communautaire, comme TC39 / WinterTC
- Fort de l’expérience acquise avec Deploy et KV, l’entreprise développe de nouveaux produits durables et distribués, et d’autres annonces sont attendues prochainement
- Afin de réduire les polémiques et la défiance, elle prévoit de renforcer sa communication et d’accorder une grande importance à la confiance avec les développeurs
3 commentaires
Bun est-il plutôt meilleur que Deno ?
Le déclin de Deno : le nombre de régions dans le monde a été réduit à 6
On dirait que c’est une réponse à ce post.
J’ai aussi publié séparément une explication sur les raisons du retard de la mise à jour de Fresh : Mise à jour Fresh 2, le framework web de Deno
Avis Hacker News
Il me semblait clair dès le départ que la plupart des développeurs ne déploient pas seulement de simples fonctions stateless, mais construisent de vraies applications qui communiquent avec une base de données, comme des apps full-stack. Le fait de ne s’en rendre compte que maintenant paraît presque inévitable.
Partage du constat qu’il y a récemment eu un courant critique sur Deno, Deploy, KV, Fresh, et plus généralement sur sa trajectoire de croissance. Je n’ai pas vu de prise de parole ou de réponse particulière sur la critique concernant la croissance, et je me demande si c’était volontaire. Puisqu’il a été dit qu’une partie des critiques était valable, cela aurait inspiré davantage confiance si l’on avait aussi précisé lesquelles et comment elles seraient traitées. Je trouve qu’une entreprise qui reconnaît honnêtement aussi ses faiblesses devient au contraire plus attractive dans le choix qu’on en fait. Retour d’expérience positif sur le fait d’exposer clairement avantages et inconvénients, comme sur la page pro/con de Migadu.
Si j’avais des attentes envers Deno au départ, c’était parce qu’il pouvait repartir proprement, avec moins de complexité, sans obsession pour la compatibilité avec l’existant. Il y avait des aspects moins pratiques que Node, mais cela restait acceptable. Ensuite, au lieu de pousser ses propres solutions, Deno s’est mis à s’accrocher de plus en plus à la compatibilité avec Node, et j’ai l’impression qu’on se retrouve maintenant avec une structure à deux niveaux encore plus complexe que Node lui-même. Bien sûr, les paquets Node devraient fonctionner naturellement sur Deno, mais il y a beaucoup de cas limites où ce n’est pas le cas à cause d’API non implémentées ou de bugs. AVA, qui était mon framework de test préféré, n’est toujours pas pris en charge. Avant, j’ignorais la couche de compatibilité npm et je n’utilisais que Deno lui-même, mais cela devient de plus en plus pénible. Rien qu’en regardant les options de ligne de commande, on voit que c’est devenu énormément plus complexe en quelques années, et que la plupart concernent l’intégration npm, donc ce ne sont pour moi que des informations inutiles. Ce que je voulais le plus dans la compatibilité Node, c’était la prise en charge de la configuration ESLint dans le linter de Deno, mais ça n’a pas l’air de les intéresser. Je souhaite malgré tout que Deno réussisse, parce qu’il pousse Node à s’améliorer. Mais l’orientation actuelle de Deno ne me semble plus cohérente avec son objectif initial.
J’ai l’impression que Deno a perdu sa direction. Au début, le positionnement était simple : un runtime JS/TS sûr et rapide, écrit en Rust. Maintenant, le menu déroulant « Products » du site web s’est rempli de plusieurs produits de façon assez brouillonne. On dirait qu’ils ont voulu suivre l’exemple de Vercel, qui a construit une plateforme de déploiement après NextJS.
J’ai perdu mes attentes pour Deno à partir du moment où il a renoncé à sa promesse initiale en ajoutant la compatibilité avec Node. Pour moi, l’attrait central de Deno était d’avoir retiré la complexité et l’héritage indésirable de Node. Aujourd’hui, il ne reste plus que quelques différences mineures comme TypeScript intégré et les permissions, et sinon il n’y a plus grand-chose qui le distingue de Node. bun.sh propose aussi une compatibilité Node. Je me demande s’il existe un moteur de scripting TypeScript côté serveur qui ne cherche pas la compatibilité Node.
La compatibilité npm étant une fonctionnalité ajoutée, je n’ai pas l’impression qu’on perde quoi que ce soit pour autant. On n’est pas obligé d’utiliser les API Node, et il suffit de prendre les bibliothèques dont on a besoin sur jsr.io. En pratique, on peut encore bénéficier sur Deno d’une expérience de développement différente de Node. Cela dit, il n’y a pas tant de gens que ça qui veulent une « pureté » absolue, donc il est plutôt rassurant qu’ils aient choisi la popularité et le pragmatisme.
Doute exprimé sur la raison de chercher un runtime TypeScript qui ne poursuive pas la compatibilité Node. Node a certes plusieurs problèmes, mais il reste suffisamment utilisable pour être massivement adopté. Pour créer une alternative pratique, il faut soit (1) des avantages suffisamment forts pour justifier une migration à grande échelle, soit (2) un coût de migration minimal et des améliorations nettes sur la performance, la fiabilité ou l’usage. Or Deno passe à côté des deux. Il ne peut pas exécuter le code Node existant, tout en n’apportant pas d’avantages assez révolutionnaires ; c’est donc une approche qui risque d’attirer seulement des « idéalistes » ou des développeurs amateurs.
Comme runtime TypeScript ne visant pas la compatibilité Node, workerd de Cloudflare Workers vient à l’esprit, mais ce n’est fondamentalement pas un runtime backend généraliste, et il a la limite de proposer très peu de paquets de base ou de fonctionnalités intégrées.
Pour ma part, je préfère utiliser JSDoc. Cela n’a rien à voir avec Node, mais offre des avantages comparables sans la complexité d’une chaîne de compilation.
Si on n’a pas besoin de rester attaché à JS côté backend, il est raisonnable d’envisager de meilleures alternatives plutôt que TypeScript. Si l’on contrôle l’ensemble de la stack, il n’y a pas vraiment de raison de rester sur un langage qui compile vers JS.
Impression que l’article récent est probablement une réaction à https://news.ycombinator.com/item?id=43863937.
Même si c’est un billet écrit par le CEO, il se concentre davantage sur la justification des décisions internes que sur des critiques concrètes adressées à Deno. Malgré cela, la gamme de produits Deno donne tout de même l’impression de plutôt bien fonctionner dans l’environnement Deno.
Il n’y a toujours pas vraiment de confiance ni de conviction. On saura sans doute bientôt ce qu’il en est de Deploy, mais pour KV, s’il n’y a pas de volonté d’aller plus loin après la bêta, je ne vois absolument aucune raison de l’utiliser dans un nouveau projet. Pour Fresh, on parle d’une refonte en alpha vers la fin du T3, mais c’était en fait un framework qui ne fournissait guère plus que le minimum, et même sa structure sans build/compilation, qui ressortait un peu, semble disparaître. Le runtime continue d’être développé, mais il est intéressant de voir que les release notes se concentrent sur la compatibilité Node/NPM, au point de rendre assez creuse la déclaration selon laquelle ils ne cherchent pas la parité fonctionnelle avec les autres runtimes.
La décision d’arrêter le développement continu de KV me paraît vraiment mauvaise. Si les entreprises n’utilisent pas KV, ce n’est pas parce que la fonctionnalité est mauvaise, mais à cause de son étiquette bêta. J’ai beaucoup utilisé Cloudflare Workers KV et je n’ai jamais eu un grand intérêt pour Durable Objects, donc Deno KV m’intéressait, mais j’ai maintenant l’impression qu’il faut l’écarter des options. Stratégiquement aussi, annoncer un nouveau produit puis le laisser immédiatement de côté donne une très mauvaise impression.
Retour sincère de quelqu’un qui envisageait d’utiliser KV mais, faute de perspectives, en est venu à étudier des alternatives.
Je me demande si le fait que la plupart des développeurs déploient non pas de simples fonctions stateless mais des applications full-stack, donc fortement liées à une base de données, vaut en réalité pour tout le mouvement serverless. Si c’est le cas, est-ce vraiment conforme à l’intention originelle du serverless, ou est-ce simplement un choix pour éviter une infrastructure complexe comme Docker/Kubernetes ?
Explication selon laquelle Deno Deploy reçoit souvent des questions sur la réduction du nombre de régions. Du côté de Deno, l’idée est que la plupart des applications n’ont pas besoin de tourner partout dans le monde : il vaut mieux optimiser pour être rapide près des données, plus facile à déboguer et simplement conforme aux réglementations locales. Mais personnellement, je n’ai pas utilisé Deno Deploy justement parce que les emplacements de ses régions n’étaient pas suffisamment proches et que cela posait selon moi un risque en matière de performances. Il existe déjà de nombreuses options plus proches des données et des utilisateurs, et la conformité réglementaire se joue généralement à l’échelle du pays, donc cette orientation d’optimisation ne me convainc pas.