Quels sont les cas d'utilisation des Web Workers? [fermé]

174

Je recherche des scénarios du monde réel pour utiliser l' API Web Workers .

javascript html web-worker

— Sergey Ilinsky
source

Sont-ils pris en charge par les plateformes mobiles / webkit?

— dmp

Je ne sais pas avec certitude, mais je suppose qu'ils le sont.

— Sergey Ilinsky

Support du navigateur @danp: caniuse.com/webworkers

— Dheeraj Vepakomma

J'ai écrit un cas où nous avons d'abord utilisé un travailleur Web, puis j'ai déterminé que nous étions mieux sans lui - windward.net/blogs/web-workers-abandon/#.Vl3QdXarQ-U

— David Thielen

Réponses:

143

John Resig (de renommée jQuery) a un tas d'exemples intéressants d'utilisation de web workers ici - jeux, graphiques, crypto.
Une autre utilisation est l'E / S Web - en d'autres termes, interroger les URL en arrière-plan. De cette façon, vous ne bloquez pas l'interface utilisateur en attente des résultats de l'interrogation.
Une autre utilisation pratique: dans Bespin, ils utilisent Web Workers pour faire la coloration syntaxique, ce que vous ne voudriez pas bloquer l'édition de code pendant que vous utilisez l'application.
De Mozilla : Une des façons dont les travailleurs sont utiles est de permettre à votre code d'effectuer des calculs gourmands en ressources processeur sans bloquer le thread de l'interface utilisateur.

À titre d'exemple pratique, pensez à une application qui a une grande table de #s (c'est le monde réel, BTW - tiré d'une application que j'ai programmée il y a environ 2 ans). Vous pouvez changer un # dans une table via un champ de saisie et un tas d'autres nombres dans différentes colonnes sont recalculés dans un processus assez intensif.

L'ancien workflow était: Modifiez le #. Allez prendre un café pendant que JavaScript passe à travers les modifications apportées à d'autres chiffres et que la page Web ne répond plus pendant 3 minutes - après l'avoir optimisée en enfer et vice-versa. Revenez avec un café. Changer un deuxième #. Répétez plusieurs fois. Cliquez sur le bouton ENREGISTRER.

Le nouveau workflow avec les workers pourrait être: Modifiez le #. Obtenez un message d'état indiquant que quelque chose est en cours de recalcul, mais vous pouvez modifier d'autres #. Changer plus de numéros. Une fois le changement terminé, attendez que le statut passe à "Tous les calculs sont terminés, vous pouvez maintenant revoir les # finaux et enregistrer".

— DVK
source

Grands liens! Je n'avais jamais entendu parler des travailleurs ... mmm, des travailleurs. (Il est temps d'aller prendre une longue douche chaude ...)

— Peter Rowell

Je sais que c'est une réponse vieille de deux ans, mais je voulais juste mentionner que vous ne devriez pas avoir besoin de Web Workers pour l'élément n ° 2 (URL d'interrogation). XHR se produit de manière asynchrone et ne bloque pas; il n'est pas nécessaire d'exécuter des requêtes XHR sur un thread séparé. (Bien sûr, dans une application moderne, vous voudriez utiliser WebSockets au lieu d'interroger.)

— josh3736

@ josh3736 - Vous avez raison, mais je suis maintenant curieux de savoir si faire de nombreuses requêtes Aync XHR parallèles peut en quelque sorte rendre le navigateur malheureux? De plus, vous avez besoin de ressources locales pour traiter les réponses XHR là où les agents peuvent être utiles.

— DVK

Si toutes les demandes parallèles sont adressées au même serveur, vous atteindrez la limite par nom d'hôte entre 2 et 9 connexions simultanées. (Je suppose que la limite s'applique à toutes les connexions, qu'elles soient initiées à partir du thread principal ou d'un worker.) Bien sûr, si vous avez 10 demandes simultanées en cours d'exécution, vous devez probablement repenser la conception de votre application.

— josh3736

Excusez ma simple question, mais à quoi vous référez-vous par «#» dans votre exemple ci-dessus?

— shrewdbeans

Je les ai utilisés pour envoyer de plus grandes quantités de données du navigateur au serveur. Évidemment, vous pouvez le faire avec des appels AJAX réguliers, mais si cela prend l'une des précieuses connexions par nom d'hôte. De plus, si l'utilisateur effectue une transition de page pendant ce processus (par exemple, clique sur un lien), vos objets JavaScript de la page précédente disparaissent et vous ne pouvez pas traiter les rappels. Lorsqu'un travailleur Web est utilisé, cette activité se produit hors bande, vous avez donc une meilleure garantie qu'elle se terminera.

— Kevin Hakanson
source

Mais vous devez échanger le message avec le web-worker. Quand le coût de cette opération mérite-t-il le bénéfice?

— Danielo515

Un autre cas d'utilisation:

Compression / décompression de fichiers en arrière-plan, si vous avez beaucoup d'images et d'autres fichiers multimédias échangés depuis le serveur au format compressé.

— sbr
source

Cela ne devrait pas se produire en JavaScript. Les images sont déjà compressées (PNG, JPEG) à l'aide d'algorithmes conçus pour compresser efficacement les données d'image. Jeter une autre couche de compression sur le dessus peut en fait augmenter la taille des données. Pour les autres types de données (par exemple un gros fichier JSON), la compression doit être gérée par le navigateur en utilisant le gzipping HTTP standard. Si vous faites de la compression en JavaScript, vous le faites probablement mal .

— josh3736

Je vois certains utilisateurs disqualifier le cas d'utilisation, mais voici ce que je voulais dire. considérez une application comme MS word, comme un puissant éditeur de documents grâce auquel vous pouvez intégrer des images, des fichiers musicaux, des données, des feuilles Excel, etc., le tout dans UN seul fichier. et considérez que vous avez un client Web et un client de bureau et un client IOS / Android. Pour ce type de cas d'utilisation, vous pouvez stocker tout le contenu du fichier dans un fichier zip, puis le décompresser sur chaque client.

— sbr

Le bookmarklet Instapaper compresse la page en cours d'enregistrement avant de l'envoyer au serveur. Cela économise du temps et de la bande passante.

— stevendaniels

@ josh3736 La seule chose qu'un navigateur peut faire est de gunzip un fichier depuis un serveur Web (ou le cache du navigateur). Il ne peut pas décompresser les données du stockage local, ni d'un websocket, et il ne peut pas du tout compresser. Les applications Web envoient une quantité toujours croissante de données en amont, et la compression pour cela est extrêmement utile. Tout aussi valable il y a un an lorsque cela a été publié: si vous ne pouvez penser à aucun cas d'utilisation valide pour la compression JavaScript, vous manquez probablement d'imagination.

— Adria

@Adria: Le standard websocket est en train d' ajouter la prise en charge de la compression . Si vous avez affaire à des images générées dans le navigateur ( <canvas>), vous pouvez obtenir les données d'image dans un format compressé (par exemple png). Mon point n'était pas qu'il n'est jamais approprié de compresser dans JS; mon point était que dans la plupart des cas , ce n'est pas le cas , et dans la plupart des cas - en particulier en ce qui concerne les images, ce dont parle cette réponse - il existe une meilleure alternative au roulement de votre propre compression.

— josh3736