离线优先：下一个渐进增强技术

你的客户需要原生手机应用而非webapp有三条基本缘由：

1. 原生应用速度比较快。如果你要创造下一个愤怒的小鸟，这当然很重要。然而，罕有应用需要达到游戏级别的响应度。也就是说，多一点关注度，利用HTML5技术创建一个快速反应的游戏是有可能的。但这能否在一系列的设备中良好运行就是另外一个事情了。

2. 客户部不知道哪个更好：“这应用如此酷！我们的对头就有了——我们也需要一个”。其实这需要一点说服力就可以解决这个问题的。

3. 手机应用能够离线运行。但是webapp也可以——就是这技术比较前沿而且我们很少用到的缘故

采用应用缓存来做一个web应用，离线应用已经实现好几个年头了。过程是这样定义的：静态文件应该被缓存以便于在网络连接丢失的情况下浏览器能运行应用。描述简洁明了，但是：

• web开发者在想到网络连接失败的情况是很害怕的。我在火车上写这篇文章就仿佛感觉到魂不守舍。即使连接速度在提高，但对于生活在偏远地区与发展中国家数以百万计的人们来说这仍旧是一个问题。

• 为已经存在的应用增加离线功能是不容易的。你需要重构ajax调用与网络请求，然后考虑网络连接状态的变化。但是，我们为什么不能够刚开始就考虑好呢。

移动优先（mobile-first）被认为是不错的开发技术。你从一个简单的可能是你的网站在不管年代或者设备上的所有浏览器运行的线性视图开始。更多的现代浏览器运用媒体查询（media queries）来应用样式扩展，在比较典型的桌面大屏幕设备上表现样式。换而言之，更优秀的浏览器采用大屏幕展示的布局就是渐进增强的。

离线应用的技术能否更易用些？应用应该推测到它的离线模式适时响应。当连接恢复，应用能够渐进增强地检索到增加的数据或者保存到云服务器。

离线优先（offline-first）成为被一些开发者探讨的概念，虽然还没有广泛应用。这里有些能够利用的主要概念。

1. 可信赖的远程机器

开发应用的逻辑重点要从服务端转向客户端。服务端本质上要变为轻量级的数据存储角色——重要的是——客户端应用应该运行在任何的网络连接状态下。

2. 创建客户端数据代理

你不能依赖ajax调用。一个数据代理要管理所有路由，例如：

1. 如果连接可用，一个ajax调用请求到服务端（假设有必要）
2. 如果连接不可用——或者ajax调用失败——localStorage、IndexDB 或其他合适的客户端存储机制被采纳。 记住，HTML5服务线程（HTML5 Service Workers）通过命名的javascript文件发送数据请求。虽然现在没什么浏览器支持该特性，也没实现标准，这种技术正在为这个目标进行设计。

3. 尽可能快地同步

当连接正常的时候你需要一个处理客户端到服务端的同步机制。采用web worker(线程)后台处理与在空闲期批量上传下载会更加有效率。

4. 考虑设备存储因素

移动设备比较复杂。比如：

1. 切换到另一个应用的行为可能会关闭浏览器。理想情况下，你的web 应用应该总要保存应用状态以便于用户返回到他们上次离开的地方

2. 当你的应用没有运行在被打开的浏览器标签里（最小化或者后台运行），Page Visibility API可以被用来减少处理过程与带宽

3. 理想情况下，你的应用应该运用Battery Status API。当电池电量低于正常水平的时候，它可以把数据存储在localStorage,即使连接可用的情况下。

5. 测试，再测试

如果你的应用需要在无连接或者有连接的情况下可操作，测试是比较困难的，下面是一些情况：

1. 应用被安装在不支持localstorage或者不支持其他必要技术的设备上
2. 网络连接丢失与重连发生在随机的时间间隔内（不稳定）
3. 在与服务端第一次通信之前网络丢失应用却被缓存
4. 应用同时运行在两个或更多的设备上
   在一系列的设备上进行严格的测试看起来只是可选项。

并非所有应用都适合采取离线优先的原则；一个多角色动作游戏运用离线优先的原则是没有意义的。但是，这种技术是否采纳应该被许多web应用在开发伊始首先考虑的。我喜欢这样，虽然我担心在已经存在的系统中开发这种技术所需要的成本。

原文 Offline First: Your Next Progressive Enhancement Technique?
翻译 子非门