Productivity News & Topics
As someone who's used services workers to give a large app offline capabilities, I think the only use case that makes sense is when you know you will need offline-first capabilities. Everything else can be handled via tried and true browser cache with cache-busting when a resource updates, and should be handled via this mechanism.
Debugging SWs is pretty difficult. Updating the service worker is really bizarre especially if you have other tabs open (which is common in development), you have to worry about quotas, potential infinite cache situations, cleaning the caches yourself, you have to deploy the SW from a root URL (Ex: myhomepage.com/sw), sometimes you don't notice your local server is off for some time, because the app is still loading as expected, just with stale data (this can hinder the whole development team bit by bit, and they all need to be educated on how SWs work), etc. Just a huge amount of complication you take on. If Offline capabilities are not considered an essential feature, avoid if possible! The value prop is not there!
(Another issue you may face, though it could have been specific to me: Because the network console for chrome puts an icon next to all requests made through a service worker, anytime there is a serverside error, resulting in a failed request, the first place people will blame is the service worker implementation. So be ready if you're the one that adds this to become a kind of scapegoat for all serverside issues that may crop up)
Your email address will not be published. Required fields are marked *
Save my name, email, and website in this browser for the next time I comment.