Les bons, les moins bons et les indécis
En 2018, Ryan Dahl, fondateur de l’environnement d’exécution Node pour JavaScript, a donné une conférence à JSConf —10 choses que je regrette à propos de Node.js. Ce n’est pas souvent que vous entendez le fondateur d’une technologie devenue paradigme regretter certaines des principales caractéristiques de sa propre invention. Si vous n’avez pas regardé la conférence, je vous la recommande vivement. Il met en évidence les lacunes qui existent dans Node, dont certaines que nous, en tant que développeurs, considérons comme des fonctionnalités.
Dans l’exposé, il présente également Deno, un nouvel environnement d’exécution qui utilise V8 mais est construit en Rust. À l’époque, il l’appelait son projet parallèle, car Ryan Dahl se passionne pour le bricolage avec des environnements d’exécution entièrement nouveaux. Néanmoins, l’introduction de Deno a presque immédiatement engendré un millier d’articles techniques posant la question : Deno remplacera-t-il Node ?
La réponse courte est… peut-être.
J’ai passé beaucoup de temps dans l’écosystème Deno tout en développant un outil open-source avec une petite équipe d’ingénieurs. Nous avons contribué à la communauté en partie parce que nous trouvions cela passionnant. Notre outil aide les développeurs à identifier les fuites de mémoire dans les applications de niveau production. Ce sont les types d’outils que Node possède depuis des années à ce stade. À la fin de la première version, ce sont les fonctionnalités qui m’ont marqué que Deno fournit.
Pas de package.json et pas de node_modules
Dites adieu à npm, package.json
, et le dossier volumineux node_modules. Si vous êtes un développeur Node, vous pensez peut-être – mais ce ne sont pas ces choses Caractéristiques de Node ? Non, en fait npm et package.json
ont été créés séparément de Node pour gérer facilement le partage des dépendances d’application. En réalité, node_modules
causé beaucoup de problèmes.
Par exemple, si vous écrivez en JavaScript full-stack ou TypeScript, disons avec React et Node, vous pourriez avoir node_modules
dossiers installés sur tout le système de fichiers de votre ordinateur, dont beaucoup contiennent exactement les mêmes modules.
Deno adopte une approche différente. Il vise à imiter le web. Il importe des modules par montrer du doigt à leur adresse sur le web. Vous trouverez ci-dessous un exemple d’importation du framework Oak (un outil permettant de créer des API RESTful comme Express.js) dans Deno.
import { Application, Router } from "https://deno.land/x/oak@v11.1.0/mod.ts";
Maintenant, vous n’avez pas besoin du fichier package.json et vous n’installez pas npm a node_modules
dossier dans le référentiel de votre projet. Au lieu de cela, vous pouvez importer des modules directement du Web dans votre projet dans des extraits décentralisés comme celui-ci.
Vous vous demandez peut-être : que se passe-t-il si les sites contenant ces modules tombent en panne ? Ne vous inquiétez pas, Deno met ces modules en cache dans votre ordinateur la première fois que vous exécutez votre code. Ou, avant de courir, vous pouvez deno install
les modules directement dans votre terminal. L’avantage est que ces fichiers sont mis en cache uniquement surce. Cela élimine tout ce gonflement embêtant de node_modules.
TypeScript prêt à l’emploi
Personnellement, en tant que développeur ayant commencé avec Java et C++, je suis un grand fan de TypeScript. Tout comme Ryan Dahl. TypeScript vous aide à dactylographier vos fichiers et élimine les erreurs gênantes, généralement dues à un code mal écrit. Il le fait avant que vous n’exécutiez quoi que ce soit. C’est votre contrôle pour vous assurer que vous créez votre produit avec le moins de problèmes évitables lorsqu’il atteint la production.
Deno fournit une intégration TypeScript prête à l’emploi. Node, d’autre part, vous oblige à importer un autre package pour gérer l’intégration de TypeScript. Cela vous oblige également à gérer la configuration des outils de transpilation pour ce TypeScript. Vous n’avez pas besoin de jouer avec ça à Deno. Cela signifie que vous commencez à créer des projets TypeScript plus rapidement dans Deno que vous ne le feriez dans Node.
Si vous détestez absolument TypeScript (je un m vous juger), alors vous pouvez également écrire du JavaScript pur dans Deno. Deno peut également traiter JavaScript étant donné que TypeScript n’est qu’un sur-ensemble du langage (mais sérieusement, changez d’avis).
La bibliothèque standard
Ne me lancez même pas sur la bibliothèque standard fournie par Deno. Avoir une bibliothèque standard a été un énorme avantage pour notre équipe lors de la création de ce projet. Étant principalement des développeurs de nœuds, nous avons initialement démarré notre projet en utilisant une bibliothèque WebSocket tierce pour communiquer avec une interface graphique qui traçait les statistiques de mémoire à partir de l’application d’un développeur.
Tout comme les développeurs de Node le découvrent souvent, les modules open source contenaient beaucoup de bogues et très peu de documentation. Après avoir beaucoup travaillé sur l’outil cassé, nous sommes passés à la bibliothèque WebSocket standard de Deno et nos problèmes ont été instantanément résolus.
Node visait à être un environnement minimaliste, et il y est parvenu à tort. Il a une bibliothèque standard extrêmement minimale. De nombreux frameworks que les développeurs utilisent quotidiennement sont open source et ne sont ni mis à jour ni maintenus. Ou, pour certains d’entre eux, ces mises à jour prennent incroyablement longtemps (en vous regardant, Express v5.0). Deno maintient un petit ensemble d’outils standard est si important pour les développeurs qui ont besoin que les modules fonctionnent, soient bien documentés et mis à jour au besoin.
Aucun outil de construction
Si vous utilisez Node, il y a 99 % de chances que vous utilisiez ou ayez également utilisé Webpack. Je vais juste le dire : Webpack est génial… jusqu’à ce que ce ne soit pas le cas. Maintenant, c’est uniquement du point de vue du développement – Webpack fait tellement de choses importantes sous le capot comme la création d’un graphique de dépendance de votre fichier, la transpilation de votre JSX/TSX, et la minification et l’aggravation de votre code.
En même temps, je me suis cogné la tête contre un mur en essayant de résoudre une erreur Webpack (il s’est avéré que j’avais besoin de changer l’ordre de deux de mes chargeurs) et ce n’était pas la seule fois. Webpack est une source constante de frustration pour les développeurs débutants et expérimentés. Juste voir à quelques de ces fâché des postes, (discrétion des téléspectateurs recommandé). Ou parcourez les 40 000 questions sur le webpack sur Stack Overflow.
Lorsque nous avons commencé à travailler avec Deno, nous avons été ravis d’apprendre qu’il y avait aucun outil de construction supplémentaire requis. Pas de Webpack, pas de Vite, pas de Babel, pas de Rollup, pas de Gulp – rien que deno compile. En fait, pour notre interface graphique, nous avons utilisé le Déno frais framework qui est un framework sans configuration et sans étape de construction pour le frontend, ce qui nous amène à Deno Deploy.
Deno Deploy
Deno Deploy est probablement ma fonctionnalité préférée liée à Deno, mais qui ne fait pas directement partie de l’environnement. Deno Deploy est un moyen de déployer vos applications sur le Web avec littéralement zéro effort.
Je ne plaisante pas – essayez-le. Vous pouvez créer un nouveau référentiel Github, ajouter le passe-partout Deno Fresh avec une seule commande de terminal et déployer en périphérie sur deno.dev en moins de dix minutes. Ensuite, toutes les mises à jour de votre référentiel Github apparaîtront en quelques secondes pour [your app name].deno.dev.
Il y a beaucoup d’autres choses intéressantes à propos de Deno Deploy, mais même du point de vue de l’expérience du développeur, c’est un outil incroyable pour réduire la complexité inutile du déploiement.
Bien que j’aie vraiment apprécié l’environnement Deno, il y avait quelques problèmes et désagréments notables, même avec les fonctionnalités que j’ai soulignées ci-dessus.
Bogues, bogues, bogues
Nous ne pouvons pas leur donner trop de flack — Deno est un nouvel outil et ses développeurs ont averti la communauté que certaines fonctionnalités sont instables. Cependant, il y avait des problèmes très bâclés dans Deno qui ne semblaient pas être la faute d’une base de code en évolution rapide.
Le plus important pour notre équipe était que l’une des fonctions standard de Deno, Deno.memoryUsage
, a renvoyé une variable étiquetée de manière incorrecte. Ils ont rapporté une valeur pour la taille de l’ensemble résident qui était en fait un nombre dérivé d’une fonction V8 qui mesure la taille de tas engagée. Ceux-ci sont des valeurs très différentes, et notre équipe a passé des jours avec un calendrier serré à essayer de comprendre pourquoi les chiffres n’avaient aucun sens. Nous avons supposé que c’était nous, il s’avère que c’était Deno. Nous avons soumis ce problème billet qui n’a pas encore été résolu.
Les fonctions de sécurité sont ennuyeuses
Je comprends et respecte les décisions de sécurité prises par Ryan Dahl lors de la création de Deno. Cependant, j’ai trouvé extrêmement ennuyeux pendant le développement que si j’oubliais un indicateur ‘-allow-read’ ou ‘-allow-net’, Deno me demanderait 50 autorisations de lecture ou d’écriture différentes dans une multitude d’invites de commande. Tu boîte construire ces drapeaux dans des scripts, ce que nous avons finalement fait. Cependant, dans ces premiers stades de développement, j’ai trouvé que c’était un choix particulièrement redondant.
La documentation est en quelque sorte moins lisible que celle de Node
Je ne sais pas vraiment comment vous rendez la documentation pire que celle de Node, mais Deno l’a fait. Alors oubliez toutes ces belles choses jaillissantes que j’ai dites sur la bibliothèque standard de Deno étant si importante parce que, tant qu’elle l’est, ils n’a toujours pas bien documenté tout cela. Je donne du crédit à l’équipe Deno : c’est assez tôt pour cet environnement. Mais je les supplie aussi d’améliorer leur documentation. Les développeurs ne doivent pas se débattre avec la syntaxe de base de votre bibliothèque standard avant de relever de véritables défis techniques.
Celui-ci n’est pas inclus dans le bon ou le mauvais – pour moi, c’est encore à décider. L’une des plus grandes critiques adressées à Deno était que de nombreuses bibliothèques npm étaient complètement inaccessibles dans un environnement Deno. C’est un énorme problème de transition d’un projet existant de Node vers Deno.
Que faire de toutes les dépendances ? Presque tous les articles pointant vers la faible adoption de Deno avaient ce problème au premier plan.
Cependant, dans cette vidéo de Ryan Dahl liée en haut de cet article, il a affirmé qu’il ne rendrait jamais Deno rétrocompatible avec les anciens modules Node. Il pensait que ce ne serait qu’un remake de Node. Sauf qu’il y a un problème : il vient de faire. Deno a stabilisé la compatibilité npm au cours des derniers mois alors que nous étions en train de créer notre outil open source.
Je ne sais pas quoi penser de cette transition. Deno a vu apparaître de nombreux frameworks innovants, en partie à cause de la disponibilité limitée de l’un des frameworks les plus anciens et les plus familiers. Personnellement, j’aime l’innovation, et je suis d’accord avec les commentaires de Ryan Dahl dans sa présentation — en établissant la rétrocompatibilité, il a fait de Deno une autre version de Node.
Pour être honnête, je pense qu’il est plus probable que la pression de Deno force Node à s’améliorer. En fait, Node a déjà introduit les importations HTTPS plus tôt cette année, donc ces problèmes avec node_modules peuvent ne pas durer trop longtemps. Comme je suis avant tout un ingénieur Node, c’est ce que j’espère.
Je vous encourage à essayer Deno par vous-même et à voir si vous l’aimez !
Si vous souhaitez consulter notre outil open source, vous pouvez trouver notre CLI outil et notre interface graphique sur Github, ou vous pouvez télécharger l’outil ici.
Merci d’avoir lu.