Qui est Ryan Dahl ?
Ryan Dahl est un développeur américain. Il est notamment connu pour avoir développé l’environnement d’exécution JavaScript Node.Js.
Après 3 ans à travailler sur Node, Ryan Dahl décide de quitter le projet et cède la direction au créateur du gestionnaire de paquets utilisé par Node.Js : Isaac Z. Schlueter.
Après avoir fait face à plusieurs frustrations sur l’ancien projet, il décide de se consacrer au développement d’un nouveau runtime baptisé Deno.
Petit point sur Node.Js
Sortie en 2009, Node.Js est une plateforme logicielle libre qui permet de développer des applications ultra rapide. Ceci pour deux raison principales :
- Node.Js utilise le moteur JavaScript V8 de Google. Tout le code JavaScript est alors compilé en code machine natif avant l’exécution du fichier. Ce qui permet à Google d’interpréter le code.
- Node.Js est capable d’exécuter simultanément plusieurs tâches. Il est construit sur un modèle d’opérations non bloquantes. Il est donc tout à fait possible pour le runtime d’exécuter une deuxième tâche lorsque la première et en attente ou en cours.
Deno, le nouveau projet
Dans une conférence donnée par Ryan Dahl sur les «10 things I regret about Node.Js» il a annoncé en 2018 le lancement d’un nouveau projet qu’il a nommé Deno (anagramme de Node). Il affirme que Deno n’a pas pour vocation à remplacer Node et pourtant les deux projets sont similaires sur plusieurs points.
Deno et Node, des projets similaires
Deno permet l’exécution du JavaScript en dehors d’un navigateur tout comme Node à la différence qu’il intègre en plus le TypeScript. Les deux sont construits avec le puissant et léger moteur JavaScript V8 de Google.
Mais les deux runtimes ne sont évidemment pas identiques sur tout les points. Comme dit plus haut, Ryan Dahl a lancé le projet Deno suite à quelques insatisfactions concernant notamment la sécurité.
Deno, le runtime amélioré
Ryan Dahl a donc consacré beaucoup d’efforts sur la sécurité du runtime Deno afin de ne pas refaire les mêmes erreurs. Dorénavant, il n’y aura aucun accès autorisé par défaut. Simple et efficace, c’est au développeur de choisir et de donner les accès. L’avantage se trouve aussi dans le fait que ces accès peuvent être paramétrés aussi précisément que l’on souhaite via des lignes de commandes. Exemples : --allows-net, --allows-write.
Suite aux avancées technologiques, le runtime Deno se différencie de Node par son système de modules ECMAScript. Lors du développement de Node, les systèmes de modules n’étaient pas encore d’actualité. Cependant, sur Deno, ils ne sont utilisables que par la spécification de leur URL (exemple : $ npm install bootstrap).
Malgré tout, les modules ES constituent un réel avantage pour Deno. Ils permettent au runtime de s’exécuter côté serveur avec le JavaScript mais aussi d’être hébergé sur n’importe quel serveur Web, même en dehors de NPM.
Pour interagir avec n’importe quel système d’exploitation, Deno peut compter sur le langage Rust ainsi que sur TypeScript sans avoir besoin de faire de configurations spéciales.
La seule fonctionnalité majeure qui manque encore au projet avant qu’il ne puisse sortir est la prise en charge du débogueur, qui devrait utiliser Devtools de Chrome pour le débogage.
Un changement de la part du créateur
En créant le runtime Deno, Rayn Dahl a surtout changé sa manière de penser. Ses regrets avec Node étaient de ne pas avoir prit le projet dans son entièreté, il s’est concentré sur ce qu’il jugeait bon de faire sans écouter ce que son équipe lui disait. Il le dit lui-même, ses amis lui avaient souvent fait des recommandations mais, il n’en a pas tenu compte. Par la suite, il s’est rendu compte, malheureusement trop tard, de ses erreurs pour les rattraper. On constate aujourd’hui que le créateur sait tirer profit de ses erreurs passées. Avec Deno, il met tout en place pour partir de la définition du besoin du projet et ainsi éviter de se perdre en cours de route.
Pour conclure, Ryan Dahl a annoncé que Deno ne sera pas compatible avec Node. C’est une volonté de la part du créateur qui ne tentera rien pour rendre compatibles les deux projets. Il veut ainsi éviter toutes possibilités de recréer le même runtime.
Vous pouvez voir la documentation officielle sur deno.land, et si l’article vous a intéressé, n’hésitez pas à faire un tour sur le blog Numendo
