Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage, je m'appelle Nicolas
Brondin Bernard et aujourd'hui on va parler des web-workers, mais juste avant un petit
mot de notre sponsor du jour.
Un réseau mondial de connaissance et l'engagement de vous accompagner à toutes les étapes
de vos projets.
De la recherche à la conception en passant par la maintenance, Farnel, votre fournisseur
de produits électroniques et industriels.
Pour en savoir plus, rendez-vous sur fr.farnel.com.
Alors pour bien comprendre ce qu'est un web-worker, il faut d'abord comprendre comment JavaScript
utilise la capacité de calcul de votre processeur central.
Donc votre CPU, c'est le circuit intégré dans votre machine qui va effectuer tous les
calculs et les opérations qui sont demandées par le système, les applications et autres.
Alors à l'exception évidemment des calculs de rendu graphique qui sont en partie délégués
à votre GPU, du coup votre carte graphique.
Un CPU, il y est décomposé en plusieurs coeurs, pour la plupart en tout cas, et qui
vont chacun travailler de manière simultanée, mais physiquement indépendante, comme si votre
machine était équipée de plusieurs petits processeurs distincts.
Chaque coeur va du coup découper ses flux de calcul en différents threads.
Un thread, c'est une séquence d'instructions qui peut être exécutée de manière indépendante
du reste de manière complètement logique et non plus physique.
JavaScript, lui, est un langage single threaded, ça signifie qu'il utilise qu'un seul et
unique thread pour toute son exécution.
Ça boucle d'événements, ça pile mémoire, etc.
Ce qui signifie que si on exécute un calcul qui prend beaucoup de ressources, toute l'application
risque de ne plus répondre pendant un certain temps jusqu'à ce que le navigateur vous
propose d'arrêter le script bloquant.
Mais heureusement les web workers sont là pour résoudre le problème.
Alors petite explication.
Un worker, c'est un script que le navigateur va exécuter dans un thread séparé du thread
principal.
Le thread principal, il faut savoir qu'il gère l'application JavaScript, mais il gère
également l'interface de la page.
Donc si vous avez des animations en CSS, peu importe, tout ça, c'est géré par cette
unique thread.
Ce qui veut dire que si on fait tout tourner sur le thread principal, on va avoir des
problèmes de performance.
C'est pour ça qu'on va pouvoir séparer des web workers pour gérer un autre thread
et conserver toutes les performances de la page.
Alors comme le worker, il travaille dans un environnement séparé, il ne peut pas communiquer
de manière directe avec l'application JavaScript et toutes les communications aideront à passer
par des événements.
Il est important de comprendre que le worker n'a pas accès à la page, il est uniquement
dédié au calcul, il est uniquement dédié à la gestion d'entrée sortie ou du traitement
de données en dehors de toute interaction graphique.
Par exemple, la variable window globale que vous retrouvez sur toutes les pages ne sera
jamais accessible depuis un worker.
Par contre, des API comme Fetch ou XMLHTTP Request, elles restent toujours accessibles
au worker.
Alors comment ça se passe en pratique ?
En pratique, on va d'abord gérer notre worker, créer notre worker et vérifier qu'il
peut communiquer avec notre page principale.
Donc on va initialiser un worker avec un new worker et dedans on va lui passer l'adresse
relative d'un script.js puisque comme je l'ai dit, un worker c'est un script séparé.
Donc on va initialiser notre worker.
Et ensuite dans notre page, on va indiquer qu'on écoute tous les événements du worker.
Donc tous les événements, ils passent par un seul écouteur qui s'appelle onMessage
et pour envoyer des messages au worker, on peut utiliser MyWorker par exemple, point
post message et on envoie nos informations ici.
Tous les événements vont se passer par notre onMessage et post message.
On peut faire absolument tout ce qu'on veut dans notre worker et justement communiquer
avec notre page et une fois que le web worker aura terminé son exécution, on va pouvoir
lui dire de simplement se terminer, se supprimer.
Donc on va faire un MyWorker.terminate.
C'est très très simple en utilisation.
Vous voyez il n'y a que simplement on initialise, on discute avec, on dialogue, lui il fait ce
qu'il veut de son côté et ensuite on le termine.
Si jamais vous voulez un exemple un peu plus concret que vous pouvez voir comment ça fonctionne
et surtout comment ça influent sur les performances d'une page, je vous ai mis une démo que j'ai
fait à la main où vous avez tout simplement un calcul qui s'exécute soit dans la page
et vous allez voir comment ça ralentit la page ou alors on l'exécute dans un thread
sur le côté grâce à un web worker et donc vous pouvez choisir sur la page selon ce que
vous voulez tester et ça vous donne vraiment une idée beaucoup plus précise de comment
ça marche et même tout simplement une démo pour se baser là dessus et créer votre propre
worker.
J'espère que cet épisode vous a été utile et que vous aurez un petit peu plus un prix
et compris ce qu'est un web worker.
Moi je vous donne rendez vous la semaine prochaine pour un prochain épisode ou directement sur
le site code ThierryGarage.fr pour retrouver tous nos articles, nos podcasts et évidemment
tous nos cours complets pour monter en compétences.
A la semaine prochaine, salut !