Writing a Service Worker • Hacker News Board

Re: Writing a Service Worker

#11

Post by krallja » Sun, Jul 09, 2017, 1:57 PM UTC

bluesign wrote: 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

Re: Writing a Service Worker

#12

Post by [deleted] » Sun, Jul 09, 2017, 2:00 PM UTC

Zyst wrote: post #9

>This is, unfortunately, a familiar scene for everyone, whether you are in Tokyo, Milan or New York. Damn it, if I'm going to have the song stuck in my head all day so should all of you! https://www.youtube.com/watch?v=P5mtclwloEQ

[deleted]

Re: Writing a Service Worker

#13

Post by untog » Sun, Jul 09, 2017, 2:23 PM UTC

bluesign wrote: 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.

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.

Re: Writing a Service Worker

#14

Post by franciscop » Sun, Jul 09, 2017, 2:24 PM UTC

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.

Re: Writing a Service Worker

#15

Post by untog » Sun, Jul 09, 2017, 2:25 PM UTC

XCSme wrote: post #10

How large can the cache get at max?

From my understanding, the cache, IndexedDB and other storage are all bundled together. But I think the actual max changes according to device.

Re: Writing a Service Worker

#16

Post by Bakary » Sun, Jul 09, 2017, 2:27 PM UTC

I interpreted the title to be a story from a programmer creating software that would replace a human employee in the service industry.

Re: Writing a Service Worker

#17

Post by davideast » Sun, Jul 09, 2017, 2:27 PM UTC

franciscop wrote: post #14

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.

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.

Re: Writing a Service Worker

#18

Post by untog » Sun, Jul 09, 2017, 2:33 PM UTC

stephengillie wrote: post #6

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?

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.

Re: Writing a Service Worker

#19

Post by antoaravinth » Sun, Jul 09, 2017, 3:24 PM UTC

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.

Re: Writing a Service Worker

#20

Post by thrownblown » Sun, Jul 09, 2017, 3:33 PM UTC

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