Cache is super useful for making web apps available offline.
I run a guitar chord chart site[0] that uses cache to enable offline experience; any chord charts you view while online are then available offline thanks to cache. It works pretty great. You service worker intercepts HTTP requests and can first check the cache for cached request/responses.
> Cache is super useful for making web apps available offline.
... until you find someone who has very low cache available. Or cache gets evicted.
wredcoll · 2h ago
Yeah, good point, it also doesn't help people when their cpu catches fire.
qwertox · 4h ago
Maybe they should have put the line
The browser does its best to manage disk space, but it may delete the Cache storage for an origin.
in a warning box.
NoahZuniga · 4h ago
You know, you could just improve this. All you need to go is find the github link for the article at the bottom of the page, find the edit button, and github will guide you through the rest of the process.
(I've done so myself a few times)
If you prefer you can also clone and make a pull request using standard git tools.
judah · 2h ago
...that's OK.
My app works fine online or offline. If you're offline and you ran out of disk space and the cache got evicted, ok, you can't use my web app offline.
(And, if you're out of disk space, all bets are off. You're gonna have other, more significant problems beyond a guitar chord chart site not working offline.)
arm32 · 5h ago
We don't talk about those people.
No comments yet
stonogo · 3h ago
Or their computer breaks. Or their electricity cuts off. Or an asteroid hits them.
...things can be super useful without being flawless.
zbuttram · 6h ago
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 · 5h ago
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 · 5h ago
We use service workers extensively in the kiosk app world.
runarberg · 6h ago
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 · 4h ago
This is a lovely app BTW
foxtacles · 5h ago
Used this API in a service worker together with Workbox to allow https://isle.pizza/ to work completely offline if requested. Works great
afavour · 6h ago
Absent a service worker this API won't give you a whole lot but it's a very powerful addition to the web toolkit. With the right caching strategies you can make a really effective offline web app.
sroussey · 5h ago
HuggingFace’s Transformers.js uses this API to cache model files for when you are running models in the browser.
h1fra · 5h ago
Oh nice, I didn't know about that. I wonder if popular libraries like react-query could use it and make a web app fully available offline (readonly) without changing a single line?
ameliaquining · 5h ago
Making a web app work fully offline requires a Service Worker, if for no other reason than because something has to handle the initial request for the top-level HTML document (and in practice it's much easier to let the Service Worker handle other things too). TanStack doesn't seem to have anything available out of the box that does this; the most commonly used library for this purpose is Google's Workbox, and it should be possible to integrate the two.
sangeeth96 · 7h ago
Did something change for this API recently or just randomly popped up on frontpage? (:
Pwntastic · 4h ago
this poster seems to just spam random stuff from mdn and his personal project over and over. you can see that he even added a spam comment to this post asking for stars on his github project.
edit: op deleted his beg comment after it was flagged dead
GZGavinZhao · 6h ago
Or maybe just to show appreciation for this API? At least I do :P
sangeeth96 · 6h ago
Hah, that's fine. Just checking in case I missed something :P
I haven't been using service workers lately but I had some run-ins recently when writing some CF workers.
xd1936 · 2h ago
I kind of like when things randomly show up on the frontpage that I _should_ know about. Today was my turn to be part of the lucky 10,000.
I encourage everybody to work with service workers to encounter the horror that can be service workers gone wrong.
Pro-tip: Use Serwist (https://serwist.pages.dev/), don't learn Workbox. Serwist has beautiful Vite integration for preloading app chunks from a build manifest. Learn all the different caching strategies. Consider dynamic caching strategies, eg. switching between two strategies for a specific cache via messaging throughout the lifetime of the app. Deep breaths. Have a service worker kill-switch in case things go wrong.
inetknght · 5h ago
I encourage everybody to not use service workers so my computer doesn't waste resources.
arm32 · 5h ago
Instructions unclear. Prefetching 8GB of media to a service worker cache on your browser. And you can't stop me! Muahahah
inetknght · 2h ago
about:config -> service -> change everything
then hate the modern internet >:(
divbzero · 6h ago
The Cache API is separate from the traditional HTTP cache. You can access the HTTP cache indirectly by fetching with appropriate HTTP headers, but I suppose there is still no way to access the HTTP cache directly?
I run a guitar chord chart site[0] that uses cache to enable offline experience; any chord charts you view while online are then available offline thanks to cache. It works pretty great. You service worker intercepts HTTP requests and can first check the cache for cached request/responses.
[0]: https://messianicchords.com
... until you find someone who has very low cache available. Or cache gets evicted.
The browser does its best to manage disk space, but it may delete the Cache storage for an origin.
in a warning box.
(I've done so myself a few times)
If you prefer you can also clone and make a pull request using standard git tools.
My app works fine online or offline. If you're offline and you ran out of disk space and the cache got evicted, ok, you can't use my web app offline.
(And, if you're out of disk space, all bets are off. You're gonna have other, more significant problems beyond a guitar chord chart site not working offline.)
No comments yet
...things can be super useful without being flawless.
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).
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.
edit: op deleted his beg comment after it was flagged dead
I haven't been using service workers lately but I had some run-ins recently when writing some CF workers.
https://xkcd.com/1053
Pro-tip: Use Serwist (https://serwist.pages.dev/), don't learn Workbox. Serwist has beautiful Vite integration for preloading app chunks from a build manifest. Learn all the different caching strategies. Consider dynamic caching strategies, eg. switching between two strategies for a specific cache via messaging throughout the lifetime of the app. Deep breaths. Have a service worker kill-switch in case things go wrong.
then hate the modern internet >:(