Que peuvent faire les employés de service que les employés Web ne peuvent pas?
Que peuvent faire les employés de service que les employés Web ne peuvent pas? Ou vice versa?
Il semble que les travailleurs Web constituent un sous-ensemble de leurs fonctionnalités. Est-ce correct?
Il y a une grande différence dans ce à quoi ils sont destinés:
Web Workers
Les travailleurs Web fournissent au contenu Web un moyen simple d'exécuter des scripts dans des threads d'arrière-plan. Le thread de travail peut effectuer des tâches sans interférer avec l'interface utilisateur. En outre, ils peuvent effectuer des E/S à l'aide de XMLHttpRequest (bien que les attributs responseXML et channel soient toujours nuls). Une fois créé, un travailleur peut envoyer des messages au code JavaScript qui l'a créé en publiant des messages sur un gestionnaire d'événements spécifié par ce code (et inversement).
Source - Utilisation de Web Workers
Agent de service
Les employés de service agissent essentiellement en tant que serveurs proxy situés entre les applications Web, le navigateur et le réseau (le cas échéant). Ils sont notamment destinés à permettre la création d’expériences hors ligne efficaces, l’interception des requêtes réseau et la prise des mesures appropriées en fonction de la disponibilité du réseau et de la disponibilité des ressources mises à jour sur le serveur. Ils permettront également l'accès aux notifications Push et aux API de synchronisation en arrière-plan.
Les travailleurs Web sont donc pratiques pour exécuter des scripts coûteux sans provoquer le gel de l'interface utilisateur, alors que les travailleurs du service sont utiles pour modifier la réponse à partir de requêtes réseau (par exemple, lors de la création d'une application hors connexion).
La réponse de Buksy est correcte mais, à mon avis, elle ne répond pas à la question initiale, à savoir: "Que peuvent faire les prestataires de services que les opérateurs Web ne peuvent pas? Ou vice versa? "
Il existe des différences fondamentales dans leur cycle de vie et le nombre d'instances que vous pouvez avoir par origine. 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 Démystifier les ouvriers de Web et de service par Nolan Lawson, à partir de diapositive 35 .
En particulier, voici comment générer et mettre fin aux travailleurs Web:
alors que les travailleurs des services ont leur propre cycle de vie, ce qui est sans aucun doute leur "partie la plus compliquée":
Le cycle de vie du travailleur de service
Le cycle de vie constitue donc une différence fondamentale entre les deux (conséquence de leur utilisation prévue).
Il existait une énorme différence dans la prise en charge du navigateur: les travailleurs du service n’étaient pas disponibles du tout dans Safari pour iOS jusqu’à 11.3 (le 29 mars 2018), voir Puis-je utiliser des travailleurs du service? En revanche, les travailleurs du Web avaient un meilleur support du navigateur déjà en 2012: Puis-je utiliser des travailleurs Web?
Il existe des différences subtiles dans la prise en charge des API entre les navigateurs, voir HTML5 Worker Test (également de Nolan Lawson). Dans un navigateur particulier, un type de travailleur 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!