主な違いは、AppCacheが高レベルの宣言型APIであり、ブラウザーにキャッシュさせるリソースのセットを指定することです。一方、Service Workerは、低レベルの必須のイベント駆動型APIであり、フェッチイベントをインターセプトし、他の処理（プッシュ通知の表示など）とともにその応答をキャッシュできるスクリプトを記述します。
長所と短所は主にAPI設計の機能です。理論的には、AppCacheの方が使いやすく、ユースケースは限られています。一方、Service Workerは使いにくいですが、柔軟性があります。
それにもかかわらず、AppCacheは設計が不十分なため、実際には使いにくいと考えられています（設計上の問題のリストについては、 アプリケーションキャッシュはDouchebagです を参照してください）。また、非推奨になっているため、ブラウザから削除されています（ アプリケーションキャッシュの使用 ごと）。
したがって、AppCacheを好む唯一の理由は、Kenneth Ormandyが ServiceWorkerを待たない：1行でオフラインサポートを追加する で推奨しているように、ServiceWorkerをまだサポートしていないブラウザーでアプリをオフラインにすることです。
Service Workerを使用できますか？ と オフラインWebアプリケーションを使用できますか？ を比較して、ブラウザーサポートの違いを確認してください。ただし、ChromeやFirefoxなどのServiceWorkerをサポートするブラウザでは、AppCacheのサポートが削除されるため、いずれかの標準をサポートするすべてのブラウザでアプリをオフラインにするには、両方を実装する必要があります。
Myk Melez が言ったことに加えて、アプリケーションキャッシュに対するService Workerの主な利点の1つは、ユーザーがネットワークから切断されている場合にのみアプリケーションキャッシュが機能するため、次の状況を管理できないことです。
1-「遅いネットワーク」-接続信号は強力ですが、一部の外部エンティティ（サーバー、ルートなど）が特定のアプリケーションへの送信を遅らせています。
2-「Lie-fi」（電話の番組はWi-Fiまたは低信号のセルネットワークに接続されている）なので、実際には接続されていないときに接続されているように見えます。
Service Workerはミドルウェアのようなもので、ブラウザが行うリクエストを制御できます。接続されているかどうかに関係なく、実際にリクエストをインターセプトして、必要な場所で応答できます。したがって、「オフラインファースト」の原則を実装できます。