為什麼扎克伯克說 Facebook 在 web 版本上押注過多，將來把更多的精力放在原生應用上？

12-24

Facebook的web版本基於HTML5技術，這項技術在當前有哪些優缺點，它的前景又是如何？

題目有點兒大，簡單講講。

優點是，
Facebook 作為一個 Web 起家的公司，已經擁有大量的 HTML（5）人才，做用 HTML5 渲染的應用可以有效利用現有人力資源和技術積累，項目起步輕快，進展迅速。

另外對於排版有複雜要求的應用，拿 HTML5 作為渲染引擎比自己寫一套原生的解決方案出來要方便、通用得多。

HTML5 還有一個很誘人的特性：跨平台支持。看上去很美，做一個 Web App 就能搞定所有平台，還不用學那麼多種編程語言。

缺點是，
真正做過跨平台的人都知道，一套代碼打天下其實是痴人說夢（做遊戲的同學日子要好過些）。
能夠一套代碼搞定所有平台的應用，通常都是在哪個平台上都不好用的應用。
就算是 Web App 也一樣，例如為不同解析度、DPI 的機器做優化這件事兒就不能省。

其次，目前的主流移動瀏覽器渲染 HTML5、執行 Javascript 還是不夠快。哪怕在支持 Nitro Javascript Engine 的 Mobile Safari 上，載入的 js framework 稍微重點兒也卡，更何況在不支持 Nitro 的 UIWebView 上呢。所以性能是純 HTML5 應用最大的軟肋，而性能差的應用其體驗是好不了的。

另外雖然 HTML5 框架支持了很多新特性，蘋果公開給 Web App 的 API 也越來越多，移動瀏覽器也越來越快，但原生 API 永遠要支持得更多、更好、更快。所以在近期內， HTML5 做的 Web App 要達到或者超過同時期原生 App 的效果，是很難，甚至是不可能的。

很多時候用 HTML5 出原型快，但是隨著需求的增加，想要實現的效果越來越高級，對性能要求越來越嚴格，完全用 HTML5 所花費的代價、對技術人員的要求反而要比用原生方案高很多，得不償失。

最後，
各種技術都有其局限性也有其優點，如果能夠把握好各技術的特點，把合適的技術用來解決合適的問題，做成 Hybrid 應用是較好的方案（fb 之前過於偏重 HTML5，我認為這不是我所描述的 hybrid 形式）。

我是做SocialGame的，困擾我們的最大問題就是我們要接入的平台，每個平台都有自己的一套介面，各自有各自的標準，每次新接一個平台，我們都要針對這個平台做特殊定製，花費大量的時間和精力。

有一天Google站了出來，說，我要解決這個問題，我提供一個統一標準，叫做OpenSocial，可以解決這個問題，實現跨平台，減少對平台的依賴。

我們很高興，以為找到了解決方案，於是開始研究它，緊接著憑藉Google的大肆推廣，國內的人人網，http://51.com等平台，全部支持了這種介面方案，但是很快我們發現，這不靠譜，為什麼呢？平台之所以採取自己獨特的介面，是為了提供平台獨有功能的支持。

以新鮮事（首頁的消息）為例，有的平台不支持新鮮事，有的僅支持文字，有的支持文字和圖片，有的支持文字圖片和自定義鏈接，有的支持多媒體。

為此，我們面臨的選擇就是，要麼最小適配，就是我們假定平台都不支持，那麼一勞永逸，我不再關心你到底有什麼亂七八糟的特性。但是這對運營是個大問題，我們無法充分利用平台特性。要麼我們就還是得針對各個平台進行不同實現，其結果是該做的工作我們一樣不落，甚至更多了，因為我們還要照顧到OpenSocial的特性。

於是乎，這種解決方案最終沒有經得起市場考驗，被人們丟到一邊。

回到Html5，和我說的這個現象類似，看似它有了一套嚴格的標準，但是它扛不住不同平台的本地實現的不同，它看起來可以幫我們偷懶，卻很難使我們的產品在一個平台將那個平台的特性發揮到極致。

更深入的，使用Html5可以脫離商店的束縛，你的商店規則對我無效了，這看似自由了，但你相當於同時放棄了對平台資源的利用，這樣的對比下，顯然放棄平台資源並不理智，除非你自己有很強大的渠道。

而且Html5是一個完善中的標準，它隨時產生變化，穩定性還不如平台，為了兼顧這套標準，我的成本非但沒有降低，還增加了。

那麼請告訴我，當你畫的大餅無法實現，我出了狼窩，又進了你這個虎穴，何必呢，我還不如回到我的狼窩，好好的伺候我的狼。

最近也負責了一個HTML5產品，這裡分析下HTML5在移動端能力（適合產品經理或開發人員閱讀）

一、HTML5的優勢
我想HTML5的優勢早已在行業內被傳的家喻戶曉，例如：

多平台
支持本地存儲
支持三維圖形特效，基於SVG、Canvas、WebGL及CSS3的3D功能
支持網頁多媒體播放，例如視頻，音樂都可以直接播放

在項目進展的過程中，驚喜的發現除了網路上流傳的這些能力外，html5還支持上傳圖片，圖片的壓縮甚至非同步拉取等在web端常見的功能。除此之外iOS6對web app支持smart banner和桌面web clip功能，使得web app對native app的下載拉動和模擬native效果的能力更強。

這些能力不是項目開始前就知道的，作為產品經理更多的是關注功能特性和交互流程，但很多時候功能能否實現更多的是依賴於HTML5這個平台能否滿足，這也是後面扎克伯克說的「it just wasn』t there」的意思。

二、HTML5的現狀
前景的確非常美好，但是目前來看HTML5的確存在不少問題：
1.兼容性非常繁瑣。多平台其實是個幌子，多平台意味著需要適配多種手機屏幕解析度，多種不同的系統，多種手機瀏覽器。老實說，android在這方面的貢獻不亞於電腦端ie瀏覽器。
2.載入渲染速度不夠快。儘管這取決於系統本身的性能，但還是比同樣機器的native慢不少，如果一些含有複雜邏輯的頁面就會出現閃屏的狀況。
3.容易誤點。原生應用拇指點擊區域一般比真正點擊區域要大，而且實際體驗上也比較自然舒服。但web來說目前只能通過css來控制觸碰區域，體驗上還是不太能令人滿意的。
4.圖片上傳。極度依賴系統支持能否壓縮，不支持就只能傳原圖，非wifi傳原圖的話，至少5S等待時間
5.本地存儲。ft中文網是使用這個特性最傳神的，但本地存儲還是依賴系統本身，充滿著不確定性和不穩定，如果是專門針對手機瀏覽器的應用或許可以利用起來。

三、HTML5的機會

HTML5和native的對比早期在網路上討論的還是很熱鬧的，例如：
HTML5比原生應用更具長期優勢__萬家熱線
HTML5和原生移動應用誰會贏？_cnBeta 軟體新聞_cnBeta.COM

但我一直認為，這種比較是毫無意義且沒有實踐經驗依據的，往往是一些所謂的技術大牛或者編輯嘩眾取寵的文章。
可以這麼說，HTML5一直沒有釋放其該有的能量，被詬病的「性能」問題是其沒能大範圍使用的根本原因。就像田忌賽馬一樣，你總不能用自己的弱項去跟別人的強項比吧？所以原生native跟HTML5結合使用是移動端最有力的武器，但遺憾的是國內外一直都沒有人能把他們正確的結合起來，
大家想到的無非是：

原生native app外殼裡麵包一層HTML5的頁面。這樣除了一些基本操作菜單外，其他內容還是HTML5，還得更新，讓人抓狂。。
HTML5直接模擬原生native app。同上，訪問速度和流量是瓶頸。

我一直在思考，到底是什麼產品形態才能充分發揮HTML5和native的優勢呢？什麼用戶會傾向與web？什麼場景下用web會更適合？什麼產品特性不需要更新客戶端也能快速更新？

這些問題延伸下去其實就是答案了。這裡用人物法來分析下思考的過程：
1.用戶：很在意移動流量，沒耐心等待慢的手機頁面，總是在移動中或碎片時間使用手機。
-所以跟用戶直接「接觸」的產品，最好是原生native的，可以保證穩定性和流暢度。
2.第三方開發者：非常需要平台方開放介面，根據這些介面盡量滿足自己的需要，或者是社區傳播自己的產品，或者是吸引更多用戶購買從而盈利等
3.平台：這裡的平台就是這款手機軟體的主開發商。對於經常需要更新，而用戶訪問又不頻繁的，可以使用HTML5來實現，對於第三方開發者想獲取到的能力進行更多自定義特性，HTML5是很適合的。

總結：
HTML5代表著移動web的未來，最適合它的未必是用它來做一個獨立的應用，而是找到最適合的點來使用。html5的增長速度會隨著網路環境和手機硬體的提升而更進一步。

引用Mark Zuckerberg的一句話：「One of the things that』s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.」

到目前為止任何跨平台都是騙人的，平台有它的獨特性，沒有這些平台的獨特性，那麼這個平台就沒有什魅力會被人遺棄。

第一問小札自己已經回答了，就是說用HTML5來滿足app應用需求， "it just wasn』t there"...直接的意思不是說HTML5不成熟，而是「滿足不了」。
第二問HTML5 在應用開發上有什麼優缺點？個人覺得不是優缺點的問題，而是要判斷什麼時候適合在應用開發上使用HTML5？HTML5不是原生應用開發語言5的縮寫，是HyperText Markup Language 5的縮寫。它本身不是為原生應用設計的，甚至也不是為了web 應用設計的（它還需要JS的幫助吧至少）。我們團隊開發過不少iOS和安卓產品，在蘋果商店就有10多個。我們的經驗是如果內容比較靠近報刊書籍，或者文章、網頁，那麼用HTML框架做主要內容展現比較好。但是如果交互功能很多，比如SNS，行情圖，我們用原生應用框架。不少應用都是比例不同的混搭。

擴大的跨平台都有點兒扯淡

在HTML5還不成熟的情況下，產品要有更好的體驗，更快地佔領市場，還是native的比較靠譜。
感覺HTML5跨平台，必然要妥協，放棄難以兼容的特性，就像流水線作業，native的更像是精雕細琢一些，目前HTML5開發的產品還是難以滿足用戶需求的。

兼容性越好的技術性能越差，兼容性越差的技術性能越強。
在安卓上使用html5做web app動畫不流暢，交互準則和原生app不一樣(尤其是安卓的back),很多高級功能也做不了

回顧PC的歷史，很有趣的是最早都是C/S結構，後來因為網路環境和機器本身的速度因素逐步走向B/S結構。
在Mobile世界也在順應這個潮流，有趣的是小札的反思其實是他走的太快了。當下的Mobile使用環境可能還是在初期必須是App當道。也就是PC時代早期的C/S結構。
長期看必定會走向B/S結構這個趨勢不會改變。只是小札超前了些許。這才有了小扎的這次演講。當然FB全面擁抱移動這是一個大事件。

一句話，HTML5這一WEB技術還不夠適應手機移動平台的一些特性，簡單一點，一套方案很難討好所有平台

都太片面了，真實情況往往考慮的是開發速度，而非質量。跨平台並不是說一行代碼不改，而是更大程度的代碼復用。而那些提性能不佳的更極端，我很好奇，你的應用得有多牛逼，能讓html5明顯卡頓。其實說了這麼多，我覺得大家的問題就是把na與html對立起來，但他們其實是互補的

跨平台都是騙人的

隨著時間的推移，大家會發現越來越多的應用可以通過H5的方式來實現，包括一些複雜的遊戲也可以。上面回答排斥H5的同學，大部分都是原生應用的從業者，而且都是好幾年前，但是2016年以後，大家會發現在手機端H5的表現越來越好。
就好像Flash經歷過，PC端動畫-&>富媒體廣告-&>全站Flash-&>Flex開發遊戲，頁游等多個階段，早期Flash也什麼都做不了，但是後面做的事情越來越多，我個人覺得這個過程也會在H5上重演一次。

怎麼沒有人說說google PNacl和Nacl可以用來開發native的web應用啊, 這個東西未來大家怎麼看 ?

翻譯下，
扎克伯格意思是他很期待將來有著美好前景的HTML5，但不是當前這個尚不成熟的baby版本。所以要停止在web版本上押太多籌碼了。
他們的寶貝用戶更多的是用手機瀏覽器上Facebook而不是用安卓和水果的原生app。所以將來他們還要把重心移回HTML5上面來。但是，這些都是長遠的事情啦。
希望對你有幫助。

When I』m introspective about the last few years I think the bigest mistake that we made, as a company, is betting too much on HTML5 as opposed to native…because it just wasn』t there. And it』s not that HTML5 is bad. I』m actually, on long-term, really excited about it. One of the things that』s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.
——Mark Zuckerberg, Disrupt SF, September 2012

唯技術論是程序員們的愛好,一天到晚爭論哪個語言更好,哪個技術更牛,沒有意義嘛,這個說法明顯是斷章取義了

html5隻是還沒有成熟標準還沒有出來，標準出來了可以就不一樣了。