Facebook 所犯的最大錯誤，就是將賭注押在了 HTML 5、而不是原生應用上。

在上月的 Techcrunch Disrupt 上，Facebook CEO Mark Zukerberg 針對其移動 App 的這番發言引發了一場針對 Web App 的聲討。HTML 5 驅動的 Web App 從在此之前的明日之星，似乎變成了所有相關移動應用體驗不佳的最大癥結所在。從用戶評價上，Facebook 新的原生 iOS App 從過去的 1.5 星評價迅速提升到了 4 星；從使用數據上，在新的應用推出后，用戶的使用率上升了一倍之多。對于 Facebook 這樣一個用戶量龐大的應用來說，能夠獲得如此的提升實屬難得，特別是考慮到新的應用在視覺上與舊的應用幾乎沒有什么區別。用戶的一致反應是，新的應用在速度和使用體驗上有了大幅度的改進。

那么，我們是否可以得到結論說：在移動設備上，HTML 5 應用很糟糕，原生應用是王道呢？也許我們應該先看看 Facebook 手機應用的發展歷程是怎么樣的。

Joe Hewitt，這位 Web 開發工程師都相當熟知的 Firefox、Firebug 開發者，同樣也是 Facebook iPhone 應用的最初開發人員。他開發的 Facebook 第一版原生 App 在當時獲得了廣泛的好評，從其中衍生出來的 Three20 也是 iPhone 早期時，開發者熟知的一個開發框架。但在 Joe 2009 年因為蘋果應用商店的審核問題退出這個項目后，后續的開發人員沒有能夠很好的在其基礎上進行進一步的改進。之后 Facebook 表示，出于跨平臺開發的考慮，他們開始轉向 HTML 5 的版本開發，但據 Facebook 內部開發人員表示，Facebook 服務器端團隊與移動團隊之間在如何傳輸數據方面一直相持不下，移動團隊原本計劃的混合開發模式是希望服務器端能為其提供 JSON 數據，以能夠實現本地內容緩存、以及快速的內容渲染，但服務器團隊卻告知他們說只能提供 HTML 數據。最后結果是，后來的 Facebook App 僅僅只是其移動版網頁的簡單封裝而沒有什么優化，其性能嚴重落后于同時間的其他原生應用，也落后于其他 Web 應用。

對于 Facebook 來說，其手機應用之前難用的主要原因并不在于 HTML 5，而更多的在于其執行中的問題，這也是目前很多 Web 封裝型應用的共同問題。由于目前各大手機平臺上 WebView 本身的性能限制和特性缺失，使得這些簡單網頁封裝型應用不僅無法趕上原生應用的水平，甚至還比不上自己的移動版網頁（出于安全性的考慮，蘋果對于 Safari 以外的 Web App 采用的 UIWebView 進行了限制，使其 在 JS 腳本執行速度等方面無法發揮真正的性能，而 Android 的 WebView 性能則更是不盡如人意。）

但這并不意味著 HTML 5 在移動開發中徹底失去了意義，Facebook 雖然比較激進的轉向了原生開發，但事實上，新的 Facebook App 同樣也采用了混合的做法，在應用的大多數地方采用了原生代碼來實現優化的性能，但在會頻繁變動的地方采用了 HTML 5 代碼來實現快速的功能更新分發，而相對應的原生代碼更新則會累積到下一次應用升級時進行更新（所謂的“fallback" renderer）。

如果說新的 Facebook App 對于 HTML 5 的使用僅僅是實驗性質的話，那么我們從 LinkedIn、Quora 等業界一致好評的優秀應用中，可以看到 HTML 5 與原生應用結合使用的優秀案例：LinkedIn iPad 應用 95% 都采用了 Web 代碼，在性能敏感的地方使用 Node.js 來進行優化；Quora 的交互功能部分采用了原生代碼，但在內容呈現上則采用了 HTML 5 來實現。

對于應用開發者來說，不應僅僅因為 Facebook 的這一政策轉向就激進的改變自己應用的開發方向。也許單純的 Web App 打包型應用的確還無法滿足用戶的標準，但 HTML 5 即使在目前的情況下也可以在原生應用中發揮重要的作用（甚至像 LinkedIn 那樣，實現非常優秀的體驗），當然其未來會如何進展還有待繼續的關注。在這方面，Mozilla Firefox OS、Google Chrome 等是 HTML 5 未來在移動端如何進化的值得關注的參與者。

此外，也不要忽略了 Mark Zuckerberg 講話的另一部分：Facebook 的移動版網頁的使用量依然比 iOS、Android 應用加起來還要多。移動網頁將依然是 Facebook 重要的戰略陣地，我們希望 Facebook 能夠在其 HTML 5 移動端進一步進行優化和改進，而不是僅僅抱怨其多么的不好用。