Deno : un en­vi­ron­ne­ment d’exécution pour Ja­vaS­cript et Ty­peS­cript

Deno est un en­vi­ron­ne­ment d’exécution d’une sim­pli­cité re­dou­table pour Ja­vaS­cript et Ty­peS­cript. Il propose à ses uti­li­sa­teurs une méthode nouvelle et facile pour rédiger en Ja­vaS­cript et Ty­peS­cript côté serveur. Cette pla­te­forme n’en est encore qu’aux premières étapes de son dé­ve­lop­pe­ment, mais prouve déjà qu’elle pourrait remplacer, à terme, l’in­con­tour­nable Node.js. Une étape qui ne se fera pas sans la com­mu­nauté des dé­ve­lop­peurs Ja­vaS­cript.

Il existe des produits qui, malgré leur im­per­fec­tion, sont appréciés par la com­mu­nauté. Le langage de script Ja­vaS­cript en est un bon exemple. Ses lacunes évidentes ne l’empêchent pas d’être le langage le plus utilisé au monde avec d’in­nom­brables fra­me­works et bi­blio­thèques. Même Node.js, quasiment un pré­dé­ces­seur de Deno, jouit d’une forte po­pu­la­rité auprès de la com­mu­nauté. Avec son nouveau projet, Deno, le dé­ve­lop­peur Ryan Dahl veut tirer parti de la longue ex­pé­rience de Node.js pour proposer une nouvelle pla­te­forme, plus sûre et plus efficace. Dans cet article, nous regardons si et comment ce système fonc­tionne.

Deno n’en est encore qu’à sa phase initiale. Ses choix en matière d’interface, d’ar­chi­tec­ture et de design ne sont pas encore gravés dans le marbre et vont sûrement évoluer au cours du dé­ve­lop­pe­ment. Sur certains points, il est donc difficile de le comparer à Node.js, évoqué plus haut. Un dé­ve­lop­peur propose une com­pa­rai­son générale de ces deux pla­te­formes dans la vidéo YouTube suivante :

Deno et Node.js sont très proches, et pas seulement par leurs noms. Leurs idées de base même sont iden­tiques : ils proposent une pla­te­forme pour exécuter des scripts Ja­vaS­cript en dehors du na­vi­ga­teur et la pos­si­bi­lité de rédiger des scripts Ja­vaS­cript (ou Ty­peS­cript) côté serveur. On les utilise donc pour des projets existants variés, il ne s’agit pas de solutions d’im­plé­men­ta­tion in­dé­pen­dantes et complètes. Pour l’exécution de Ja­vaS­cript dans dif­fé­rents en­vi­ron­ne­ments, on pri­vi­lé­gie en règle générale le moteur V8 de Google, déjà intégré dans les na­vi­ga­teurs Chrome et Edge. Côté serveur, tout comme Node.js, Deno se sert du moteur V8.

Ici s’arrêtent les si­mi­li­tudes. En effet, con­trai­re­ment à Node, qui est rédigé en C++, Deno utilise le langage de pro­gram­ma­tion Rust de Mozilla Research, innovant et bien plus sûr. Deno permet ainsi d’écrire di­rec­te­ment du code en typage statique, ce qui est presque un argument clé de vente.

Deno a deux fonctions qui per­met­tent de sim­pli­fier dras­ti­que­ment les flux de travail : l’en­vi­ron­ne­ment d’exécution crée d’une part un système simple de modules, avec lequel chaque URL cor­res­pond à un module, et vice versa. D’autre part, Deno permet d’exécuter librement des codes Ty­pes­cript.

Une plus grande liberté pour le dé­ve­lop­peur se traduit gé­né­ra­le­ment par un risque de sécurité plus élevé pour l’ap­pli­ca­tion. En matière de sécurité, Deno est paré à toute éven­tua­lité, car il exécute par défaut les scripts dans un bac à sable in­dé­pen­dant du système d’ex­ploi­ta­tion. Les dé­ve­lop­peurs ont limité la pos­si­bi­lité d’ajouter d’autres fonctions.

En com­pa­rai­son, Deno est bien plus orienté vers l’ex­pé­rience uti­li­sa­teur sur Internet : ce runtime ver­rouille par défaut l’accès au système d’ex­ploi­ta­tion. L’uti­li­sa­teur doit autoriser une ap­pli­ca­tion à accéder au système, sans quoi les deux sont par­fai­te­ment isolés l’un de l’autre. Un principe com­pa­rable au com­por­te­ment d’un na­vi­ga­teur qui demande l’au­to­ri­sa­tion, par exemple, d’accéder à la Webcam et au micro dans le cadre d’une vi­déo­con­fé­rence en ligne. Le logiciel accède aux res­sources uni­que­ment si l’uti­li­sa­teur lui en donne l’au­to­ri­sa­tion. En bref, Deno se comporte comme un na­vi­ga­teur pour des scripts en ligne de commande.

De plus, Deno reprend la tendance la plus forte du dé­ve­lop­pe­ment avec Ja­vaS­cript : le support natif de Ty­peS­cript.

Pour convertir et exécuter le code Ty­peS­cript généré avec Deno en Ja­vaS­cript, il n’est plus né­ces­saire de passer par l’étape du com­pi­la­teur. Dès que des données doivent être échangées, elles sont trans­mises par paquets. Par con­sé­quent, Deno n’a besoin d’aucun paquet externe comme ts-node, par exemple, qui s’occupe du processus de com­pi­la­tion pour Node.js.

Deno crée aussi la surprise en matière de gestion de paquets. Node doit notamment son succès à son ges­tion­naire de paquets npm. À l’origine, npm ap­par­te­nait à la com­mu­nauté GitHub et n’était pas un composant standard de Node. Pourtant, l’as­so­cia­tion des deux fait figure de norme non of­fi­cielle. À l’inverse, Deno est fourni sans aucun ges­tion­naire de paquets externe, puisqu’il est son propre ges­tion­naire de modules. Son système de modules peut récupérer des paquets à partir d’un chemin d’accès ou d’une URL et té­lé­char­ger di­rec­te­ment les res­sources né­ces­saires.

Deno n’en est qu’à son com­men­ce­ment. L’accent est clai­re­ment mis sur la sécurité et sur les questions d’ar­chi­tec­ture fon­da­men­tales. On le ressent dès l’ins­tal­la­tion, qui ne repose pas sur un simple paquet d’ins­tal­la­tion, mais passe par GitHub et plus spé­ci­fi­que­ment par les scripts shell ou le ges­tion­naire de paquets du système d’ex­ploi­ta­tion. Pour vérifier que l’ins­tal­la­tion est réussie, il faut entrer la commande Deno - version dans l’interface de ligne de commande (une solution old school s’il en est). Cette commande donne également une vue d’ensemble de la version Deno installée et des versions du moteur V8 et de Ty­peS­cript. Si vous ne souhaitez pas installer Deno sur votre système, le runtime peut aussi s’installer et s’exécuter dans un conteneur Docker.

Dès que Deno est installé, il propose deux modes d’exécution. L’en­vi­ron­ne­ment d’exécution peut s’utiliser en mode in­te­rac­tif en tant que shell ou pour éditer un fichier. La première option est in­té­res­sante pour les petites ap­pli­ca­tions et pour ex­pé­ri­men­ter Deno en tant qu’al­ter­na­tive à Node.js. La seconde cor­res­pond à une uti­li­sa­tion plus courante de Deno : on indique le nom d’un fichier dans la pla­te­forme avant de commencer à tra­vail­ler.

Les mots-clés courants de Ja­vaS­cript comme import, export, promise, etc., sont di­rec­te­ment dis­po­nibles sous Deno et n’ont pas besoin d’être importés au préalable. Outre les objets standards, la pla­te­forme propose aussi un objet global, que les dé­ve­lop­peurs ont baptisé, sans grande ima­gi­na­tion, Deno. L’objet Deno constitue la base de toute ap­pli­ca­tion. Il se comporte comme une interface avec le système. Ainsi, les dé­ve­lop­peurs peuvent, par exemple, accéder au système de fichiers et sortir du bac à sable. Comme déjà mentionné, cette exception doit être ac­ti­ve­ment autorisée afin de ne permettre à aucune ap­pli­ca­tion d’accéder au système sans que l’uti­li­sa­teur n’en soit informé.

Deno propose tous les modules standards. Cependant, la com­mu­nauté propose déjà des modules com­plé­men­taires, ex­pé­ri­men­taux ou aboutis, pour augmenter l’étendue de ses fonc­tion­na­li­tés.

Deno est-il ou deviendra-t-il meilleur que Node ? Son dé­ve­lop­peur, Ryan Dahl, en est convaincu. Les lourdeurs his­to­riques, les erreurs et les compromis finiront par être résolus pour créer une pla­te­forme moderne, stable et sûre sup­por­tant Ja­vaS­cript et Ty­peS­cript côté serveur. Dans tous les cas, son potentiel est bien là, notamment grâce au choix d’utiliser le langage de pro­gram­ma­tion de Mozilla, Rust, dans le noyau, et de créer un système d’au­to­ri­sa­tion cen­tra­lisé. Ce dernier offre une uti­li­sa­tion intuitive tout en empêchant aux ap­pli­ca­tions dans le bac à sable d’accéder in­vo­lon­tai­re­ment au système.

Ce processus de travail fortement simplifié présente (encore) quelques in­con­vé­nients : Deno n’est pas toujours com­pa­tible avec les éco­sys­tèmes existants. Ainsi, un module Node ne fonc­tion­nera pas di­rec­te­ment sur Deno – et in­ver­se­ment. Quoi qu’il en soit, si la pla­te­forme fait ses preuves au fil du temps, à long terme, elle ne pré­sen­tera plus de grave problème de com­pa­ti­bi­lité. À titre d’exemple, Deno dispose déjà d’une fonction require com­pa­tible avec Node.