Un trabajador de servicio tiene una funcionalidad adicional más allá de lo que está disponible en los trabajadores compartidos y, una vez registrados, persisten fuera de la vida útil de una página web determinada.

Los trabajadores de servicio pueden responder a eventos de message , como trabajadores compartidos, pero también tienen acceso a eventos adicionales. El manejo de eventos de fetch permite a los trabajadores del servicio interceptar cualquier tráfico de red (que se origine en una página controlada) y realizar acciones específicas, incluida la entrega de respuestas desde una memoria caché de Request / Response . También hay planes para exponer un evento de push a los trabajadores de servicios, lo que permite que las aplicaciones web reciban mensajes de inserción en "fondo".

La otra gran diferencia se relaciona con la persistencia. Una vez que un trabajador de servicios se registra para un determinado origen y ámbito, permanece registrado indefinidamente. (Un trabajador de servicio se actualizará automáticamente si cambia la secuencia de comandos subyacente, y puede eliminarse manualmente o mediante programación, pero esa es la excepción). Porque un trabajador de servicio es persistente y tiene una vida independiente de las páginas activas en un navegador web , abre la puerta a cosas como usarlos para potenciar los mensajes de inserción antes mencionados: se puede "despertar" a un trabajador del servicio y procesar un evento de push siempre que el navegador se esté ejecutando, independientemente de las páginas que estén activas. Es probable que las funciones futuras de la plataforma web también aprovechen esta persistencia.

Hay otras diferencias técnicas, pero desde una perspectiva de alto nivel, esas son las que se destacan.

Un contexto SharedWorker es una sesión con estado y está diseñado para multiplexar páginas web en una sola aplicación mediante mensajería asincrónica (paradigma cliente/servidor). Su ciclo de vida se basa en el dominio , en lugar de en una sola página como DedicatedWorker (paradigma de dos niveles).

Un contexto de ServiceWorker está diseñado para no tener estado . En realidad, no es una sesión persistente en absoluto: es la inversión de control (IoC) o el paradigma del servicio de persistencia basado en eventos. Sirve para eventos, no para sesiones.

Un propósito es servir eventos asincrónicos seguros simultáneos para consultas de larga ejecución (LRQ) a bases de datos y otros servicios de persistencia (es decir, nubes). Exactamente lo que hace un grupo de subprocesos en otros idiomas.

Por ejemplo, si su aplicación web ejecuta muchas LRQ seguras simultáneas en varios servicios en la nube para completarse, ServiceWorkers es lo que desea. Puede ejecutar docenas de LRQ seguros al instante, sin bloquear la experiencia del usuario. SharedWorkers y DedicatedWorkers no son fácilmente capaces de manejar muchos LRQ seguros simultáneos. Además, algunos navegadores no son compatibles con SharedWorkers .

Tal vez deberían haber llamado a ServiceWorkers en su lugar: CloudWorkers para mayor claridad, pero no todos los servicios son nubes.

Con suerte, esta explicación lo llevará a pensar en cómo se diseñaron los distintos tipos de Worker para trabajar juntos. Cada uno tiene su propia especialización, pero el objetivo común es reducir la latencia del DOM y mejorar la experiencia del usuario en las aplicaciones basadas en web.

Agregue algunos WebSockets para transmisión y WebGL para gráficos y puede crear algunas aplicaciones web increíbles que funcionan como juegos de consola multijugador .

2020 11 Actualización

Detalle importante para cualquier persona interesada en esta discusión: SharedWorker NO es compatible con WebKit (se eliminó intencionalmente ~v6 o algo así).

El equipo de WebKit sugiere explícitamente usar ServiceWorker siempre que SharedWorker parezca relevante.

Para una comunidad que desee recuperar esta funcionalidad en WebKit, consulte este problema (no resuelto hasta el momento).