web-applications - Firefox 和 Chrome 应用 list 的主要区别是什么

Question

FF 和 Chrome 都开始使用应用 list 和服务 worker 来支持渐进式网络应用。

那么在编写 list 时要记住的主要区别是什么(或者同一个 list 文件可以同时用于两者)。

如果它是一个托管的 web 应用程序(不是一个打包的)，在让用户安装它的过程中有什么区别？

Answer 1

这个问题有很多事情要做。我将尝试通过提供一些历史记录然后回答 OP 可能会提出的几个问题来解决所有问题。

背景

打包应用

Chrome、Firefox、Opera 和许多其他平台在不同时期都有“打包”的应用程序平台，这些平台运行 HTML/JS/CSS 内容但不在网络上。这些通常使用某种 list 文件结合类似 zip 的包装和目录结构(有时还有签名)来分发应用程序。这些应用程序通常没有参与同源策略或以与 Web 内容相同的约束和功能运行；通常，这些包是通过专有商店和功能和 API 提供的，这些功能和 API 还不能用于“纯旧的 Web 内容”。

这些应用程序的 list 格式——至少在 Chrome Packaged Apps 的情况下和 Firefox Packaged Apps -- 是内容和选项未标准化的 JSON 文件。

托管应用程序

一些系统将提供给其专有打包应用程序系统的额外功能与“真正的”基于 Web 的应用程序托管相融合，以创建“托管应用程序”。它们有多种风格，但 TL;DR 是它们也倾向于具有基于 JSON 的专有 list 文件。例如，参见 Chrome Hosted Apps 的文档, Firefox Hosted Apps , 和 Windows 10 Hosted Apps .

同样，这些系统是专有的、非标准的、不可互操作的，尽管有问题的内容来自“真实的网络”(不同于它们的打包应用程序表兄弟)。

渐进式 Web 应用程序

渐进式 Web 应用程序不同于打包应用程序和托管应用程序，因为它们只是“普通的旧 Web 内容”，也恰好指向基于标准跟踪的 list 文件 Web App Manifest format .

这种格式是 Chrome 检测并用于触发“Add-to-Homescreen”行为的格式，也是 Opera 当前在您手动向主屏幕添加内容时(以及将来 Opera 提示时)使用的格式。

Mozilla 有 signaled support对于这种格式，他们的工程师大量参与了标准的设计和演变。我很乐观，这将演变成对基于标准而非专有 list 的 UI 的支持。

Mozilla 也有望在 future 几个月内为 Service Workers 提供支持，这将为 Chrome、Opera 和 FF 之间的可互操作“安装”行为奠定基础。激动人心的时刻。