Re: [w3c/ServiceWorker] event.waitUntil vs return promise (#1148)

To be clear, I think separating `respondWith` is fine and allows different use cases. However, `waitUntil` still seems strictly unnecessary. I've updated the title accordingly.

> Since we don't await or return the result of waitAndMaybeReject(), we don't react to it in any way. Code like this is usually a mistake.

— https://jakearchibald.com/2017/await-vs-return-vs-return-await/

You basically need to amend this article with another hazard where `await waitAndMaybeReject()` is also not sufficient. 

> `waitUntil` is separate, as you may wish to do additional work in the service worker related to the fetch, but not handle the response.

This is the case without `waitUntil` too. 

The issue is that `waitUntil` is an unnecessary footgun. The original motivation of the browser needing to terminate the worker is completely orthogonal. The browser can do that without a `waitUntil`. It can also do that in the synchronous case (e.g. if a worker does `while(1)`) where there is no `waitUntil` today.

**To summarise**: Keep `.respondWith`. You also don't need to deprecate `.waitUntil`. Just correctly `.waitUntil` the response if a promise is returned. Also, if there are things left to execute, don't ignore them by default. If you need to terminate despite there being things left to execute, that should be handled separately. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1148#issuecomment-350107798