I like service workers, but I don't like the lack of control I have.
For example, I want Messenger to send me notifications if I have the tab open, but I don't want the service worker to maintain a persistent connection and send me notifications with the tab closed.
Unfortunately, I am not able to block service workers. My only option is to block notifications entirely, which doesn't even stop the service worker.
The service worker can't maintain a persistent connection. Without an active tab it is shut down after 30 seconds or so. It can receive events via the Push API, which is what you're seeing. But if you refuse notification permissions the site cannot use the Push API. I'm actually not sure how it works when you block notifications after having given permission - it's a requirement that you show a notification in response to a push, so if you're blocked, I'm not sure how the browser registers it.
More broadly, I agree that it is strange you can opt into the Push API without a permission prompt. I wish it weren't the case, but I do think it would be confusing to users to request separate push and notification permissions - most consider them to be synonymous, even if they aren't.
Actually, Firefox has UI for this. Click "Menu -> Web Developer -> Service Workers". This will open a special page "about:debugging#workers". It shows active service workers and allows you to unregister them. There is another even simpler UI at "about:serviceworkers".
Great write up. I’ve been exploring SWs recently to help with downloading and caching data in the background for faster UI.
Question, I’d like to avoid doing large downloads or possibly cap the transfer rate to avoid any potential jank. Is there a best practice or is it possible to monitor the current browser interaction to determine how strategically best to pull data with a SW?
Depending on what a user chooses to cache, it’s JSON data (1-10MB) going to a mix of localstorage and indexedDB.
Thanks for this! I've recently been asked how much data our React Native app uses. I totally hadn't thought of
using Axios' interceptors to track this. So obvious!
They are aware, it’s business software, syncing records/templates/frequent info etc. It’s only to improve the experience, and it’s controlled by settings/opt-in etc.
It’s also configurable to only operate on faster connections/non mobile IP address etc.
The main reason I was asking is if you currently benchmark service worker updates with indexedDB for async/larger updates, they still cause a small amount of jank, (at least on larger requests) even though they may use a different process etc.
There’s a github repo with a benchmark, this link is older but if you clone the current version and update to the lastest packages, the results are still similar.
You misunderstand. Service worker traffic is invisible, unlike loading an image and generally speaking can't be governed, unlike visible elements.
Loading 1-10MB JSON might drain a significant portion of mobile data. It could take a long time, meaning it may need to re-start it a couple of times, due to, say, a flaky 3G connection.
I'm curious on the why - unless this is an announced feature, I don't think this should be an automatic process and should only be done on user demand explicitly.
I agree with you, there are several settings avail to control what is optimized, it’s typically enabled on faster devices/connections at work. I would be upset as well if a site naively used up a connection in the background.
"Imagine being able to respond to push notifications, intercept resource requests, and schedule background syncronization, all without the need for a user to actively have your website open in front of them."
".. by authoring special-purpose JavaScript which you register with the browser."
Why does this seem like something useful for malware and generally annoying me.
Push requests only exists on Chrome and is behind a permission, intercepting resource requests within the domain of a website could cause some annoyances, can’t see the malware effect immediately. Scheduling a download for a stable connection, again, could be an annoyance, but what’s the malware implication?
The malware angle is basically service-worker-powered cache poisoning: if you can get the server to serve your code once, users can get a service worker installed, and intercept resource requests under that path. It’s limited in practical value because you have to be able to serve a full JS file as the service worker, rather than just injecting a snippet of JS as the most common technique is, but it is a genuine attack vector.
Service workers automatically reload after 24 hours, regardless of caching headers (though I believe they’ll respect a 304). I believe this was done partially to limit the duration of such a compromise.
I don't want to be compromised at all and it seems like a great way keep it that way is to force web pages to live in you know pages which I can close and know they aren't effecting my browser.
It also breaks my mental model of how the browser works in a way that will be incomprehensible to users.
Instead of my computer is acting funny I need to reboot we will have my browser is acting funny I need to restart it or we can combine the 2.
My browser is acting funny lets power cycle again. Coming soon to a windows PC near you.
Unless there’s a sandbox escape, the worst it could do is use some extra CPU cycles and RAM. It’s not good at doing stuff like bitcoin mining because it’s event driven (much more like a page than a web worker). All the browsers are also very aggressive at killing them unless a page is open or you get a push notification.
They bite. The generic idea may even be reasonable (offline working web app), but every single time I encounter service workers they make things worse.
If you load a React frontend, it'll, by default, deploy a service worker. Good luck trying to load anything non-react from that resource/server.
I never asked for a web app to work in the background once I closed a site. Nobody should be trained to expect websites work in the background - that is not how they are. If there is no tab open, there should be no notification, no nothing. That is how the web works.
My most delightful experience with a service worker was SVGOMG, https://jakearchibald.github.io/svgomg/. One time I was without an internet connection, and I thought to myself, “if only it had a service worker so it’d work offline!” and then I opened a tab to it, to remind myself to optimise the SVG I was working with later, and— huh. It loaded. On reflection, I decided that given who Jake Archibald is, it made sense that he’d be an early service worker adopter. So that day I was really pleased with the Just Works™ value of that service worker.
And SVGOMG is able to load faster thanks to service workers, too.
At FastMail, we’ll be getting round to adding service workers some time soon, and it’ll actually give us a quite fascinating performance boost: even without supporting full offlineness, simply caching the basic data you need can get you to the point where you need literally no requests before you can load the interface, showing meaningful data to the user, and then fetch updated data in the background. I’m confident we’ll be able to get startup time to under two seconds with service workers for code and data loading/caching, and hopeful that we’ll get it down to under a second.
Service workers can be badly implemented, but they also offer the possibility of some quite delightful improvements in websites and web apps.
I've recently set an offline mail client to sync mail locally for my wife's laptop. Her two gmail accounts downloaded 22GB.
Be careful what offline actually means when it comes to mail; eg. that 22GB as service worker cache sounds a bit nasty to me, especially because service workers don't tend to differentiate between desktop and mobile.
Definitely. I’d hate to have it download all my mail on my laptop or my phone. We have yet to particularly consider the UI for controlling it, but I fully expect that anything in the way of synchronisation rather than simple caching of what we’re already fetching (and only limited amounts of that—there’s already an LRU GC on the cache) will require manual configuration, probably with options like “sync the inbox” or “sync the last 30 days of mail”, and probably projections of probable storage requirements.
If you want a local backup of all your mail, using a web app like ours, even if it supports fetching it all, is not a good idea, unless it satisfies both of these criteria:
(a) it should support fully offline and session-agnostic functionality. We’re very unlikely to ever go this way on fastmail.com, because it’s just not going to be useful to almost anyone, and is more complex and easily leads to confusion. Instead, the data will be tied to your session, so that if you log out, or your session is permitted to expire, or you close your account, then the data will all promptly be deleted when you next go online.
(b) it has a way to export it again. Theoretically with JMAP we could actually do that, but even if we did implement it (and I doubt we ever will), it lacks the portability of other formats like mbox or PST.
Taking both of these points together, I say that an email service provider’s app’s sync should not be considered suitable for a backup. For convenient offline access, perhaps, but not for a backup.
Why would anyone that has that amount of mail go out of their way to get a phone with such limited capacity. At this point a phone with 16gb serves the purpose of being a burner phone.
There is no limit on gmail. For someone who has it for a decade or more, 20GB mail is realistic, since gmail always told you there is no need to delete anything, ever.
As for 16GB phones, those are pretty normal; take a look at moto e5. Please don't tell me a 64GB phone is required for email.
It also doesn't change the initial problem of what and how much should be cached by service workers.
> If you load a React frontend, it'll, by default, deploy a service worker.
I think you mean that create-react-app is doing this by default, and that it might be a surprise and cause of problems for the developer. Which is also the reason why they're removing that by default from create-react-app v2.
> That is how the web works.
That's not really an argument, in that it also could've been used as an argument against the introduction of inline images, CSS, or anything added to the web after its first publication. It doesn't really matter how the web works today; what's relevant is how we want the web to work.
good luck trying to convince google of that. they are shaping the web just the way they want it. push notifications? nobody ever except the marketing apartment thought that was a good idea to add to anything. if we try making everything on the web like mobile apps we're gonna get garbage features like this and false expectations on what the web should be like.
No actual user cares how their messaging application is made. If it's a progressive webapp or a native app, and the actual experience can be the same, then it really doesn't matter.
> AIM, ICQ, IRC, and Yahoo Messenger all used local clients.
A webapp with a service worker is a local client. And a lot of people use Whatsapp Web, or Facebook Messenger's web site. I know I do.
I think users do care. I care that I can't close my browser without missing messages. I dislike that Electron apps use half my RAM.
If by "don't care" you mean "don't care enough to abandon a platform their friends are on" then I guess I agree. But all you've proven is that network effects matter.
but people do want their messaging application to run in a browser now.
People don't want something until it happens and they see it and say hey that's what I want, unless you are going off the assumption that people are sheeple and can be made to want messaging applications in the browser because they have been told to want it somehow.
Really? Have they been given an alternative? Not an electron app, a real desktop alternative, that syncs with the mobile native client and gives an in-desktop experience.
Nobody did that, ever. It's simpler and cheaper to ship an in-browser solution, so everyone does that, that's all.
> every single time I encounter service workers they make things worse
I'd wager you encounter more service workers than you think, but you don't notice them when they work correctly. They are designed to be invisible in the majority of cases, so of course you only notice them when something goes wrong.
> If you load a React frontend, it'll, by default, deploy a service worker.
What?
> That is how the web works.
The web 'experience' has stopped being about fetching static documents in a request/response fashion long ago. Consumers demand rich apps and interactivity, and it appears they're having it their way.
Equating 'create-react-app' package with React is silly. By that logic, I can wrap $library_of_your_choice in scaffolding and then blame it for the bloat I've chosen to add.
> EDIT: see gov.uk. It works quite well without being fancy.
We're at an impasse, since you countered my 'assumption without data' with your 'one-off anecdotal evidence'
> Consumers demand rich apps and interactivity, and it appears they're having it their way.
no consumer ever demanded the web to be like an app. this is marketing baloney crap. stop treating humans browsing the web as targets for advertisement and consumerism.
You are conflating what you wish were true with reality.
For-profit companies typically build toward what they believe is in-demand and will be well-received by consumers. They perform market analysis to reinforce their intuition. Sometimes they get it right and their stock goes up.
There isn't some elaborate plot on the part of Google, nor are 'they' purposely making something 'no consumer ever demanded.' When they do this, the endeavor fails and we call it a flop.
> what they believe is in-demand and will be well-received by consumers
They never show an actually alternative version. A/B or bandit testing doesn't cover a comparison between, say, a nicely designed, very fast, non-tracking, but less interactive version, or a slow, but full-fledged "app".
There used to be mobile versions accessible from desktop (twitter, facebook, etc), but not any more without faking the user agent. Those are significantly lighter, than desktop versions, but there is no way to actually compare the two for the generic public, and companies don't seem to be brave enough to really dig into these questions.
Google and Facebook want us on their website but we aren't their customers. The people paying their bills want our web experience mildly but tolerably bloated and tracked. You have a good point but Google and Facebook are the last people to use for proof.
Maybe I'm out of touch, but for messaging apps wouldn't it be desirable to have an actual service from a native app that you can enable/disable in your OS?
Webster’s is a descriptive dictionary, which will include nonstandard words so that it can _describe_ them, and provide guidance on what should be used instead. Just like in that link - it suggests the use of “regardless”
For example, I want Messenger to send me notifications if I have the tab open, but I don't want the service worker to maintain a persistent connection and send me notifications with the tab closed.
Unfortunately, I am not able to block service workers. My only option is to block notifications entirely, which doesn't even stop the service worker.