Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a Service Worker

hacklabo.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Writing a Service Worker

#51

Post by elithrar »

csharpminor wrote: post #35
akulbe wrote: post #22

Earlier quoted context omitted.

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

It's not just a safari problem, last I checked Chrome on iOS also does not support service workers, so you're just helping Android users. Apple has a vested interest in pushing users towards their walled garden for apps, while Google and Mozilla are trying to bring app-like experiences to the browser. There are hints of Safari supporting serviceworkers but I'm not holding my breath. Highly recommend Alex Russel's tal…

> last I checked Chrome on iOS also does not support service workers, so you're just helping Android users.

All browsers on iOS are wrappers around WKWebView (Safari, for the most part). You can’t release a browser app for iOS that doesn’t use this.

Re: Writing a Service Worker

#52

Post by rictic »

resca79 wrote: post #42

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_...

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.

Re: Writing a Service Worker

#53

Post by azernik »

csharpminor wrote: post #44
BHSPitMonkey wrote: post #40

Earlier quoted context omitted.

> you're just helping Android users And desktop users of Chrome, Firefox, and soon Edge (which has support implemented behind a flag).

While true, the most compelling use-case for serviceworkers is still on mobile. Serviceworkers solve the problem of intermittent connectivity. They can patch the gap when a user drops a connection for less than a few minutes (e.g. when a user is mobile). Laptops and desktops still benefit, but less so because generally if you sit down to use one of those devices in an area of poor connectivity, you're going to run ou…

That depends on the application. Some applications will run out of stuff to do after a few minutes offline, but others (especially where individual tasks are pretty independent, like Google Docs) can still be very useful for long periods, and can benefit from increased control of caching strategies.

Re: Writing a Service Worker

#54

Post by vaviloff »

icebraining wrote: post #33
Eun wrote: post #24

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

I don't get it, how is one supposed to use that, if the domains point to your IP addresses?

It's evidently for local work, /etc/hosts file is included in the repo.

Re: Writing a Service Worker

#55

Post by delta1 »

resca79 wrote: post #42

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_...

From the top of your link: "Using the application caching feature described here is at this point highly discouraged; it’s in the process of being removed from the Web platform. Use Service Workers instead."

Also: https://alistapart.com/article/application-cache-is-a-douche...

Re: Writing a Service Worker

#57

Post by gramstrong »

BHSPitMonkey wrote: post #40
csharpminor wrote: post #35

Earlier quoted context omitted.

It's not just a safari problem, last I checked Chrome on iOS also does not support service workers, so you're just helping Android users. Apple has a vested interest in pushing users towards their walled garden for apps, while Google and Mozilla are trying to bring app-like experiences to the browser. There are hints of Safari supporting serviceworkers but I'm not holding my breath. Highly recommend Alex Russel's tal…

> you're just helping Android users And desktop users of Chrome, Firefox, and soon Edge (which has support implemented behind a flag).

Unfortunately for Edge/Windows, in order to make the app installable it will have to be registered in the Windows Store. A small nuisance, and maybe a compromise that Safari/OSX could move towards, but still a pointless exercise that misses the point of PWAs.

Re: Writing a Service Worker

#58

Post by gramstrong »

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?

It is also useful for low-bandwidth or intermittent-bandwidth situations (i.e. poor network coverage).

Re: Writing a Service Worker

#59

Post by TheCoelacanth »

millstone wrote: post #50
hdhzy wrote: post #48

Earlier quoted context omitted.

Not scary at all. Check out this article on Background Sync [0]. It's not supported everywhere yet but the fallback to sync when the page is open is good enough. Of course you can also do sync on push events (they have broader support) but then you have to show a notification. Service workers have access to Indexeddb but not to local storage. That's something to remember. [0]: https://developers.google.com/web/update…

That link describes a web page that keeps running and sending data even after your browser is closed. Why shouldn't I be scared by that? Isn't that the holy grail for anyone who wants to track and surveil users?

It seems like there are some restrictions on them, but they are kind of vague about exactly how restrictive they are.

> Sync events will often complete while the user has a page open to the site, so requiring user permission would be a poor experience. Instead, we’re limiting when syncs can be registered and triggered to prevent abuse. E.g.:

> You can only register for a sync event when the user has a window open to the site.

> The event execution time is capped, so you can’t use them to ping a server every x seconds, mine bitcoins or whatever.

Re: Writing a Service Worker

#60

Post by MuffinFlavored »

callahad wrote: post #27
thrownblown wrote: post #20

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 brow…

I might be dumb but can't you kind of polyfill this behavior by making your SPA cache itself on load and response to everything as events, like shown in the repo linked in this article?
Post reply on HN