有时，网络技术的此消彼长令人着迷。 服务工作线程 已经到来，除了离线网络（阅读 Jeremy 的书），这可能是它们最好的功能，它们还可以通过 推送 API 支持 推送通知。
我完全理解实现这一点的**推动**（双关语）。有一种普遍的情绪，即**我们希望 Web 获胜**，正如这个行业应该存在的那样。在 Web 上失败意味着输给所有不同平台上的原生应用。原生应用并非邪恶或任何东西——它们仅仅是以 Web 不具备的方式具有竞争力和排他性。使 Web 成为任何类型“应用”的可行平台对我们和人类来说都是胜利。
原生应用擅长的一件事是推送通知，这使它们具有竞争优势。一些开发者选择原生应用来完成此类任务。但是，现在我们实际上已经在 Web 上拥有了它们，社区甚至浏览器本身都对此表示抵制。Firefox 支持它们，然后 推出了一个用户设置来完全阻止它们。
我们看到了像 Moses Kim 的文章，例如 别@我
推送通知是好的用户体验意图因我们没有界限而变坏的经典例子。
很少有人赞扬推送通知。然而！Jeremy Keith 写了一篇关于 Sebastiaan Andeweg 的精彩实验文章。与其说是令人讨厌且干扰的推送通知……
以下是 Sebastiaan 想调查的：如果最后一步没有那么具有侵入性会怎样？以下是他想测试的替代流程
- 网站提示用户是否允许发送推送通知。
- 用户授予权限。
- 幕后发生了一系列复杂的事情。
- 下次网站发布相关内容时，它会触发一个推送消息，其中包含新 URL 的详细信息。
- 用户的服务工作线程接收推送消息（即使站点未打开）。
- 服务工作线程获取推送消息中提供的 URL 的内容并缓存页面。静默地。
它奏效了。
想象一个可以离线工作并静默接收和缓存新播客的 PWA 播客应用。太棒了。现在我们需要一个允许静默通知的权限模型。
更新：以下是 Sebastiaan Andeweg 的后续文章 无需通知的 PushAPI，他在其中深入探讨了所有这些背后的思考、代码和演示。
我发现第一步具有侵入性。还有什么比通知更无用地分散注意力的？关于允许通知的通知。
我同意，这有点自以为是。在播客 Web 应用示例中，寻求对静默更新的非提示性选择加入将是完美的。