Apple has started to implement service workers in the latest Safari, but it still lacks behind the other browsers - I suspect they are worried it will provide a disincentive for applications to be hosted on the app store.
My biggest draw to PWAs was the ease of which I could deploy an intranet app on portable devices with spotty connectivity. This works fine with the appcache, which is what I currently use, but service workers require SSL and self-signed certificates are a no-go. This adds to the complexity of using service workers in a simple intranet hosted PWA. Also, back to Safari's poor implementation of service workers, the amount of time a PWA will reside in the browser is unspecified. I can only imagine the the headaches it will cause if the PWA drops randomly. So I'm avoiding service workers in my PWAs for now.
When appcache deprecates (it's slated to), maybe it will be time for me to go native if I am going to have to add complexity regardless.
I dont know if Apple has a marketing team to downvote this, but anytime I've been critical of Apple, someone is quick to downvote and defend their actions.
> Please don't impute astroturfing or shillage. That degrades discussion and is usually mistaken. If you're worried about it, email us and we'll look at the data.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
They are doing everything they can to put off Safari Push on iOS. That will seriously destabilize the App Store, by giving webapps the most important feature of native apps, Push.
Slightly related - not much a fan of hackernoon. The electric lime green banner at the top is essentially blinding. I had to zap the element with Ublock Origin just to read the article comfortably.
I think service workers are the biggest foot gun to web development. There are so many issues you bring to the table just to have offline capability.
First you have to design a service worker that can intelligently download new updates to your app, relay to the user there is a new version, and you have to make sure you support changing apis as clients can be using the old versions of an app for a long time.
You have to design self destruct logic because your service worker itself can have bugs and break your app. In addition your self destruct logic can break.
You also have to make sure you service worker does not infinitely cache an old version of you app, because it will never expire without correct logic. You cant just assume to download higher version numbers, some times you want to revert to an older version of your app.
There were previous proposals like appcache which tried to do the right thing and handle a lot of details like this for the developer, but it didn't fit every use-case well. So instead, browsers implemented something more raw that just focused on exposing all of the necessary capabilities. I think the hope is that web developers create reusable abstractions over service workers and most people just use libraries for dealing with them (and if any of the libraries end up on a really powerful abstraction, maybe that will get baked into browsers later).
I thought the worker is required to be re-downloaded every 24 hours (well, possibly as long as you have connectivity) specifically to avoid foot-gun risks? Or is that something that's they're still figuring out the details of?
Not only one of the most creative talks I've had the pleasure of attending, but also a good showcase of what happens when you fire this foot gun: https://www.youtube.com/watch?v=t7WraVE8rY8
I tried service workers and even just unlaunching the feature was a major challenge. Our users ended up having cached versions of the site with a service worker for every and we had to put a ton of cache busters in to deal with it.
Sorry but it is completely your own fault. We've been using Service Workers on production for two years now, and never had any issues of any sorts. Also kudos for "trying" a new API on production.
I'm a software engineer who works for Google who has worked on web tech for 25 years (hello NCSA and CERN). We went into this because a web dev on the team thought it would be a good solution, and put a bunch of work into it. After some time, we noticed that it added a ton of complexity and violated many of our core assumptions about how web pages work.
Note that service workers weren't really new when we used them, we deployed them carefully and with intent, with skilled developers.
Don't get me wrong- I like the idea behind service workers- I just found how they were implemented to be difficult.
A normal application will check if a file it needs is downloaded, and if not, download it.
An insane application would unconditionally attempt to download the file, except first it forks off a new child process, turns it into a network MITM proxy, and have it intercept the request. Because how else can you access local files on disk except through HTTP?
> immediately switched back to my browser to navigate to the website, to read the blog that I was peacefully reading on the native app
I had to read this twice because I couldn't believe there's actually someone out there who prefers those "install the app" banner spam apps that the mobile web is littered with.
36 comments
[ 2.2 ms ] story [ 89.5 ms ] threadMy biggest draw to PWAs was the ease of which I could deploy an intranet app on portable devices with spotty connectivity. This works fine with the appcache, which is what I currently use, but service workers require SSL and self-signed certificates are a no-go. This adds to the complexity of using service workers in a simple intranet hosted PWA. Also, back to Safari's poor implementation of service workers, the amount of time a PWA will reside in the browser is unspecified. I can only imagine the the headaches it will cause if the PWA drops randomly. So I'm avoiding service workers in my PWAs for now.
When appcache deprecates (it's slated to), maybe it will be time for me to go native if I am going to have to add complexity regardless.
Yes, as of iOS 11.3.[1][2]
[1] https://webkit.org/blog/8090/workers-at-your-service/ [2] https://caniuse.com/#feat=serviceworkers
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
https://news.ycombinator.com/newsguidelines.html
[1] https://webkit.org/blog/8090/workers-at-your-service/ [2] https://caniuse.com/#feat=serviceworkers
First you have to design a service worker that can intelligently download new updates to your app, relay to the user there is a new version, and you have to make sure you support changing apis as clients can be using the old versions of an app for a long time.
You have to design self destruct logic because your service worker itself can have bugs and break your app. In addition your self destruct logic can break.
You also have to make sure you service worker does not infinitely cache an old version of you app, because it will never expire without correct logic. You cant just assume to download higher version numbers, some times you want to revert to an older version of your app.
I would assume you would republish the older version as a new higher version. It's not uncommon in regular software releases.
Not ready for primetime.
When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Person 2: "It worked for my single use case / environment / circumstances = the best thing ever, it's your fault"
:)
Note that service workers weren't really new when we used them, we deployed them carefully and with intent, with skilled developers.
Don't get me wrong- I like the idea behind service workers- I just found how they were implemented to be difficult.
https://gist.github.com/ankita1910/1ff6c67a63c0f2d62a5c82c7d...
A normal application will check if a file it needs is downloaded, and if not, download it.
An insane application would unconditionally attempt to download the file, except first it forks off a new child process, turns it into a network MITM proxy, and have it intercept the request. Because how else can you access local files on disk except through HTTP?
I had to read this twice because I couldn't believe there's actually someone out there who prefers those "install the app" banner spam apps that the mobile web is littered with.