top | item 14729315

Writing a Service Worker

227 points| kayfloriven | 8 years ago |hacklabo.com

55 comments

order
[+] thrownblown|8 years ago|reply
I always get all stoked on service workers until I remember that half my users are on safari. Then I get bummed.
[+] callahad|8 years ago|reply
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.

[+] tuxracer|8 years ago|reply
> I always get all stoked about creating an iOS app until I remember that half my users are on android. Then I get bummed.

But seriously it is a bummer Safari doesn't support service workers yet. It's possible higher adoption would put more pressure on Apple to add support. In the meantime it can be a great enhancement where it is supported.

[+] akulbe|8 years ago|reply
What's the difference with Safari? (not a JS dev, so this is not familiar territory)
[+] antoaravinth|8 years ago|reply
Service workers are really cool. I love them in using it in react project. In fact, create-react-app does inject a service worker for you to cache all the static files in production environment.
[+] CamelCaseName|8 years ago|reply
What does the "Got it!" button do? Just let the author know that I understood the guide?

I really like that button. I don't know, it just drives home the point that you care that I understood your guide -- which was clear and easy to read.

[+] fiveseven_|8 years ago|reply
Isn't that button for acknowledging the fact that the site will use cookies?
[+] resca79|8 years ago|reply
Why don't use HTML5 application cache with the manifest? At first look it do the same that you need:

* Cache css, js and images file

* Defined cached entries page ex index.html, show.html etc..

* Fallback Entries

and it is really simple to use. https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_...

[+] dlbucci|8 years ago|reply
For one, it's deprecated. I've also found (at least during development) that it seems to cache too aggressively. Plus it lets you do weird things, like cache your appcache file. Combine that with caching the HTML, and you won't even be able to update your site until you clear the browser cache. I do appreciate the surface simplicity, but the complexity under the surface makes it painful to use.
[+] rictic|8 years ago|reply
I had a project that was pretty much a perfect fit for the app cache:

    - 100% static
    - reasonable dataset size
    - amenable url space (a few static files, then a large url
      space that could fall back to serving out the index.html 
      file)
Despite this, the appcache just never worked reliably. It was a crapshoot whether it would actually work offline for any given user, I had to be careful not to permanently cache the appcache itself, and it was just generally inflexible and unpleasant.
[+] nannal|8 years ago|reply
I imagine this comes with massive overheads in regards to data and ram usage, both of which are precious commodities on mobile platforms.
[+] onli|8 years ago|reply
At least when following this example the site should work just fine when JS is disabled, which was the main issue I had when I tried following google's (?) tutorial on how to use service workers to make webapps work offline. That one revamped the whole site into a JS app powered by service workers, with a blank white page remaining without JS. Not the case here.

I don't think this approach here should cost much performance. It is just a thread checking a cache (that will be on disk) on page load.

[+] franciscop|8 years ago|reply
Ah this is really nice but still feels quite verbose (+the web standards are know for their bad documentation for end devs). A small library with good documentation making things easier could kill it, similarly to localstorage, cookies, etc.
[+] davideast|8 years ago|reply
I highly recommend using Workbox: https://workboxjs.org/.

One of the more gnarly parts of ServiceWorker is having to clean up old caches during a version change. The workbox-build module generates revision hashes for your pre-cached assets and handles any cache clean ups for you.

[+] bluesign|8 years ago|reply
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.
[+] untog|8 years ago|reply
More than that - service workers have background sync and stuff like that as well. Imagine a messaging app where you can read and write messages no matter what the connectivity state is, then have the phone sync when you come back online.
[+] danellis|8 years ago|reply
I was going to say, "Isn't this what the application cache is for?" then I looked and saw it has been removed from the standards.
[+] hdhzy|8 years ago|reply
AppCache looks like a poor hack if you want offline site that is more complex than just a static blog post. There are numerous edge cases that you can easily handle in SW's JavaScript vs AppCache's limited declarative language. For example navigation requests can be special cased. Or you can decide yourself when to make a network request vs cache lookup. AppCache used some weird rules (e.g requests with query parameters never use cache).
[+] shinzui|8 years ago|reply
The author must not have been to Tokyo because I've never had bad connectivity underground there.
[+] XCSme|8 years ago|reply
How large can the cache get at max?
[+] untog|8 years ago|reply
From my understanding, the cache, IndexedDB and other storage are all bundled together. But I think the actual max changes according to device.
[+] callahad|8 years ago|reply
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.
[+] stephengillie|8 years ago|reply
Could this be used to optionally reduce bandwidth use? For instance, could someone use this before going into Airplane Mode, even though they are in the middle of a city, but do not want to use wireless data?
[+] untog|8 years ago|reply
Yep - that's one of the great things about service workers, IMO. The caching is pretty guaranteed, unlike the standard mobile caching which empties out far more often than you expect.
[+] gramstrong|8 years ago|reply
It is also useful for low-bandwidth or intermittent-bandwidth situations (i.e. poor network coverage).
[+] detaro|8 years ago|reply
yes, a site could allow the user to preload data into the cache and prefer that later.
[+] withholding|8 years ago|reply
Why the little story at the beginning? Annoying and silly.
[+] Bakary|8 years ago|reply
I interpreted the title to be a story from a programmer creating software that would replace a human employee in the service industry.
[+] aequitas720|8 years ago|reply
I thought this was going to be about AI replacing workers in the service industry.
[+] Eun|8 years ago|reply
What borders me, is that you need an valid SSL cert for an service worker, however there is a develop/test cert here: https://github.com/Eun/test.bi
[+] icebraining|8 years ago|reply
I don't get it, how is one supposed to use that, if the domains point to your IP addresses?