Dégradation gracieuse avec les travailleurs Web

Question

Donc, je commence à entendre de plus en plus sur Web Workers. Je pense que c'est absolument fantastique, mais la question à laquelle personne n'a encore vraiment réfléchi jusqu'ici est de savoir comment prendre en charge les anciens navigateurs qui ne sont pas encore compatibles avec la nouvelle technologie. La seule solution que j'ai pu trouver jusqu'à présent est de créer une sorte d'encapsulation autour de la fonctionnalité de travail web qui reviendrait à une solution basée sur une minuterie folle qui simulerait l'exécution multi-thread.

Mais même dans ce cas, comment détecter si les web workers sont une fonctionnalité supportée par le navigateur qui exécute actuellement le javascript?

Merci!

Answer 1

Voici le vieux problème du développement web: que faire des navigateurs qui ne supportent pas ce dont vous avez besoin? Actuellement, je préconise uniquement l'utilisation de Web Workers pour des tâches complexes et de longue durée qui peuvent être interrompues et qui, pour une raison quelconque, ne peuvent pas être effectuées côté serveur. De cette façon, si vous n'avez pas de Web Workers, vous attendez plus longtemps. Sinon, vous devrez faire un gâchis de votre code avec des wrappers et ce que vous allez essayer d'éviter plus tard. Ma stratégie de dégradation se produit dès que la page est chargée.

fonction onload pseudocode:

if(window.Worker /*check for support*/) 
    someObject.myFunction = function() { /*algorithm that uses Web Workers*/ } 
else 
    someObject.myFunction = function() { /* sad face */ } 

Il vous reste à écrire l'algorithme deux fois, mais vous devez le faire de toute façon si vous voulez soutenir les navigateurs sans travailleurs sur le Web. Cela soulève donc une question intéressante: vaut-il le temps (et l'argent) d'écrire quelque chose deux fois, juste pour que ça puisse aller un peu plus vite pour certaines personnes?

Answer 2

Voici ce que John Resig dit replying to a comment on his blog

Je pensais à ce sujet - mais ça va être difficile. Vous devrez faire en sorte que votre code de traitement utilise setTimeout/setInterval dès le début (ce code finirait par fonctionner à la fois dans un worker et sur un site web normal). Ainsi, alors que le résultat serait légèrement plus lent pour les navigateurs activés par les travailleurs, il fonctionnerait au moins dans les deux cas.

Answer 3

Le projet Bespin a (ce qu'ils appellent) un facade qui leur permet d'exécuter du code JavaScript dans les Web Workers, les travailleurs Gears et si ce ne sont pas disponibles dans le thread principal.

Answer 4

Après avoir mâché sur ce pendant quelques jours, je fini par écrire un article sur mon blog:
http://codecube.net/2009/07/cross-platform-javascript-webworker/

L'idée est que dans les cas où WebWorker n'est pas défini, il y a une API wrapper qui vient utilise techniques intégrées. Bien que l'exemple dans l'article soit très simple, il fonctionne dans tous les navigateurs :-)

Answer 5

J'ai eu le drôle de problème que ma tâche sans le support de Web Worker soit trop lente dans Firefox (script qui ne répond pas), mais assez rapide dans tous d'autres navigateurs modernes. Avec Web Workers, il a fonctionné dans tous les navigateurs sauf Opera (10.50) qui ne supporte pas du tout les Web Workers, mais Opera a bien fonctionné sans eux.

J'ai donc écrit un WorkerFacade qui utilise l'API Web Worker lorsqu'elle est disponible ou qui fausse l'API avec quelques ajouts mineurs au Worker JS. Vous pouvez trouver WorkerFacade as a gist on GitHub. Travaillé bien pour moi, pourrait aider quelqu'un d'autre aussi.

Answer 6

Vous pouvez utiliser Modernizr (http://modernizr.com/download/#-webworkers) pour détecter si le navigateur prend en charge webworkers, à quel point vous avez alors deux versions ... Vous pouvez voir les navigateurs avec webworkers à http://caniuse.com/webworkers

if(Modernizr.webworkers) 
{} 
else 
{} 

Answer 7

@ geowa4 De cette façon, vous libérez de la mémoire en charge et vous n'avez pas besoin de demander de support à chaque fois.