les choses que j'aime chez Deno

Le problème

La version stable de Deno a été introduite il y a environ 3-4 ans. À cette époque, cela a suscité beaucoup d’attention car nul autre que Ryan Dahl, le créateur de Node.js, était également le patron de Deno. Hein! Vous avez bien entendu. Pourquoi créerait-il un nouvel outil pour rivaliser avec son propre « enfant » ?

Ryan Dahl a admis que Node.js présente des faiblesses critiques. Initialement, Node.js a été conçu pour se concentrer sur la simplicité et la flexibilité. Mais au fil des années, tout est devenu incontrôlable. Node.js s'est développé de manière très puissante, attirant davantage d'attention, et à mesure que les gens essayaient de tout intégrer dans cette étoile montante, cela est devenu plus compliqué que nécessaire.

Deno est né pour remédier aux faiblesses de Node. Cependant, au moment de son lancement, il n’a pas fait valoir ses atouts. Ses performances étaient même inférieures à celles de Node.js, sans parler du manque de support npm, qui était l'un des plus grands avantages de Node. Cela a rendu les choses de plus en plus difficiles.

Étant une personne curieuse, j'ai rapidement expérimenté quelques extraits de code en utilisant Deno et j'ai réalisé les inconvénients concernant le système de bibliothèque. "Wow, mes bibliothèques préférées mettront peut-être beaucoup de temps à apparaître sur cette plateforme ; tout semble à la fois nouveau et inconnu", ai-je pensé !

Tout a changé lorsque j'ai lancé "Tear Down and Rebuild" mon blog. Après de nombreuses hésitations et réflexions sur les choix technologiques, le nom Fresh est apparu. Cependant, Fresh nécessite Deno comme environnement d'exécution. N'ayant aucune expérience préalable en matière de déploiement, mais pensant « c'est juste un environnement d'exécution JavaScript ! » m'a donné plus de confiance. La prochaine histoire est cet article.

Aujourd'hui, je vais résumer 5 points sur lesquels je me sens "comme" lorsque je travaille avec Deno.

Prise en charge de TypeScript

Deno prend en charge nativement TypeScript. Cela signifie que vous pouvez exécuter un fichier .ts directement sans passer par une étape de conversion en .js comme le font habituellement les autres bibliothèques. Beaucoup de gens se demandent si cela est différent de l'utilisation d'un outil pour exécuter du code TypeScript comme ts-node ? La réponse est définitivement oui car ts-node nécessite que les fichiers de configuration TypeScript fonctionnent dans des cas complexes, contrairement à Deno. La prise en charge par défaut de TypeScript simplifie le processus d'exécution directe du code .ts.

Je crée souvent des scripts pour gérer moi-même certaines tâches mineures. Chaque fois que je crée un nouveau script, j'hésite toujours entre choisir .js ou .ts. Et lorsque Deno est apparu, .ts est devenu le choix par défaut. Même dans les projets Node, lorsque j'ai besoin d'écrire un script pour effectuer une tâche rapide, je préfère toujours choisir .ts et utiliser Deno pour exécuter ce code.

Fini les fichiers de configuration multiples

Plus je m'engage dans des projets JavaScript/TypeScript en général ou Node.js en particulier, une chose que je me suis toujours posée ou même trouvée ennuyeuse est... qu'il y a trop de fichiers de configuration. Chaque projet différent contient des fichiers avec des noms différents. À partir de package.json, package-lock.js et d'un tsconfig.js supplémentaire si le projet utilise Typescript... Sans oublier si je dois configurer quelques éléments supplémentaires comme webpack, vite, tailwind, postcss... oh mon Dieu ! Au début, parce que je n'étais pas familier, j'ai dû lire pour comprendre la signification et l'utilisation de chaque fichier de configuration qui apparaît dans le projet, en lisant tout en maudissant silencieusement : "Comment diable pouvez-vous créer des centaines de fichiers de configuration comme celui-ci ?"

Lorsque j'ai déménagé chez Deno, j'ai été étonné de constater qu'il n'y avait aucun fichier de configuration. Cela signifie que vous pouvez exécuter le projet sans aucune configuration – cela semble surréaliste, n'est-ce pas ? S'il y en a, il ne s'agit que d'un seul fichier deno.json. Deno a intelligemment éliminé de nombreuses configurations compliquées ou les a placées dans un seul fichier JSON. Quel soulagement d'ouvrir un projet sans se soucier à nouveau de l'apparition d'un nom étrange !

Prise en charge des API Web et des API de nœud

Deno a essayé et essaie de prendre en charge les API Web autant que possible. Les API Web sont un ensemble standardisé d'API disponibles dans le navigateur. Une bonne prise en charge des API Web peut permettre aux programmes exécutés dans Deno de s'exécuter également dans le navigateur, en suivant le paradigme écrire une fois – exécuter n'importe où. Cela ouvre des voies aux bibliothèques « universelles ».

Si vous avez déjà travaillé avec Serverless, en particulier avec Cloudflare Workers, vous savez que les Workers ne sont pas entièrement compatibles avec Node.js, donc l'utilisation de bibliothèques spécifiques à Node ne fonctionnera probablement pas. En revanche, si une bibliothèque utilise ou est compatible avec les API Web, elle fonctionne correctement. Cela s'applique également à Deno.

La prise en charge des API Node permet à Deno d'exécuter la plupart des « packages » sur npm. Ainsi, vous pouvez utiliser librement les packages npm sans plus vous soucier de la compatibilité.

Nouveau mécanisme de sécurité

C'est assez étrange qu'il y ait une évidence que lors du démarrage d'un projet Node, il aura par défaut toutes les autorisations de l'utilisateur. Cela signifie que le programme peut accéder librement aux fichiers ou exécuter des commandes dans le système au nom de l'utilisateur. Assez dangereux, n'est-ce pas ? Imaginez si vous « exécutez » accidentellement le projet de quelqu'un d'autre sans le vérifier au préalable, et qu'il analyse toutes les données de votre machine, les renvoie à un serveur ou crypte tous les fichiers contre une rançon, puis considérez votre vie comme ruinée, une erreur qui ne peut pas être corrigé !

Deno corrige cette faille en ajoutant des indicateurs pour demander des autorisations lors de l'exécution d'applications. Les autorisations peuvent inclure l'accès aux fichiers, l'accès à Internet... Si le programme souhaite accéder au système de fichiers ou se connecter à Internet, il doit au moins demander l'autorisation. Par exemple :

$ deno run --allow-read --allow-write --allow-net index.ts

De nombreuses autorisations doivent être « demandées » ; pour plus de détails, reportez-vous à Sécurité et autorisations | Deno Docs. Le moyen le plus rapide consiste à autoriser toutes les autorisations en utilisant l'indicateur -A ou --allow-all.

Les performances s’améliorent continuellement

Je me souviens des premiers jours où il venait juste d'être introduit ; Deno semblait être à la traîne de Node.js en termes de performances du programme. Plus précisément, les tests de référence ont montré la différence entre Deno et Node lors de l'exécution du même programme ; Deno a toujours échoué. À un moment donné, bun.sh est soudainement apparu. Bun est apparu comme un phénomène car il a surpassé les deux Node.js en termes de performances. Cela a rendu Deno encore plus ennuyeux.

En réalité, lorsque j'utilisais bun pour exécuter certaines applications Node, j'ai rencontré pas mal de problèmes et même de bugs. Il semble que Bun ne soit pas prêt pour la « production ». Donc à cette époque, j'ai conclu que Node était toujours le choix incontournable pour ceux qui aiment la stabilité.

Récemment, avec la sortie de Deno 2.0, des efforts importants ont été déployés pour améliorer les performances et améliorer l'expérience de programmation de ce « dinosaure noir ». Selon la dernière documentation publiée, Deno se démarque à tous égards par rapport aux noms bien connus Node et Bun.

Conclusion

Vous trouverez ci-dessus les points que j'aime lorsque je travaille avec Deno. Il existe quelques fonctionnalités supplémentaires, telles que la fourniture gratuite de Deno Deploy pour déployer des applications. Cependant, je tombe encore occasionnellement sur des articles qui « critiquent » les performances et le système de modules, ainsi que la faible compatibilité avec Node. Ces limitations ont été corrigées dans la dernière version 2.0. Mon point de vue sur Deno a changé par rapport à son lancement initial, et j'espère que Deno recevra plus d'attention de la part de la communauté et fera encore plus de percées à l'avenir.

Et vous ? Avez-vous utilisé Deno? Avez-vous des éloges ou des critiques concernant cet environnement d'exécution JavaScript ? Veuillez laisser vos commentaires ci-dessous !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!