Réponses:
Il y a une grande différence dans ce à quoi ils sont destinés:
Travailleurs Web
Les Web Workers fournissent un moyen simple pour le contenu Web d'exécuter des scripts dans les threads d'arrière-plan. Le thread de travail peut effectuer des tâches sans interférer avec l'interface utilisateur. De plus, ils peuvent effectuer des E / S à l'aide de XMLHttpRequest (bien que les attributs responseXML et channel soient toujours nuls). Une fois créé, un worker peut envoyer des messages au code JavaScript qui l'a créé en publiant des messages dans un gestionnaire d'événements spécifié par ce code (et vice versa).
Source - Utilisation de Web Workers
Travailleur de service
Les techniciens de service agissent essentiellement comme des serveurs proxy qui se trouvent entre les applications Web et le navigateur et le réseau (le cas échéant). Ils sont destinés (entre autres) à permettre la création d'expériences hors ligne efficaces, à intercepter les demandes du réseau et à prendre les mesures appropriées en fonction de la disponibilité du réseau et des actifs mis à jour résident sur le serveur. Ils permettront également d'accéder aux notifications push et aux API de synchronisation en arrière-plan.
Les Web Workers sont donc pratiques pour exécuter des scripts coûteux sans geler l'interface utilisateur, tandis que les Service Workers sont utiles pour modifier la réponse des requêtes réseau (par exemple, lors de la création d'une application hors ligne).
La réponse de Buksy est correcte mais à mon avis elle ne répond pas à la question initiale, à savoir: "Que peuvent faire les techniciens de service que les web workers ne peuvent pas? Ou vice versa?"
Il existe des différences fondamentales dans leur cycle de vie et le nombre d'instances par origine que vous pouvez avoir. En bref:
| Web Workers | Service Workers |
|--------------|--------------|------------------|
| Instances | Many per tab | One for all tabs |
| Lifespan | Same as tab | Independent |
| Intended use | Parallelism | Offline support |
La réponse de Buksy est essentiellement la dernière ligne du tableau. Crédit: J'ai pris ce tableau de Demystifying Web Workers and Service Workers par Nolan Lawson, à partir de la diapositive 35 .
En particulier, voici comment vous créez et arrêtez des web workers:
considérant que les travailleurs des services ont leur propre cycle de vie, qui est certes leur «partie la plus compliquée»:
Le cycle de vie du service Worker
Le style de vie est donc une différence fondamentale entre les deux (une conséquence de leur utilisation prévue).
Il y avait une énorme différence dans la prise en charge des navigateurs : les techniciens de service n'étaient pas du tout disponibles dans Safari pour iOS jusqu'au 11.3 (29 mars 2018), voir Puis-je utiliser des techniciens de service? En revanche, les web workers avaient déjà une bien meilleure prise en charge du navigateur en 2012: puis-je utiliser des web workers?
Si vous devez prendre en charge IE11, vous ne pouvez utiliser que des web workers: IE11 n'a pas de service workers et apparemment la fin du support pour IE11 est le 14 octobre 2025 .
Il existe des différences subtiles dans leur prise en charge d'API entre les navigateurs, voir HTML5 Worker Test (également par Nolan Lawson). Dans un navigateur particulier, un type de worker peut prendre en charge un certain appel d'API alors que l'autre ne le fait pas. Visitez cette page et testez votre propre navigateur!