這就是web app跟原生app的差別 （太經典了，說到骨子了去）
有一個詞叫"手機網站"（mobile web），指供手機瀏覽的網站，但它是不存在的。人們提到"移動網際網路"的時候，其實專指另外一樣東西：手機App。
一、Web App VS. Native App
比起手機App，網站有一些明顯的優點:
-
跨平臺：所有系統都能執行
-
免安裝：開啟瀏覽器，就能使用
-
快速部署：升級只需在伺服器更新程式碼
-
超連結：可以與其他網站互連，可以被搜尋引擎檢索
但是，現實是怎樣呢？
（1）體驗差。手機App的操作流暢性，遠超網站。
（2）業界不支援。所有公司的移動端開發重點，幾乎都是原生app。
（3）使用者不在乎。大多數使用者都選擇使用手機app，而不是網站。
如果將來有一天，Web app會成為主流，一定有一個前提，那就是它的效能可以趕上Native app。
二、為什麼Web app有效能瓶頸？
Web app輸給Native app的地方，不是介面（UI），而是操作效能。主要是互動（interaction）和動畫（animation）這兩方面，會出現卡頓（jank），使用者會感覺到明顯的時滯，有時簡直慢得難以忍受。
Web app的效能瓶頸，主要有以下原因。
（1）Web基於DOM，而DOM很慢。瀏覽器開啟網頁時，需要解析文件，在記憶體中生成DOM結構，如果遇到複雜的文件，這個過程是很慢的。可以想象一下，如果網頁上有上萬個、甚至幾十萬個形狀（不管是圖片或CSS），生成DOM需要多久？更不要提與其中某一個形狀互動了。
（2）DOM拖慢JavaScript。所有的DOM操作都是同步的，會堵塞瀏覽器。JavaScript操作DOM時，必須等前一個操作結束，才能執行後一個操作。只要一個操作有卡頓，整個網頁就會短暫失去響應。瀏覽器重繪網頁的頻率是60FPS（即16毫秒/幀），JavaScript做不到在16毫秒內完成DOM操作，因此產生了跳幀。使用者體驗上的不流暢、不連貫就源於此。
（3）網頁是單執行緒的。現在的瀏覽器對於每個網頁，只用一個執行緒處理。所有工作都在這一個執行緒上完成，包括佈局、渲染、JavaScript執行、影象解碼等等，怎麼可能不慢？
（4）網頁沒有硬體加速。網頁都是由CPU處理的，沒用GPU進行圖形加速。
上面這些原因，對於PC還不至於造成嚴重的效能問題，但是手機的硬體資源相對有限，使用者互動又相對頻繁，結果跟Native app一比，就完全落在了下風。
三、FlipBoard的解決方案
FlipBoard原本是一個手機App，最近開始部署Web版本，結果就遇到了上面的問題：Web版的體驗不佳。
上週，他們將解決方案公佈在網站上，結果引起了業界轟動，因為這是一個史無前例的解決方案：
---- 他們沒有使用DOM，而是將整個網站用canvas輸出！
你可以用手機開啟flipboard.com，體驗一下，看看跟Native app有沒有差別。如果你沒有帳號，可以直接開啟這裡或這裡。
這個方案的出發點是這樣的：如果將網頁變成了一個個canvas，使用者就等於在跟圖片互動，這樣就繞開了DOM，降低了操作時滯。而且，canvas可以被硬體加速，這樣就提高了效能。具體的技術細節，可以參考原文。canvas的轉化基於React框架實現，FlipBoard 開發了一個專門的庫React-canvas，已經開源。
這個方案引發了很多爭議（這裡和這裡），主要是canvas只是一個位圖，本身沒有語義，如果要在它上面實現UI，等於HTML語言已有的東西都要再發明一遍，比如如何實現超連結、如何實現CSS效果等等。一些最簡單的東西都變得很麻煩，因為canvas不是自適應的（responsive），文字在哪裡斷行，都要自己計算，而且使用者也無法選中文字。另外，怎麼讓搜尋引擎檢索網頁，解決起來也不是很容易。
但是不管怎樣，這是一個有意義的嘗試。
四、未來的路
James Long對FlipBoard的嘗試，寫了一篇評論《Radical Statements about the Mobile Web》。本文就受到了那篇文章的啟發。
在文中，James Long對未來的Web app提出了幾點預測，我認為很值得分享。
（1）多執行緒瀏覽器。每個網頁應該由多個執行緒進行處理，主執行緒只負責佈局和渲染，而且應該在16毫秒內完成，JavaScript由worker執行緒執行，這樣就不會發生堵塞了。Mozilla正在開發的Servo就是這樣一個專案。
（2）DOM的非同步操作。JavaScript對DOM的操作不再是同步的，而是觸發後，交給Event Loop機制進行監聽。
（3）非DOM方案。瀏覽器不再將網頁處理成DOM結構，而是變為其他結構。React的Virtual DOM方案就是這一類的嘗試，還有更激進的方案，比如用資料庫取代DOM。