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

你的客户须要原生手机应用而非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?
翻译 子非门