Guide du débutant –

En 2019, l'écosystème Web a évolué à un point tel que le navigateur est un environnement d'exécution pour les applications construites en JavaScript. Cela se reflète dans la rapidité avec laquelle l'industrie propose de nouveaux frameworks, paradigmes, chargeurs et bundles de modules, gestionnaires de dépendances, outils de création et gestionnaires de packages année après année.

Quand JavaScript a été conçu aux premiers jours d'Internet. , la direction du développement d’Internet n’était pas claire. En raison de l'évolution rapide et constante du secteur et de l'écosystème, de la compatibilité ascendante des navigateurs et des normes Web, l'évolution de JavaScript est devenue un flux constant de correctifs, de hacks et de réflexions ultérieures.

Les appareils mobiles actuels sont généralement équipés de 8 cœurs de processeur ou de 12 cœurs de processeur. Les processeurs de bureau et de serveur ont jusqu'à 16 cœurs, 32 threads ou plus.

Dans cet environnement, le fait d'avoir un environnement de programmation ou de script dominant à thread unique est un goulot d'étranglement.

JavaScript Is Single-threaded

Cela signifie que, par conception, les moteurs JavaScript – à l'origine les navigateurs – ont un fil d'exécution principal et, pour le dire simplement, processus ou fonction B ne peut être exécuté avant le processus ou la fonction A . est fini. L'interface utilisateur d'une page Web ne réagit à aucun autre traitement JavaScript alors qu'elle est occupée à exécuter quelque chose – c'est ce qu'on appelle le blocage de DOM .

C'est terriblement inefficace, particulièrement comparé à d'autres langues . ].

Si nous allons à JS Bin et exécutons ce code dans la console JavaScript du navigateur:

 // noprotect
i = 0;
tandis que (i <60000) {
  console.log ("Le nombre est" + i);
  i ++;
}

… l'intégralité du site Web jsbin.com ne réagira plus tant que le navigateur n'aura pas compté – et enregistre – jusqu'à 60 000.

Nous ne pourrons interagir avec rien sur la page, car le navigateur est occupé.

Il s’agit d’un processus informatique relativement peu exigeant et les applications Web d’aujourd’hui impliquent souvent des tâches beaucoup plus exigeantes.

Nous devons être en mesure de calculer les éléments en arrière-plan pendant que l'utilisateur interagit de manière transparente avec la page.

Web Workers

Le W3C a publié un premier projet du standard des travailleurs Web en 2009. La spécification complète est disponible sur sur le site Web du Groupe de travail sur la technologie des applications hypertextes Web – ou WHATWG – un organisme de normalisation Web autre que W3C.

Les utilisateurs Web sont un système ou un protocole asynchrone pour les pages Web. pour exécuter des tâches en arrière-plan, indépendamment du fil principal et de l'interface utilisateur du site Web. Il s'agit d'un environnement isolé isolé de l'objet window de l'objet document d'un accès direct à Internet et qui convient le mieux aux tâches de calcul longues et exigeantes. [19659002] Outre les travailleurs Web – un système dédié au multithreading -, il existe d'autres moyens de réaliser un traitement asynchrone en JavaScript, tels que les appels asynchrones Ajax et la boucle d'événement.

Pour le démontrer, revenons à JS Bin. et essayez cet extrait:

 console.log ("A");
setTimeout (function () {console.log ("B");}, 2000);
console.log ("C");
setTimeout (function () {console.log ("D");}, 0);
console.log ("E");
setTimeout (function () {console.log ("F");}, 1000);

Lorsque nous exécutons cette opération, notre séquence de journal est la suivante: A, C, E, D, F, B . Le navigateur planifie d'abord les opérations sans le délai d'expiration, car elles arrivent, puis exécute les fonctions setTimeout () dans l'ordre de leurs délais spécifiés respectifs. Cependant, cette asynchronicité ne doit pas être automatiquement confondue avec le multithreading. En fonction de la machine hôte, il peut souvent s'agir d'une pile d'un seul thread d'appels dans l'ordre que nous avons expliqué.

Web Workers & Multithreading

Comme Le site de référence JavaScript de Mozilla explique les travailleurs Web. sont un «moyen pour le contenu Web d'exécuter des scripts dans des threads d'arrière-plan».

Nous les utilisons de la manière suivante : nous vérifions la disponibilité du constructeur Worker () dans le navigateur, et s’il est disponible, nous instancions un objet worker avec l’URL du script comme argument. Ce script sera exécuté sur un thread séparé.

Le script doit être exécuté à partir du même hôte ou du même domaine pour des raisons de sécurité. C'est également la raison pour laquelle les travailleurs Web ne fonctionneront pas si nous ouvrons le fichier localement avec un fichier: // schéma.

 if (typeof (Worker)! == "undefined") {
    worker = new Worker ("worker.js");
}

Nous définissons maintenant ce code dans le fichier worker.js :

 i = 0;
tandis que (i <200000) {
    postMessage ("Compteur Web:" + i);
    i ++;
}

La séparation des threads

Il est important de noter ici la séparation de la fenêtre et du document dans le thread de la fenêtre principale du navigateur et du . ] worker scope.

Pour pouvoir utiliser le fil worker ces deux scopes doivent pouvoir communiquer. Pour ce faire, nous utilisons la fonction postMessage () dans le fichier worker.js – pour envoyer des messages au fil du navigateur principal – et le worker.onmessage . écouteur dans le fil principal pour écouter les messages de travailleur .

Nous pouvons également envoyer des messages du fil de navigateur principal au fil ou à la fonction de travailleur . La seule différence est que nous inversons les choses et appelons worker.postMessage () sur le fil principal et onmessage sur le fil à traiter. Pour citer la référence de développeur de Mozilla:

Notez que les messages et postMessage () doivent être suspendus à l'objet Worker lorsqu'ils sont utilisés dans le fil de script principal, mais pas lorsqu'il est utilisé chez le travailleur. En effet, à l'intérieur du travailleur, le travailleur est effectivement la portée globale.

Nous pouvons utiliser la méthode terminate () de la même manière pour mettre fin à l'exécution de notre travailleur.

Cela dit, prenons l'exemple suivant:

. index.html

    
    
    

 début travailleur 
 départ travailleur 


 blocage du thread 



 test de réactivité du navigateur 
  
 et  worker.js : 
 i = 0;
tandis que (i <200000) {
    postMessage ("Compteur Web:" + i);
    i ++;
}
 Cela nous donne l’occasion de tester les effets de l’exécution du thread principal sur le comportement et les performances de la page par rapport aux effets de l’utilisateur Web.
 Dans ce tutoriel, nous avons utilisé  le serveur http  pour servir le serveur Web. fichiers localement.
 
 Nous pouvons maintenant constater que le thread de travail ne bloque pas l'interactivité du processus du navigateur principal et que la lecture en boucle de 200 000 numéros n'affecte pas le thread principal. Les numéros de l'élément  #workerOutput  sont mis à jour à chaque itération.
 Le thread bloquant, ou thread principal, lorsqu'il est engagé dans une boucle, bloque toute interactivité (nous avons défini le nombre d'itérations à 200 000 ici. , mais ce sera encore plus évident si nous augmentons ce nombre à 2 000 000.)
 Une autre chose qui nous indique un thread principal bloqué est que le processus de travail met à jour la page à chaque itération et la boucle dans le thread principal ( celui défini dans  index.html  ne met à jour que l'élément  #mainThreadOutput  de la dernière itération.
 En effet, le navigateur est trop utilisé pour le comptage ( pour  pour pouvoir redessiner le DOM, donc il ne le fait qu'une fois que ses affaires avec la boucle  pour  sont complètement terminées (à la fin de la boucle).
 Conclusion
 Dans cet article, nous avons présenté  des travailleurs Web une technologie qui aide l'industrie du Web à e et des applications Web plus exigeantes. Cela se fait en fournissant aux applications Web un moyen de tirer parti des périphériques multiprocesseurs et multithreads en conférant à JavaScript des superpouvoirs multithreads.
 Les travailleurs Web transforment les environnements de navigateurs de bureau et mobiles en plates-formes d'applications leur fournissant un environnement d'exécution strict. Cette rigueur peut nous obliger à prévoir la copie d’objets entre plusieurs threads et à planifier nos applications en tenant compte de ces contraintes.
 Avez-vous des conseils concernant les travailleurs Web et le Web en tant que plate-forme de programmation? Faites-le-nous savoir dans les commentaires!
 
 
 Tonino est un développeur Web et un consultant en informatique qui utilise le code source ouvert depuis plus de 10 ans. Il est également un passionné de crypto, un fan de Linux et un libertaire modéré.
 Le meilleur outil 2023 pour ta croissance Instagram ! 
 
 
 
   
 
Source link 
Partager :
Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)