我曾在《讓Web App和Native App的無聊之爭消停會兒吧，看看那些明智的Web技術解決方案》中講到過第一個選擇純粹Web App路線的主流新聞媒體——Financial Times（金融時報）。FT產品主管曾說過，開發Web面臨幾個主要挑戰：1. 目前Web App領域的開發文檔、測試工具都很稀缺，需要自己開發測試工具來測試性能；2. 不同的瀏覽器性能差別很大，使得圖片和視頻呈現效果不一且可能出現一些Bug；3. 許多用戶都是首次接觸Web App，需要為用戶做好使用指南；4. 做好離線功能（支持預覽、離線訪問、內容的收藏、下載等）。
最近，在Orlando FL上，Andrew Betts分享了他們在Financial Times上離線功能的一些設計原則：
1. 依靠多種形式的存儲在客戶端上的各類數據：Cookies、 localStorage、IndexedDB、AppCache和Files API，并且每個本地存儲解決方案之間是相互獨立的。盡量精簡Appcache中保存的內容，例如最基本的Javascript、CSS和HTML，只要它能夠支持Web App啟動就足夠了，后面的工作就交給AJAX和 eval來完成，把它們保存在localStorage中。
2. 從訂閱列表中下載最新的文章（使用JSON格式），當整個內容下載成功后，清空數據庫中已有的內容，然后調用將最新下載的文章存入數據庫。最后使用jQuery并調用一個模板將文章的標題顯示在訂閱列表中。
3. 每當更新文章列表時，其中的每個條目都會被重新下載，所以可以將部分內容存于瀏覽器緩存中，這樣可以快速填充AppCache。同時可以利用JavaScript API監控AppCache的可用空間并精細的指定哪些內容是需要被重新下載的。
4. 將App的主要功能模塊與Web頁面完全分離，例如那些翻頁、前進和后退的功能。這樣，應用啟動時只需要在這些模塊的基礎上加載內容的緩存就行了。而那些需要頻繁使用的緩存一定要保存在localStorage中。
5. Mozilla建議將 AppCache的格式更改為JSON并通過網絡控制其加載，而Google正在開發一個全新的API，能夠在JavaScript 中創建一個導航控制器，此控制器設定不同緩存加載的優先級，你也可以在其中自定義緩存加載規則。
6. IE和FireFox以不同的方式管理 AppCache，在設計時需要考慮這些差異。
7．不同瀏覽器之間對緩存的大小有很大的不同，一定要確保文章表單有足夠的空間供App保存離線閱讀的文章。
8．JavaScript使用UTF-16編碼，其每個字符占兩個字節，而如果用ASCII碼（每個字符占一個字節）轉化，將能夠節省一倍的空間。
相關閱讀：
讓Web App和Native App的無聊之爭消停會兒吧，看看那些明智的Web技術解決方案
“Web App和Native App誰才是未來？”這類的討論幾乎成了移動互聯網的月經話題。這兩天，又有朋友跟我說到“Native App必死”的論調，我并不贊同他的觀點，理由很簡單：雖然我們都知道Native App有許多缺點——客戶端的開發工作量大；軟件升級和維護比較麻煩；每次版本更新都需要向官方市場提交審核；開發者需要針對不同的操作系統和不同分辨率的終端進行適配開發工作；服務器端要支持多客戶端，難于擴展。但目前為止，其性能和用戶體驗都很難被Web App取代。同時，Web App還有其他的一些弱點——服務器端的開發工作量大，邏輯復雜；需要在更多設備上進行測試；前端技術還未標準化；難使用設備的特性（傳感器、GPS定位、本地文件系統等）。所以，我認為這兩種解決方案各有千秋，并不存在“誰將戰勝誰”的問題。
雖然討論“誰才是未來”的話題毫無意義，但我比較關心另一個話題：在當前狀況下，針對不同的公司規模，面向不同的應用領域，該如何做技術選型？我們看到，HTML5技術雖然已經火熱許久，但真正利用HTML5技術構建的成功的App相較于Native App而言可謂微乎其微，所以我認為看看那些利用HTML5技術成功的案例是幫助我們思考這個問題最簡單的方法。
我想說的第一個案例是Financial Times（金融時報）的FT Web App，它是第一個選擇純粹Web App路線的主流新聞媒體。我一直認為，就目前而言，最適合嘗試Web App的應用領域就是在線媒體，因為其特性與Web App的優勢十分貼合：用戶動作簡單（無非是閱讀、收藏、評論這幾樣核心功能）、注重內容呈現、無需做太多的視覺效果、面臨最多的跨平臺問題、與服務器關系密切、需要快速的操作體驗、輕量且易于更新。還有非常重要的一點，媒體的核心價值在于其內容，而在當今為內容付費的成功案例都稀缺的情況下，用戶是絕對不會為這類App的下載付費，而開發一個Native App需要花費較高的成本，我認為對于許多為變現發愁小型媒體而言，這種做法是不太明智的。
FT產品主管在談到他們的Web App時，除了對其以上特性的溢美之詞外，也分享了他們面臨的幾個主要挑戰：1. 目前Web App領域的開發文檔、測試工具都很稀缺，需要自己開發測試工具來測試性能；2. 不同的瀏覽器性能差別很大，使得圖片和視頻呈現效果不一且可能出現一些Bug；3. 許多用戶都是首次接觸Web App，需要為用戶做好使用指南；4. 做好離線功能（支持預覽、離線訪問、內容的收藏、下載等），他們在官方博客Tutorial: How to make an offline HTML5 web app, FT style中分享了詳盡的解決方案。
第二個案例是LinkedIn的iPad App，與FT不同的是，LinkedIn并不是一個完全的Web App。而是一個95%的工作由HTML5技術解決，剩下5%的工作（據說只有界面）是依靠Native App完成的，它實際上可以被成為是一個Hybrid App。
LinkedIn之所以選擇在iPad上利用HTML5技術開發應用是因為相較于其他的移動設備，iPad擁有更強大的處理器性能，能夠讓HTML5技術發揮良好的特性，保證整個App的體驗和響應速度。其負責人在接受VentureBeat的采訪時分享了一些他們的經驗：專注于簡潔的設計，通過移除一些不必要的設計來提高響應速度，例如去處圓角和漸變效果等。同時，他們大量使用Node.js來提高服務器的負載能力。
如今，像LinkedIn這種利用Hybrid架構解決方案的團隊越來越多，即將需要使用本地資源、數據和需要高表現力的部分交給Native來完成，其余部分由Web來負責。 這么做一方面能將Web App的許多特性表現的淋漓盡致，另一方面也能保證應用有不錯的響應速度和本地特性。
上面兩個例子中的FT和LinkedIn都是在線的、內容屬性和實時屬性非常強且對效果要求不高的產品。這也是我認為如今最適合嘗試Web App技術的產品類型，而像游戲這種對動畫效果和處理性能要求很高的產品，還沒有在HTML5技術運用上十分成功的案例（已經有一些游戲公司在嘗試Hybrid方案）。所以我想說的是，請拋開對Web App和Native App非黑即白的爭論，這個世界上，從來沒有最好的技術或是編程語言，只有最恰當的選擇和與之匹配的解決方案。