Live data from Hacker News

Writing a Service Worker

hacklabo.com

41–50 of 60 posts

Re: Writing a Service Worker

#41

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.

Isn't that button for acknowledging the fact that the site will use cookies?

Yeah, but the color of that dialog should probably be changed. On a quick glance it blends in.

Re: Writing a Service Worker

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

Re: Writing a Service Worker

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

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.

Re: Writing a Service Worker

#44

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

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 out of things you can do with your serviceworker's cached content pretty quickly. If you're developing a serviceworker, the improved experience will be most felt by mobile users.

Re: Writing a Service Worker

#45
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…

The Guardian has an experimental iOS app that polyfills the Service Worker API. The way you'd use it is, roughly, change the INITIAL_URL variable to your home page, change the name / icon / etc. of the app, then release it on the App Store as an actual app.

https://github.com/gdnmobilelab/hybrid

If you have an actual iOS app already, then this is of course worse, but if you have something that works nicely as a webpage on Android with ServiceWorkers and you want iOS users to have some option at all, this is probably worth playing with.

Re: Writing a Service Worker

#46
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…

[deleted]

Re: Writing a Service Worker

#47
post #38
post #13

Earlier quoted context omitted.

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.

Exactly. I've written something like that but instead of messaging it was an issue tracker meets wiki. Completely offline with SW and IndexedDB with background sync when there was a connection. Works very well on the airplane :)

How did you make it sync in the background, by which I mean when the app is not in the foreground? That's the scary stuff of service workers.

Re: Writing a Service Worker

#48
post #38

Earlier quoted context omitted.

Exactly. I've written something like that but instead of messaging it was an issue tracker meets wiki. Completely offline with SW and IndexedDB with background sync when there was a connection. Works very well on the airplane :)

How did you make it sync in the background, by which I mean when the app is not in the foreground? That's the scary stuff of service workers.

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/updates/2015/12/background...

Re: Writing a Service Worker

#50
post #48

Earlier quoted context omitted.

How did you make it sync in the background, by which I mean when the app is not in the foreground? That's the scary stuff of service workers.

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?
Post reply on HN