Live data from Hacker News

Writing a Service Worker

hacklabo.com

21–30 of 60 posts

Re: Writing a Service Worker

#25
post #22

I always get all stoked on service workers until I remember that half my users are on safari. Then I get bummed.

What's the difference with Safari? (not a JS dev, so this is not familiar territory)

Not implemented. "Under consideration".

https://webkit.org/status/#specification-service-workers

Re: Writing a Service Worker

#27

I always get all stoked on service workers until I remember that half my users are on safari. Then I get bummed.

I wouldn't let that stop you: adding a service work won't in any way degrade the experience of Safari users. When used for caching, it's pure progressive enhancement.

Sure, some browsers will have a more robust experience in adverse network conditions, but the experience once a page has loaded will be identical. It's also difficult to accidentally make the worker a hard dependency of a site, since even supported browsers will load the site without the worker on first visit.

Re: Writing a Service Worker

#29
post #10

How large can the cache get at max?

It's browser specific. Most use a heuristic along the lines of allowing browser storage (inclusive of IndexedDB, etc.) to use a combined 50% of the device's otherwise free space. Usually each origin is limited to around 20% of that potential usage.

Re: Writing a Service Worker

#30
post #11
post #3

Best use case of this I guess, is some kind of flight mode for web apps. Before going in to metro or flight, you click a button, and for example HN caches front page for you.

Caching cross-origin resources is problematic because you can't check the response code: https://stackoverflow.com/q/35626269

You can still cache the response you just don't get to see what the response was. For those types of resources it's best to only fallback to using them if the user is offline.
Post reply on HN