原文：What Progressive Web Apps Mean for the Web Opinion by TJ VanToll

作为一个开发者，我持一定的怀疑态度去了解新平台特性。你不必深究这个博客的文章来发现我对 Apple Watch，web 组件和其他众多新潮的技术的抱怨。

最近这些新潮的技术似乎是 progressive web 应用，巨大的网络社区 —— 特别是 Google —— 在过去的几个月里一直大力推动着。我很认同 Alex Russell 的文章里他对 progressive web 应用的详细解释，但是简单的说， progressive web 应用就是使用了大量 Web 最新特性的 Web 应用，例如 manifest，service worker以及其他的让 Web 应用感觉更像原生应用。

最近的 Chrome 浏览器开发峰会，大量地谈论 progressive web 应用，最终说服了我去深入研究。本文中，我将用构建一个应用的亲身经验来给出我对 progressive web 应用的看法。我会讨论什么是我喜欢的，什么是我不喜欢的以及我认为 progressive web 应用对未来的 web 意味着什么。让我们快速的讨论下构建一个 progressive web 应用你需要做什么。

构建一个 progressive web 应用

从一个较高的水平来说，一个 web 应用想 “progressive”，必须要做三件事：

• 注册一个 service worker —— Google 倡导的一系列接口，允许离线访问、web 推送通知等等。
• 运行在 HTTPS 上，这是 service workers 规范强加的硬性要求用来防止有人从中攻击。
• 创建一个应用程序清单文件（manifest file），指定一堆关于你的应用的信息，例如它的名字。

我的博客https://www.tjvantoll.com没有做这三件事，我想升级它会是一个亲身尝试这个过程的绝佳机会。我不会去涉猎详细步骤，但我会给出一些对我有很大帮助的指南：

• Nicolás Bevacqua 关于 service workers 的文章富有表现力地帮助你设置一个基于内容的网站的离线访问。
• Jeremy Keith 关于 service workers 类似的文章， 以及他较好的源代码作为我大部分的实践依据。
• 当我调整我的 service worker 代码时，Jake Archibald’s offline cookbook 是很好的参考点。

本着开放的精神，这是manifest.json 和 service-worker.js文件，我用来将我的博客变成一个 progressive web 应用。可以随意参考他们以及复制粘贴你想要的。

现在我的博客有了这些文件后有两个十分棒的特点：

• 1）离线支持。你可以在没有网络连接时阅读我博客上任何之前浏览过的文章。如果你在断网时尝试阅读新文章，我会显示一个断网的页面，而不是完全失败。
• 2）应用安装的 banner：随着应用清单（manifest）到位，目前 Android Chrome 浏览器和 Android Opera 浏览器会提示用户像应用安装一样将我的博客安装到他们的设备主屏幕上。下面的截屏显示了在 Android Chrome 浏览器上的流程。

注意：Chrome 和 Opera 已经改进了第一个截图中 banner 展现频率的算法。目前，Chrome 的算法是需要两次独立的访问该网站。你可以在你的设备上访问 chrome://flags 且允许忽略用户互动度检查 （Bypass user engagement checks）标志来强制显示 banner 。

尽管我的博客相对简单，但你可以看到这些 API 的潜力。试想如果 Facebook 或者 Twitter 的移动网页保存了你的浏览记录，那么你可以像浏览其他本地应用一样离线浏览它。或着，如果新闻刊物因为这些浏览器实现的安装 banner 而放弃他们对用户安装他们的本地应用的迫切呼吁。

这有很多潜力，但是现在这些 API 已经准备好让普通的公司尝试了吗？让我们开始讨论，看看浏览器的支持度。

其他浏览器如何？

对于一个浏览器支持 progressive web 应用，浏览器必须实现 service worker 和 web 应用 manifest 规范，目前基于 Chromium 的浏览器（例如：Chrome，Opera，Chrome android版等等）是唯一支持两者的浏览器。至于其他的浏览器：

• Firefox 在他的开发版本已经支持了 service worker，而 manifest 文件列为正在积极开发。
• Edge 列出 manifest files 和 service works 两者为 “正在考虑中”。
• Safari 列出 service worder 特性为 “没有积极开发”，并且没有列出 manifest 文件。

这种支持情况似乎相当消极，是的，在几年前他们就可以将这些特性按照他们的方式加到 IOS 上，特别需要注意，WebKit 团队最近公布的5年计划提到了这。

但是别急着关闭标签页，因为这可怜的支持情况并没有像你想的那么重要。事实上，我对 progressive web 应用感到兴奋的最大的一个原因是因为他们的设计遵守 web 的定义特点之一：优雅降级

优点：优雅降级

还记得我如何把这两个文件添加到我的博客使它成为一个 progressive 应用吗？ 将这些文件放在不支持 service worker 或 web 应用 manifest 的浏览器会发生什么？ 什么都没发生。这些文件仅仅被忽略了。

这是令人耳目一新的，因为这么多 web 的新特性都没有这种优雅的回退。是的，polyfill 是一个办法，但是许多 web 平台最新的 API 不是都能轻易被 polyfill 的 —— flexbox，指针事件以及 web 组件。

而简单的事实是，有很多 web 开发者不能认真地对待非友好平稳回退的 API 直到这些特性到达他们被支持的每个浏览器。因此如果一个浏览器，如目前最普通的浏览器 Safari，决定不实现某个 API，那浏览器实际上是拿该特性要挟众多 web 开发者。

让我们用 web 组件作为一个例子，如果你打算在2013年时全力以赴地使用 web 组件，你选择在许多浏览器使用表现不佳的 polyfill，并希望浏览器对大部分的支持情况会提升，然并卵 （尽管 polyfill 的性能是有的）。

但是 progressive web 应用不同。不像 web 组件， 今天，如果你的应用中不使用这些 API，唯一让人信服 理由是参与编写和维护必要代码的时间和精力。

缺点：入门门槛高

尽管 progressive web 应用有潜力对普通 web 应用增加很多有用的功能，有一点我认为会影响到用户的采纳，就是当前使用这些 API 的门槛相对较高，从 HTTPS 开始。

现在，我想大多数开发者都明白使用 HTTPS 的重要性了，包括隐私，比 HTTP/2 性能更好，甚至谷歌搜索都排名更靠前。但并不会改变大多数网站的实际情况 —— 包括众多数目中最突出的 —— 还没有到处切换使用 HTTPS。即使 Amazon.com 也没有将 HTTP 流量定向到 HTTPS。

像 Let’s Encrypt 倡议尝试提供免费证书来降低入门门槛。但现实是，在许多机构，尤其是大机构，普通的开发者理解 HTTPS 但并没有在服务器上安装证书的能力。相反，他们一定是经常做无用的挣扎来反对繁琐地完成工作。

对于 progressive web 应用，即使在你有 HTTPS 的条件下，底层的 service worker API 尽管他们可以做很多而引人注意，但开发者还是需要相当长的时间来学习和理解。像 Jake Archibald’s offline cookbook 这些资源都是好的开始，但是很多开发者根本不想去自己写这些样板代码。

经过一段时间的思考，我最终发现一些框架整合了这个离线功能并直接支持。想想看 Angular 路由就足够聪明来离线工作，WordPress 有个插件可以自动安装需要的 service worker 和 应用清单文件，或者[Kendo UI 电子表格组件能够同步离线变化到服务器上，即使用户关闭了标签页。

我认为这些事情即将发生，但现在，service worker API 的底层性质意味着如果你想构建一个 progressive web 应用，你必须要准备撸起你的袖子。我想这是进入 progressive web 应用的高门槛，因为我认为对一个 progressive web 应用一个最大的屏障是克服用户期望。

Progressive Web 应用的特点

作为开发者我们清楚网页及其我们手机设备的细微差别，但普通用户不会。当谈及 Progressive web 应用时，我有一大堆的用户体验问题：

• 用户会相信是原生实现的“添加到主屏”按钮吗？尤其是在一个网页中同样的功能充斥着很多自定义版本。
• 用户是否会因他们主屏的 web 应用不是真正的本地应用而感到困惑？确实，尽管 web 应用及其图标会出现在用户的主屏，但他们不会出现在应用商店或用户设备上所有程序安装列表中。

我想有一些用户体验的挑战可以克服，但只有足够多的网站真正使用了 progressive 应用接口才行。一个用户可能不会信任首次弹出的“添加到主屏”，但第四次时，我会期待用户意识到那个弹框是来自浏览器自己，并值得尝试。

因此 progressive web 应用会有很多技术的困扰，就像先有鸡还是先有蛋的难题。用户或许不会信任和使用这些应用直到大量的网站利用了 progressive web 应用 API。但是大的网站或许不想实现这些相同的 API 直到有大量用户真的想“安装”他们的 web 应用。

因为 progressive web 应用友好的平稳退化设计，所以我保持乐观。差不多每个 web 应用都会因增加 service worker 来允许某种形式的离线访问得到好处，即使它只是用来展示一个离线错误页。另外，随着用户购买移动应用的花费剧增，许多商家可以有机会做出选择使用 progressive web API 来增加他们的用户基数。

Chrome Android 版也提供了一个相当聪明的机制用来提示从 Google Play 下载原生 Android 应用，这对构建一个自定义 banner 来插入你的 Android 应用来说是一个吸引人的替代方案。

那么如果你现在从事一个 web 应用的工作，尤其是一个已经安装了 HTTPS 的应用，我会鼓励你花些时间把你的网站转化一个 progressive web 应用。构建一个 service worker，创建一个应用清单文件，参与未来的 web。