Service Workerには、共有ワーカーで利用できる機能以外の追加機能があり、登録すると、特定のWebページの存続期間外でも存続します。
サービスワーカーは、共有ワーカーと同様にmessageイベントに応答できますが、追加のイベントにアクセスすることもできます。 fetchイベントを処理することにより、Service Workerは（制御されたページから発生する）ネットワークトラフィックを傍受し、Request/Responseキャッシュからの応答の提供など、特定のアクションを実行できます。 PushイベントをService Workerに公開する 計画 もあり、Webアプリが「バックグラウンド」でプッシュメッセージを受信できるようにします。
他の主な違いは持続性に関連しています。 Service Workerが特定のオリジンとスコープに登録されると、無期限に登録されたままになります。 （基盤となるスクリプトが変更されると、Service Workerは自動的に更新され、手動またはプログラムで削除できますが、それは例外です。）Service Workerは永続的であり、Webブラウザーでアクティブなページとは無関係に寿命があるためです。 、前述のプッシュメッセージングを強化するためにそれらを使用するなどの扉を開きます。どのページがアクティブであるかに関係なく、ブラウザーが実行されている限り、Service Workerは「起こされ」、Pushイベントを処理できます。 。将来のWebプラットフォーム機能もこの永続性を利用する可能性があります。
他にも技術的な違いがありますが、上位レベルの観点から見ると、それらは際立っています。
SharedWorkerコンテキストはステートフルセッションであり、非同期メッセージング（クライアント/サーバー）を介してWebページを単一のアプリに多重化するように設計されていますパラダイム）。そのライフサイクルは単一ページベースではなくドメインベースですDedicatedWorker（2層パラダイム）。
ServiceWorkerコンテキストはstatelessになるように設計されています。それは実際には永続的なセッションではありません-制御の反転（IoC）またはイベントベースの永続的なサービスパラダイムです。セッションではなくイベントを提供します。
1つの目的は、データベースとその他の永続サービス（つまり、クラウド）に対して長時間実行クエリ（LRQ）の同時セキュア非同期イベントを提供することです。スレッドプールが他の言語で何をしているのか。
たとえば、Webアプリがさまざまなクラウドサービスに対して多数の同時セキュアLRQを実行して、それ自体を設定する場合、ServiceWorkersが必要です。ユーザーエクスペリエンスを妨げることなく、数十の安全なLRQを即座に実行できます。 SharedWorkersおよびDedicatedWorkersは、多数の同時セキュアLRQを簡単に処理できません。また、一部のブラウザはSharedWorkersをサポートしていません。
おそらく、代わりにServiceWorkersを呼び出す必要がありました：CloudWorkers明確にするためすべてのサービスはクラウドです。
うまくいけば、この説明で、さまざまなタイプのワーカーがどのように連携して機能するように設計されているかについて考えるようになるはずです。それぞれに独自の専門分野がありますが、共通の目標は、DOMベースのレイテンシを削減し、Webベースのアプリケーションのユーザーエクスペリエンスを向上させることです。
ストリーミングの場合はWebSocketsを、グラフィックスの場合はWebGLをスローしてビルドできます。 マルチプレイヤーコンソールゲーム のように機能する一部のホットな喫煙Webアプリ。