Comment fonctionne JavaScript sous le capot ?

Cet article vise vraiment à expliquer de manière simple comment JavaScript fonctionne sous le capot afin que même un nouveau programmeur soit capable de saisir le concept et de visualiser ce qui se passe lors du codage de JavaScript.
Pour commencer, il y a au moins 3 questions sur lesquelles je voulais me concentrer et qui permettront de surmonter les difficultés et d'intérioriser la logique derrière ?
Ces questions sont également celles qui sont susceptibles d'être posées lors des entretiens d'embauche pour les développeurs Web où JavaScript implique :

1. Comment fonctionne JavaScript ?
2. Expliquez la différence entre synchrone et asynchrone ?
3. Ou expliquez cette affirmation : JavaScript est un langage à thread unique qui peut être non bloquant ?

Vraiment, Il n'est pas nécessaire de savoir comment fonctionne JavaScript en interne pour écrire un programme mais il est essentiel et crucial d'apprendre afin de comprendre ce qui se passe derrière et ressentir ce que vous écrivez d'où certains des nombreux développeurs qui ont de nombreuses années en transporteur, je m'en fiche de savoir ça.

Permet d'abord de savoir qu'est-ce qu'un programme ? Un programme est simplement un ensemble d'instructions qui indiquent à un ordinateur quoi faire et comment exécuter la tâche. Le programme doit allouer de la mémoire, sinon nous ne pourrons pas avoir de variables ni même sauvegarder des fichiers sur nos ordinateurs. Le programme doit également analyser (lire) et exécuter une tâche dédiée et tout se passe dans une mémoire.

Maintenant, JavaScript dispose d'un moteur connu sous le nom de Moteur JavaScript que chaque navigateur implémente. Par exemple dans Chrome, il s'appelle V8, dans Mozilla Firefox : Spider Monkey, dans le navigateur Safari : JavaScript Core Webkit.

L'image suivante montre le moteur V8 de Google Chrome

Que se passe-t-il dans le moteur JavaScript ?

Le moteur JavaScript comme V8 dans Chrome lit les codes JavaScript que nous écrivons et les convertit en instructions exécutables par machine pour le navigateur. La figure ci-dessus montre des parties du moteur JavaScript qui se composent de deux parties, à savoir Un tas de mémoire **et **Une pile d'appels.

Il est également important de noter que l'allocation de mémoire s'effectue dans le tas de mémoire, tandis que l'analyse (lecture) et l'exécution ont lieu dans la Call Stack. En plus de cela, c'est le tas de mémoire qui vous indique où vous en êtes dans le programme.

Voyons l'allocation de mémoire dans le tas de mémoire avec les codes JS (JavaScript)

const a = 4;  // now we allocated a memory. JS engine is going to remember
// that a has a value of 4. 

const Obj = {a, b, c };  // In memory, variable 'Obj' holds the object {a, b,c}

// The same as on array. the engine will remember values of the array
const Array = [1,2,3,4,5]

Alors, quel est le problème avec le code ci-dessus une fois déclaré globalement ?

Il y a quelque chose appelé Fuite de mémoire. Comme mentionné ci-dessus, la déclaration de variable s'effectue dans le tas de mémoire et sa taille est limitée à allouer. Lorsque vous continuez à déclarer des variables globales qui sont de très grands tableaux au lieu de nombres et même inutilisées, cela remplit la mémoire et entraîne la Fuite de mémoire. Vous entendrez que les variables globales sont mauvaises car lorsque nous oublions de nettoyer, nous remplissons ce tas de mémoire et finalement le navigateur ne pourra pas fonctionner.

Qu'en est-il de la pile d'appels ?

Si on s'en souvient, c'est la Call Stack qui lit et exécute les scripts. Utilisons des codes pour que ce soit clair.

const a = 4;  // now we allocated a memory. JS engine is going to remember
// that a has a value of 4. 

const Obj = {a, b, c };  // In memory, variable 'Obj' holds the object {a, b,c}

// The same as on array. the engine will remember values of the array
const Array = [1,2,3,4,5]

Avec les codes ci-dessus, le call Sack lit la première ligne console.log("x"); et est placé dans la pile d'appels, le moteur JavaScript reconnaît que le console.log a été ajouté, puis l'insère dans la pile d'appels, l'exécute et génère x. Après, il supprime le premier console.log lorsqu'il a fini de l'exécuter et le place dans le deuxième console.log("y"), l'ajoute sur la pile d'appels, exécute y et supprime le deuxième console.log. Obtient enfin console.log("z") en utilisant le même processus.

C'est la démo la plus simple, et si c'était un exemple un peu plus complexe ? Donnons un exemple typique :

// Example Call Stak

console.log("x");
console.log("y");
console.log("z");

// Result in browser

// x
// y
// z

Maintenant, que s'est-il passé dans le code ci-dessus selon la pile d'appels ? Voyons comment il exécutera le bloc de code ci-dessus :

//PILE D'APPELS

La fonction example1() sera exécutée en premier, puis la fonction example2() vient au-dessus de la pile d'appels et est exécutée, ce qui imprime le numéro 7 en sortie après avoir vérifié s'il y a d'autres codes à exécuter. Après cela, il commencera à être supprimé de la pile d'appels dans l'ordre commençant par console.log('7'), example2(), example1() et la pile d'appels est maintenant vide.

> Est-ce qu'on se souvient de cette déclaration ? JavaScript est un langage à thread unique qui peut être non bloquant.

Un seul thread signifie qu'il n'a qu'une seule pile d'appels. Il ne peut effectuer qu'une seule chose à la fois et il est important de souligner que la La pile d'appels est premier entré, dernier sorti comme une pile.

D'autres langages peuvent avoir de nombreuses piles d'appels, ce qu'on appelle multi-thread, ce qui pourrait être plus avantageux d'avoir plusieurs piles d'appels afin de ne pas attendre les tâches.

> Mais pourquoi JavaScript a-t-il été conçu pour être à thread unique ?

Pour répondre à cette question, exécuter normalement du code sur un seul thread peut être assez simple puisqu'il n'y a pas de scénarios compliqués qui se produisent dans un environnement multithread. En fait, vous avez une chose à laquelle vous soucier. En multithread, il peut y avoir des problèmes tels que des Deadlocks. Avec cette théorie, on peut facilement savoir ce que signifie une Programmation synchrone.

La programmation synchrone signifie simplement : la première ligne de code est exécutée, la deuxième suit et la troisième est exécutée etc…

Pour être plus explicite, cela signifie que console.log(“y”) ne peut pas s'exécuter tant que console.log(“x”) n'est pas terminé et console.log (« z ») ne démarre pas avant la fin des deux premiers car il s'agit d'une Call Stack.

Il est probable que les programmeurs utilisent le site stackoverflow.com. que signifie le nom ? Bien. voyons :

Comment se produit le débordement de pile

L'image ci-dessus montre comment une fuite de mémoire peut se produire et comment la mémoire d'un moteur JavaScript peut déborder. Ici, la pile d'appels reçoit de nombreuses entrées supérieures à sa taille et déborde.

Il est possible de démontrer le débordement de pile à l'aide du code :

const a = 4;  // now we allocated a memory. JS engine is going to remember
// that a has a value of 4. 

const Obj = {a, b, c };  // In memory, variable 'Obj' holds the object {a, b,c}

// The same as on array. the engine will remember values of the array
const Array = [1,2,3,4,5]

N'oubliez pas que JavaScript est un thread unique, une seule instruction est exécutée à la fois. Voici un problème maintenant : et si console.log(“y”) dans le bloc de code suivant a une grosse tâche qui prendra plus de temps à être exécuté par exemple en parcourant un tableau contenant des milliers ou des millions d'éléments ? que se passerait-il là-bas ?

// Example Call Stak

console.log("x");
console.log("y");
console.log("z");

// Result in browser

// x
// y
// z

La première ligne s'exécutera et supposera que la deuxième ligne a un travail énorme à effectuer, donc la troisième ligne attendra une longue période pour être exécutée. Dans l’exemple ci-dessus, cela ne veut pas dire grand-chose, mais pensons à un gros site Web qui effectue des opérations lourdes, l’utilisateur ne pourrait rien faire. Le site Web se bloquera jusqu'à ce que la tâche soit terminée et que l'utilisateur y attende. C'est une mauvaise expérience en ce qui concerne la performance.

Eh bien, avec les tâches synchrones, si nous avons une fonction qui prend beaucoup de temps, elle va retarder la file. Il semble donc que nous ayons besoin de quelque chose de non bloquant. Rappelez-vous la déclaration que j'ai mentionnée ci-dessus : JavaScript est un langage à thread unique qui peut être non bloquant.

Idéalement, en JavaScript, nous n'attendons pas les choses qui prennent du temps. Alors, comment contourner ce problème ?

En guise de secours, il existe la Programmation asynchrone. Alors, qu'est-ce que c'est ?

Pensez à l'asynchrone comme à un comportement. L'exécution synchrone est excellente car elle est prévisible. En synchrone, nous savons ce qui se passe en premier, ce qui se passe ensuite, etc., mais cela peut devenir lent.

Lorsque nous devons faire des choses comme le traitement d'images ou faire des requêtes sur le réseau comme des appels API, nous utilisons quelque chose de plus que de simples tâches synchrones qui sont asynchrones.

Voyons comment faire de la programmation asynchrone avec des codes :

const a = 4;  // now we allocated a memory. JS engine is going to remember
// that a has a value of 4. 

const Obj = {a, b, c };  // In memory, variable 'Obj' holds the object {a, b,c}

// The same as on array. the engine will remember values of the array
const Array = [1,2,3,4,5]

Maintenant, sur la base des codes ci-dessus, il semble que nous ayons sauté la deuxième ligne, exécuté la troisième et attendu 3 secondes pour afficher le résultat. c'est un événement asynchrone.

Afin de comprendre cela et ce qui s’est passé, utilisons la figure suivante.

Environnement d'exécution JavaScript

Pour que JavaScript s'exécute, nous avons besoin de plus que du tas de mémoire et de la pile d'appels. nous avons besoin de ce qu'on appelle JavaScript Run-Time qui fait partie du navigateur. il est inclus dans les navigateurs. Au-dessus du moteur, il y a quelque chose appelé API Web, file d'attente de rappel et boucle d'événements comme indiqué sur la figure.

Discutons maintenant du code dans lequel nous utilisons la fonction setTimeout.

// Example Call Stak

console.log("x");
console.log("y");
console.log("z");

// Result in browser

// x
// y
// z

La fonction setTimeout fait partie de l'API Web et ne fait pas partie de JavaScript, c'est plutôt ce que les navigateurs nous donnent à utiliser pour nous permettre de faire de la programmation asynchrone. alors, fournissons plus de détails pour clarifier.

PILE D'APPELS : Le console.log("x") va dans la pile d'appels, s'exécute et nous console.log dans le navigateur. Après cela, setTimeout(() =>{console.log("y");},3000); va dans la pile d'appels car la première tâche est terminée puis passez à la seconde.

Maintenant, voici un truc, en lisant le code, la pile d'appels détectera qu'il y a une fonction setTimeout qui a été définie et qui ne fait pas partie de JavaScript mais de l'API web ( Voir la figure JavaScript Run-Time Environment ) et possède des caractéristiques particulières. Ce qui se passe, c'est que setTimeout déclenche l'API WEB et comme l'API Web est notifiée, la fonction sera retirée de la pile d'appels.

Maintenant, l'API web démarre un chronomètre de trois secondes sachant qu'en 3 secondes elle doit effectuer la tâche. N'oubliez pas ici, car la pile d'appels est vide, le moteur JavaScript continue jusqu'à la ligne 3 qui est console.log("z"); et exécutez-le. C'est pourquoi nous avons obtenu le résultat x,z mais nous avons setTimeout trois secondes dans l'API Web. puis, après trois secondes, lorsque le délai est écoulé, setTimeout s'exécute et voit ce qu'il contient et c'est fait. Une fois que c'est fait, l'API Web reconnaîtra qu'elle dispose d'une fonction callback() de setTimeout et l'ajoutera à la QUEUE DE RAPPEL étant prête à l'exécuter.

Nous arrivons à la dernière partie qui est** EVENT LOOP*. Celui-ci vérifie en permanence si la pile d’appels est vide. Lorsqu'il est vide et que rien n'est en cours d'exécution dans le moteur JavaScript, il vérifiera la file d'attente de rappel et trouvera notre fonction **callback()* avec console.log("z") puis placez-le dans CALL STACK et s'exécute. Une fois que c'est fait, sortez-le de la pile d'appels. Maintenant, tout est vide et obtenez le résultat x z y.

Conclusion : Dans cet article, nous avons vu de nombreuses informations sur ce qui se passe sous le capot pour comprendre complètement la logique JavaScript, les tâches exécutées de manière synchrone et asynchrone.

J'espère que cela aidera les programmeurs JavaScript nouveaux et avancés à apprécier le codage dans des frameworks liés à JavaScript comme ReactJS ou AngularJS, car c'est la base sur laquelle commencer pour comprendre la logique avancée.

> Bon codage

Références

https://www.freecodecamp.org/news/how-javascript-works-behind-the-scenes.
https://www.simplilearn.com/tutorials/javascript-tutorial/callback-function-in-javascript#

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!