離線優先：下一個漸進加強技術

你的客戶須要原生手機應用而非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?
翻譯 子非門