En ce moment, c’est une période passionnante pour JavaScript. Nous venons de recevoir un nouveau chignon d’exécution rapide et brillant, le dernier petit nouveau Deno étant sorti il y a seulement 4 ans, et nous avons l’avantage des environnements d’exécution informatiques/sans serveur comme Cloudflare worker et Blueboat. Avec tous ces engouements pour la communauté JavaScript, je n’ai pas pu m’empêcher de demander, comment se fait-il que seul JavaScript obtienne tous ces nouveaux runtimes fantaisistes ? Pourquoi ne les entendons-nous pas plus souvent dans d’autres langues ?
Qu’est-ce qu’un runtime ?
L’exécution peut signifier différentes choses, mais nous nous référons ici à l’environnement d’exécution ou au système d’exécution, qui est le système sur lequel le programme est destiné à être exécuté. Fondamentalement, cela signifie que vous devez installer certaines bibliothèques ou utiliser des exécutables pour exécuter vos codes, comme la façon dont vous utiliseriez node commande pour exécuter vos codes JavaScript. Une chose à noter est que vous pourriez le confondre avec “bibliothèque d’exécution”. Parfois, nous parlons aussi de “runtime” dans certains langages compilés, mais le plus souvent, ce sont des bibliothèques standard qui sont incluses lors de chaque construction pour gérer le tas/pile et les ramasse-miettes. Consultez quelques FAQ comme celle de Go et de Rust.
Certaines langues n’en ont pas besoin
La chose intéressante à propos de l’exécution n’est pas que toutes les langues en ont besoin pour exécuter leurs programmes. Prenons par exemple certains langages compilés de type statique. Habituellement, ils sont compilés à l’avance dans des exécutables binaires, et parfois pour les langages modernes comme go, ces exécutables peuvent même être multiplateformes. Lorsque vous exécutez ces exécutables sur un ordinateur, vous n’avez pas nécessairement besoin de préinstaller les bibliothèques requises sur cet ordinateur. Donc, pour ces langages, nous n’avons même pas besoin d’un runtime.
D’autres peuvent avoir quelques runtimes, mais souvent avec une implémentation officielle
Étant un langage de type statique et compilé, Java a besoin d’un runtime, qui est une machine virtuelle appelée Java Virtual Machine (JVM). Lorsque les codes sources Java sont compilés, ils sont transformés en bytecodes, et ces bytecodes seront exécutés dans JVM. Dans un certain sens, python étant un langage interprété est en fait assez similaire à Java : l’interpréteur Python transformerait d’abord les codes source python en bytecodes et ces bytecodes seraient exécutés dans la machine virtuelle Python. La différence est que pour Python, l’interpréteur et la machine virtuelle se trouvent tous les deux dans le même exécutable. Donc, pour ces deux langages, ils nécessiteraient tous deux un runtime, soit pour interpréter et/ou exécuter les codes intermédiaires. Pour Java, il existe différentes JVM ; pour Python, il existe également des alternatives autres que le CPython par défaut. Ce sont tous des environnements d’exécution différents, mais la plupart du temps, nous utilisons toujours l’implémentation de référence par défaut.
Le runtime JavaScript est composé d’un moteur JavaScript et d’implémentations d’autres API
Étant historiquement un langage embarqué, nous utilisons JavaScript pour effectuer des tâches dans l’environnement hôte, la plupart du temps étant un navigateur. Ces tâches, telles que la manipulation DOM, l’ajout d’écouteurs d’événements et la récupération de requêtes HTTP, bien qu’initiées par des codes JavaScript, font toutes partie des API Web et non du langage principal. Ainsi, le navigateur aurait besoin d’un “moteur” pour exécuter ces codes JavaScript pour faire le travail. Le terme “moteur JavaScript” fait écho à l’autre partie majeure d’un navigateur – moteur de rendu, et est plus approprié que “interpréteur JavaScript” puisque les moteurs modernes utilisent également la compilation juste-à-temps pour l’amélioration des performances (il est intéressant de noter que seule la communauté PHP utilise le mot « moteur » pour désigner son interpréteur).
Nous pouvons donc considérer le moteur JavaScript comme un temps d’exécution minimum qui est une implémentation de la spécification ECMAScript, ou le “core JavaScript”, et il n’exécutera JavaScript que de manière synchrone, ce qui n’est pas très utile. Le runtime ajoutera toutes les bonnes choses que nous voulons : pour l’environnement du navigateur, c’est DOM, Fetch et d’autres API Web ; pour l’environnement serveur, ce sont les systèmes de fichiers, la mise en réseau et aussi certaines API Web. Si je peux utiliser une analogie : le moteur JavaScript est comme un cerveau humain capable de comprendre des instructions, et l’environnement d’exécution est l’humain complet avec un cerveau et un corps qui peuvent à la fois comprendre des instructions et effectuer des tâches. Juste pour penser que quelque chose de nécessaire et simple comme l’API de la console n’est pas inclus dans la spécification ECMAScript et a été ajouté par le runtime. Pour constituer ces « corps », ou pour implémenter ces API, il faut aussi utiliser d’autres langages de bas niveau, comme pour Node c’est C++, pour Deno c’est Rust, et pour Bun c’est Zig. Ceux-ci sont tous pilotés par la communauté; L’absence d’une organisation officielle ou d’une implémentation de référence pour le JavaScript côté serveur permet également que l’un ne puisse pas faire de l’ombre aux autres.
Conclusion
Donc voilà, pour les autres langages, soit il n’a pas du tout besoin d’un runtime, soit il a plusieurs runtimes mais un est principalement utilisé. Pour JavaScript, avec plusieurs choix pour les navigateurs Web, nous avons également plusieurs prétendants pour les runtimes, et il y aura toujours de nouveaux venus pour défier le statu quo. Tout comme la façon dont tous les principaux frameworks frontaux se font concurrence et améliorent le Web, je pense que tous les runtimes vont dans la même bonne direction pour JavaScript côté serveur, pour cela nous devons remercier toute la communauté créative et travailleuse contributeurs, qui ne cessent de rendre JavaScript frais et passionnant.
CHARGEMENT EN COURS
. . . & commentaires Suite!