[zbuttram]

I almost used this recently to gain more control over the HTTP cache behavior in our app at work, but eventually realized what I wanted could be achieved by combining plain old cache headers with some more intelligent cache busting query strings. I would definitely like to see some more real-life examples where this API provides unique benefits over traditional cache handling.

[jeroenhd]

This API is pretty useful for writing web apps that also work offline/with bad connectivity. It saves you from re-implementing the browser fetching/resource loading logic the browser already does for you.

It's very powerful, which also makes it a footgun: you can end up with fetch() requests going out over the network, with server responses saying one thing, but the frontend receiving something completely differently.

As for examples, I believe Home Assistant uses it to cache pretty much every resource in the frontend pre-emptively so you can use the web UI even if your internet connection is down (but your connection to your home server isn't).

[arm32]

We use service workers extensively in the kiosk app world.

[runarberg]

This API is used heavily in service workers to store responses for offline use. I don‘t think you can use HTTP cache headers to robustly achieve the same effect.

I created an SRS based kanji learning app (https://shodoku.app/ https://github.com/runarberg/shodoku) hosted on GitHub Pages (meaning the app is a static HTML page) where all the dictionary data is stored as hundreds of thousands of json (and SVG) files. Storing these assets using the Cache API saves tens of thousands of round trips to the server in addition to offering a somewhat robust offline experience.

[moribvndvs]

This is a lovely app BTW