Salut et bienvenue dans un nouvel épisode de Code Garage. Moi je m'appelle Nicolas
Brondin-Bernard et aujourd'hui on va parler de Node.js. Alors je le vois souvent passé
dans des CV ou des portfolios, dans la rubrique « L'Engage », je vois « JavaScript » et
derrière « Node.js ». Et même si la confusion est compréhensible, c'est vraiment important
de comprendre la vraie nature de Node.js. Parce que je le répète, pardon, c'est le
« Ce n'est pas un langage de programmation ». Node.js, c'est ce qu'on appelle un environnement
d'exécution. Un environnement d'exécution, c'est simplement un endroit où on va faire
tourner du code en l'occurrence, du code JavaScript. Et pour Node.js, c'est en dehors
du navigateur. C'est un environnement qui est open source et cross-platform, puisque
vous pouvez l'exécuter sur Windows, Mac, Linux, etc. Et il est majoritairement utilisé
pour exécuter tout simplement des scripts, JavaScript, mais côté serveurs. Il a une
popularité qui est toujours grandissante, notamment chez les développeurs juniors, parce
que justement, ça permet de réutiliser des scripts qu'on a développés dans le côté
navigateur pour s'en servir côté serveurs et donc potentiellement éviter d'apprendre
un nouveau langage ou en tout cas gagner du temps sur l'apprentissage d'un nouveau
langage et de réutiliser quelque chose qu'on connaît déjà et qu'on utilisait du côté
front-end. L'origine de Node.js, il y a déjà des
prémices en 1996. Il y a l'entreprise Netscape qui est donc éditrice du très célèbre navigateur
web qui s'appelle Netscape, qui lance Netscape LiveWire. C'est donc la première tentative
de créer un moteur d'exécution JavaScript en dehors du navigateur qui fait son apparition
1996, mais évidemment, plutôt malheureusement, ce dernier n'en rencontrera jamais le succès
attendu parce qu'à l'époque, ce n'était pas encore trop dans les mercs et dans les idées
des gens de faire ça. Deux ans plus tard, Netscape lancera un nouveau projet qui s'appellera
Rino. C'est un moteur d'exécution JavaScript, un environnement d'exécution JavaScript entièrement
développé en Java et qui va permettre d'exécuter, plutôt de compiler du code JavaScript en
bytecode Java et de générer les classes correspondantes. C'était globalement pour faire tourner
JavaScript dans du Java. C'est seulement en 2009 que Ryan Dahl écria la première version de notre
JS. Tout simplement, lui à l'origine, c'est pour pallier aux contraintes techniques du
serveur web Apache et principalement l'une de ses plus grosses contraintes qui est de pouvoir
gérer plus de 10 000 connexions simultanées. Ce n'est pas forcément une contrainte que
tout le monde rencontre, mais sur des gros projets à grande échelle, ça vient effectivement
une contrainte. Ryan Dahl en 2009 se dit, « Ok, moi, j'ai envie de créer cet environnement
d'exécution-là en JavaScript et de faire en sorte que ça puisse gérer plus de 10 000 connexions
simultanées ». Comment est-ce que ça fonctionne notre JS ? On ne va pas rentrer trop dans les
détails, mais globalement, notre JS, d'abord, il est écrit en C++ et il est basé sur le moteur
d'exécution V8. Le moteur V8, c'est un moteur open source développé par Google et qui est
intégré à Chrome tout simplement. Ce moteur-là, il implémente une boucle d'événement et une API
d'entrée sortie banniveau. Il est intégré directement dans Chrome à l'origine. Le fait
qu'il soit basé sur une architecture événementielle et qu'il soit capable de gérer des entrées
sorties de manière à synchrone, ça lui permet de gérer un flux de données très rapide et d'être
optimisé pour des systèmes temps réels. Et la gestion de requêtes concurrentes est du coup bien
meilleure que celle de la page. Je vous mettrai un lien de benchmark si ça vous intéresse dans les notes
du podcast. Mais par contre, il y a une limitation, c'est que le moteur est obligé de tourner sur un seul
trade. Un trade, c'est un souceur virtuel du processeur, plus ou moins. Je reste vague là-dessus
pour ne pas vous perdre. Ce qui lui permet pas d'être le plus performant sur des gros calculs.
Il est performant sur plein de petits calculs, plein de petites requêtes, mais pas sur les gros
calculs car il n'y a pas de parallélisation, pas d'utilisation en multithread. Il y a un petit
truc à noter aussi, c'est que Node.js est uniquement capable de faire tourner du code JavaScript. Si on
veut utiliser du TypeScript, il faudra d'abord passer par un compilateur TypeScript qui compilera
ça en JavaScript et on pourra le faire tourner dans Node. On parle beaucoup de Node, mais est-ce
qu'il y a une alternative ? Est-ce qu'on est obligé de passer par cet environnement d'exécution
là pour faire tourner du JavaScript sur un serveur ? Non, en 2018, le créateur de Node.js,
Ryan Dahl, il a annoncé qu'il travaillait sur un nouvel environnement d'exécution JavaScript qui s'appelle
Deno. Deno, c'est simplement Node à l'envers et qui est pour lui censé résoudre les erreurs
qui regrette d'avoir commise en créant Node.js. La version 1.0 de Deno a été publiée en mai 2020
et je vous mettrai si jamais ça vous intéresse le lien pour aller voir un petit peu. Dans les
principales différences, on a dit que Node.js et donc le V8 sont écrits en C++, Deno, lui,
est écrit en Rust. Je ne suis pas un expert banniveau, donc je ne pourrais pas vous donner
exactement les pours et les comptes de chaque langage, mais Rust est en très forte expansion
sur le côté banniveau et le côté système. Ce n'est pas si étonnant que ça. Il y a la
gestion des dépendances aussi qui est intégrée et non pas dans une terres partie comme avec NPM,
Yarn, etc. Donc là, la gestion des dépendances est intégrée au langage, enfin au langage non,
du coup, attention, à l'environnement d'exécution. TypeScript, lui, est nativement géré par Deno,
contrairement à Node et il y a une librairie standard qui est présente pour offrir du cours
un développement basé sur du code officiel testé et révisé, tout simplement par rapport à Node
ou la librairie standard. Ce sont des modules qu'on vient inclure, des modules externes.
Pour l'instant, on n'en est pas encore à voir, en tout cas, j'ai jamais vu d'applications en
prod tournées sur un environnement d'Eno, mais peut-être que ça ne serait tardé, je ne sais pas.
En tout cas, voilà. Ce qu'il faut retenir tout simplement, c'est que Node.js n'est pas un
langage, c'est un environnement d'exécution et il existe d'autres environnements d'exécution,
en plus du navigateur et de Node. Il existe par exemple Deno. Et la dernière chose, c'est que Node.js,
on s'en sert souvent pour du code serveur, mais on ne s'en sert pas que pour ça. Par exemple,
on a des frameworks comme Electron qui permettent de faire des applications de bureaux,
tout simplement basés sur le moteur V8 et sur l'environnement Node pour exécuter
la non pas des réseaux des applications, on va dire des serveurs web, mais tout simplement pour
afficher, pour lancer une application, faire tourner une application bureau. Voilà. J'espère que
cet épisode vous aura plu et vous aura apporté des réponses à vos questions. Et moi sur ce,
je vous dis une bonne journée, une bonne semaine et à très vite.