Webworker

Aujourd’hui, j’ai mis en place un Web Worker pour gérer un polling sans flinguer l’UI.
Parce que l’asynchrone, ça reste quand même dans le main thread,
et c’est comme un gars qui raconte sa vie en open space :
ça empêche tout le monde de bosser correctement.

Un Web Worker, c’est quoi ?

C’est un script qui tourne en parallèle du thread principal, dans son propre environnement.
Il n’a pas accès au DOM, mais il peut exécuter des tâches lourdes sans bloquer l’interface utilisateur.

Pourquoi c’est cool ?

• 🚀 Performance : Ton thread principal reste libre pour gérer l’UI.
• ⚡ Réactivité : Fini les freezes parce que t’as un calcul ou un appel réseau un peu trop gourmand.
• 🔀 Scalabilité : Tu peux gérer plusieurs tâches en parallèle, comme en backend avec des workers.

Comment je l’ai utilisé ?

Dans mon cas, j’avais un polling qui interrogeait régulièrement une API.
Problème : si je laissais ça dans le main thread, l’UI devenait poussive.
Du coup, j’ai déporté ce polling dans un Web Worker, qui envoie les résultats via postMessage().

Résultat ?

• 🎯 Une UI fluide.
• 😊 Un utilisateur content.
• 💡 Et moi, une petite fierté de dev.

➡️ T’as déjà utilisé les Web Workers sur tes projets ?
Tu les vois utiles où ?