Webワーカーができないサービスワーカーには何ができますか?またはその逆?
Webワーカーは、サービスワーカーの機能のサブセットのようです。これは正しいです?
それらが意図されているものには大きな違いがあります:
Web Workers
Web Workerは、Webコンテンツがスクリプトをバックグラウンドスレッドで実行するための簡単な手段を提供します。ワーカースレッドは、ユーザーインターフェイスを妨げることなくタスクを実行できます。さらに、XMLHttpRequestを使用してI/Oを実行できます(ただし、responseXMLおよびチャネルの属性は常にnullです)。作成されたワーカーは、そのコードで指定されたイベントハンドラーにメッセージを投稿することで、そのコードを作成したJavaScriptコードにメッセージを送信できます(その逆も可能です)。
サービスワーカー
基本的に、サービスワーカーは、Webアプリケーションと、ブラウザとネットワーク(利用可能な場合)の間に位置するプロキシサーバーとして機能します。 (特に)効果的なオフラインエクスペリエンスの作成、ネットワーク要求のインターセプト、およびネットワークが利用可能かどうかに基づいて適切なアクションを実行し、サーバーに更新されたアセットが存在することを可能にすることを目的としています。また、プッシュ通知およびバックグラウンド同期APIへのアクセスも許可します。
そのため、Web Workersは、ユーザーインターフェイスをフリーズさせずに高価なスクリプトを実行するのに便利です。一方、Service Workerは、ネットワーク要求からの応答を変更するのに役立ちます(たとえば、オフラインアプリの構築時)。
Buksyの答え は正しいですが、私の意見では、元の質問には答えていません。つまり、」できない?またはその逆?」
ライフサイクルと、Originごとのインスタンス数には根本的な違いがあります。要するに:
| Web Workers | Service Workers |
|--------------|--------------|------------------|
| Instances | Many per tab | One for all tabs |
| Lifespan | Same as tab | Independent |
| Intended use | Parallelism | Offline support |
Buksyの答えは、基本的にテーブルの最後の行です。クレジット:この表は slide 35 から始めて、Nolan Lawsonによる Demystifying Web Workers and Service Workers から取りました。
特に、Webワーカーを生成および終了する方法は次のとおりです。
一方、サービスワーカーには独自のライフサイクルがあり、これは明らかに「最も複雑な部分」です。
したがって、ライフサイクルは、2つの基本的な違いの1つです(意図した使用の結果)。
以前はブラウザサポートに大きな違いがありました:サービスワーカーは、11.3(2018年3月29日)までiOSのSafariで利用できませんでした。 サービスワーカーを使用できますか? すでに2012年に、はるかに優れたブラウザーサポート: Webワーカーを使用できますか?
ブラウザ間でのAPIサポートには微妙な違いがあります。 HTML5ワーカーテスト (同じくNolan Lawsonによる)を参照してください。特定のブラウザーでは、1種類のワーカーが特定のAPI呼び出しをサポートしているのに対し、他のワーカーはサポートしていません。そのページにアクセスして、独自のブラウザをテストしてください!