Web App和Native App不是生死之爭——反思HTML5慘痛的500天和四個謊言
上一篇《HTML5定稿了?背後還是那場鬧劇》講了HTML5所謂“定稿”背後的商業利益博弈,本文將繼續這一話題,反思兩年前那場“Web App和Native App”的大爭論,提出一些建設性的意見。
2013年是HTML5在中國最慘淡的一年,但是直到現在仍舊很少有人反思這種慘淡的根源。“體驗經濟”的盛行,讓“使用者體驗至上”成了網際網路公司鐵的紀律。各行各業也把使用者體驗掛在嘴邊上,可是偏偏在HMTL5從業者的思維中,使用者體驗被刻意忽略甚至成了“某種藉口”。
HTML5慘痛的500天
2012年HTML5全球範圍的熱度很快傳輸到了中國,行業掀起了一場大論戰“Web App和Native App在3年或5年內誰生誰死”。可是不曾想,就在當年HTML5話題在中國最熱的時候,歐美接連傳來壞訊息,眾多大牌的HTML5擁護者紛紛反水:如Facebook承認HTML5移動戰略的錯誤、蘋果App Store拒絕充當包殼的Web App發行渠道等等。
很快中國力挺Web App和HTML5的排頭兵們紛紛偃旗息鼓,為數不多的當時獲得VC青睞的HTML5創業公司也在2013年被迫轉型甚至解散。直到500天后的2014年,一隻再次挑動了HTML5“神經的貓”出現才打破這一悲觀的趨勢。
通常來說,“使用者”的需求會被放在特定“商業”邏輯裡,然後選擇具體“技術”來實現,既從User Business Tech。也就是說技術作為底層基礎、商業邏輯基於技術實現、使用者需求被商業邏輯包裝後的技術滿足。而在HTML5這個事情上,反而技術邏輯成了優先的部分,打著使用者需求的幌子滿足野心家們的商業需求。這些幌子和謊言總結下來包括以下4個方面:
謊言一:使用者使用一個native app的時候要去App Store搜尋,這一過程繁瑣不友好。
回答:使用者如果不願意去app store搜尋,難道還指望去手機瀏覽器裡面像pc一樣搜尋web app?手機瀏覽器很重要,但是已經沒辦法在ios和android的生態下和使用者桌面的入口抗衡。
謊言二:native app的更新頻繁,使用者對更新感到厭煩。
回答:app的更新流程已經被app store和眾多手機助手等充分的優化,使用者習慣已經養成。另外native app的更新代表著更好的使用者體驗和更多新的系統功能加入,不斷完善使用者體驗。而對於web app的“弱功能”和“弱體驗”屬性,很難憑藉所謂的無需手動更新的優勢獲得使用者青睞。
謊言三:下載和更新native app耗費流量,流量花費影響使用者使用
回答:流量的問題在今天網路環境下已經不再成為使用者優先考慮的痛點,wifi的普及甚至讓大型的遊戲和視訊app獲得生機。當下高品質的native app少則10幾兆起、多則幾百兆是普遍現象。另外,根據實際結果評估,web app的手機瀏覽器裡面的重複使用並不會真正的減少使用者使用流量。
謊言四:使用者不願意下載太多的native app
回答:使用者真的不願意下載太多的app?現在一個使用者手機內平均安裝多少個app?對於有重複使用需求的app(哪怕是短期需要重複使用),使用者都會毫不猶豫的選擇下載native app。雖然確實存在使用者開啟手機瀏覽器通過百度移動搜尋然後訪問mobile web的場景大量存在,但是屬於過路式的流量和低粘性需求,如果web app只能擁抱這種低品質使用者需求,那筆者也無話可說了。目前深度和粘性使用者需求還是需要Native app來滿足。
做HTML5的人和用HTML5的人
HTML5和Web App的支持者所謂的“從使用者角度出發”的機會,都是為了脫離iOS和Android生態系統的掌控,希望迴歸PC端web時代的自由流量模式而尋求的種種藉口。至少目前雲端格局的生態下,native app相比web app代表著更成熟的使用習慣和更好的使用者體驗。沒必要用一種商業邏輯去綁架HMLT5技術和使用者需求。如果我們進一步分析祖克伯的話“我們最大的錯誤是在HTML5上面賭太大”,那麼真正的教訓就應該是:
“不能把對HTML5的商業邏輯的野心凌駕於使用者需求和市場大環境之上”。
我從來不懷疑HTML5作為一種跨平臺的開發標準,隨著時間的推移註定會發揮更大的作用。那麼拋棄商業的邏輯,想把HTML5和Web App單純當成技術來使用的時候,該如何面對呢?
記得2004年前後Web2.0在中國網際網路興起的時候,作為領軍人物的謝文曾經這樣分類網際網路的兩類人,一類是“做網際網路”的人,一類是“用網際網路”的人。所謂做網際網路的人就是把網際網路本身當成生意,而用網際網路的人是把網際網路當成渠道。同樣類比,HTML5的從業者也可以分為“做HTML5”和“用HTML5”的人。
“做HTML5”的人:這裡麵包括了HTML5的工具和平臺廠商、遊戲廠商、Web App開發者和渠道商(如微信和手機瀏覽器)
“用HTML5”的人:擁有其他的業務,HTML5技術和Web App是用來展示自身業務,把微信、手機瀏覽器等當成眾多流量入口之一的使用者。
對於“做HTML5”的人賭生態來說下一步仍舊充分未知和艱辛,因為博弈iOS和Android生態系統不會在短期內看到重大的機會,迎接黎明可能還要很久。就算微信成了Web App很好的一個渠道,但是大環境還是缺乏更廣泛的優質Web App渠道商(至少手機瀏覽器和搜尋入口已經在第一輪競爭中落敗),與虎謀皮的生意能做多大是個挑戰。
對於“用HTML5”的人,選擇是非常簡單的。網際網路是流量的生意,在不同的有流量的入口上佈局是聰明的選擇。如果有足夠的預算,那麼native app、web app以及微信公用賬號甚至百度的輕應用light app都可以實現覆蓋,以便流量最大化,這也是眾多有資源的網際網路公司的通行做法。因為從“用”的角度完全沒必要像“做HTML5”的群體那樣把賭的成分擴大。當然如果預算不夠,從現實的角度微信或native app是更可行的方案,因為眼下這是兩個成型的生態系統,存在較高的商業價值。
技術角度看Web App和Native App
HTML5夢工廠的負責人田愛娜曾經說:“拿HTML5和原生比或Flash比沒有任何意義”,潛臺詞“HTML5只是技術、不要被商業邏輯綁架”。接下來從三個技術角度看web App和Native App的比較:
-
頁面佈局:HTML5配合CSS3以及Canvas確實在跨平臺的介面佈局和展示方面存在效率和成本的優勢。反觀native app的開發技術無論是在開發時間亦或是人員要求和整體成本上都有非常大的差距。但是對於一個能夠充分滿足使用者需求的(web/native)app來說除了介面佈局還有更重要的兩方面技術需求,一個是終端裝置本身的能力API呼叫既端API,另外一個是眾多雲端能力API的呼叫既雲API。那麼這兩方面HTML5的技術到底能不能滿足市場和使用者的需求?
-
端API:HTML5的標準自身配套了device api的部分,但是遺憾的是終端和作業系統的發展已經不能用日新月異來形容,各種新的能力層出不窮。緩慢更新和落後的標準完全無法適應終端的發展以提供最新的端API,因此可以說HTML5在端API領域存在較大的弱勢。如果單純限定HTML5只是在部分展示類的領域滿足使用者需求,可能要糾正市場對HTML5應用範圍的過高預期。
-
雲API:“雲端架構”已經被認定為網際網路最明確的發展趨勢之一,眾多的服務通過雲API的形式提供,各個領域也產生了大量的雲API服務商。常見的如微信和微博分享、支付寶移動支付、雲端儲存等,另外例如融雲IM即時通訊、美洽移動客服等app常用功能都以雲API的方式提供給開發者。此外很多APP也把自身的服務封裝成API嵌入到另外一個APP中,例如Uber把叫車服務以雲API的形式和starbucks進行合作嵌入其中實現了服務的擴充套件和更多流量的聚集。對於雲API不但簡化了APP的開發也增強了移動APP的能力。
在眾多的雲API中,幾乎大部分都同時提供了native sdk和jssdk同時服務native app和web app。所以在雲API的領域HTML5的技術還是有很多可以對接的服務可供選擇。不過總體而言JS版本的sdk無論從功能還是體驗上都和native sdk存在差異,例如百度地圖雲服務API的sdk,使用者使用內嵌到web app的JS版本sdk使用手勢縮放地圖的時候體驗通常較差。HTML5在效能方面和native技術的差異仍舊取決於硬體和瀏覽器效能的提升,但是應該在可預期的時間內獲得解決。
Web App和Native App從技術和使用者需求角度衡量,只有合適不合適,沒有所謂的“生與死”的問題。“用HTML5”的人只要根據預算選擇適合自己的技術就可以脫離賭徒式的迷思。而真正的考驗是留給“做HTML5”的人,隨著HTML5技術的進一步普及和配套環境的成熟,市場機會合適出現並且如何把握是最大的變數。
這種環境下“資本的支援、團隊的組建、隨機而動的靈活”是活下去和壯大的根基。HTML5又逐漸熱起來,Web App和Native App生死的大辯論已經討論了太多,沒必要再來一次。開發者只要緊跟“移動應用開發生態系統”的變遷,就可以始終抓住機會獲得最大的回報,下文將分析《HTML5再起,移動生態系統如何改變?》
本文作者劉鑫,移動雲服務APICloud創始人兼CEO,從SP夢網時代就開始持續關注移動Web開發
相關文章
- Web App和Native App不是生死之爭 而是可以和平共處!WebAPP
- 未來不是Web與App的生死之爭,而是Web和App的融合WebAPP
- web app和native app的區別WebAPP
- EF和Dapper之爭的關鍵APP
- Web App、Hybrid App、Native App 橫向對比WebAPP
- 聊聊Web App、Hybrid App與Native App的設計差異WebAPP
- 使用Vue寫一個cnodejs社群的webapp之後的反思VueNodeJSWebAPP
- 到底getApplicationContext和getApplication是不是返回同一個物件?APPContext物件
- Native APP(原生應用)、Web App(Web應用)、Hybrid App(混合應用) 優缺點分析APPWeb
- 我的第一個React Native AppReact NativeAPP
- 營銷謊言:微信小程式目前並不是Serverless!微信小程式Server
- uni-app實現web-view和App之間的互相通訊APPWebView
- 讓web app更快的HTML5最佳實踐WebAPPHTML
- ionicreact-native和native開發移動app到底那個好ReactAPP
- 關於 Java 的10個謊言Java
- 關於Java的10個謊言Java
- 你的首個 Progressive Web AppWebAPP
- 《React Native高效開發》之create-react-native-appReact NativeAPP
- 分享四個好用的手機APPAPP
- Google Web App開發指南第四章:構建優秀的Web AppsGoWebAPP
- 和AI談倫理、道德和謊言AI
- 這不是魔法:Flask和@app.route(2)FlaskAPP
- 這不是魔法:Flask和@app.route(1)FlaskAPP
- 網站設計菜鳥得到的6個慘痛教訓網站
- BI 7.0 之後的Bex Web ApplicationWebAPP
- 使用duxapp開發 React Native App 事半功倍UXAPPReact Native
- React Native釋出APP之打包iOS應用React NativeAPPiOS
- HTML5的視訊格式之爭HTML
- HTML5的影片格式之爭HTML
- 記錄一次慘痛的“update”操作
- Web Application 開 發 利 器 - WebSnap(四) (轉)WebAPP
- 十個最適合 Web 和 APP 開發的 NodeJS 框架WebAPPNodeJS框架
- 10 個最適合 Web 和 APP 開發的 NodeJS 框架WebAPPNodeJS框架
- 應用開發之爭:App終將回歸原生APP
- 開源一個天氣APP Build with React NativeAPPUIReact Native
- package html to native applicationPackageHTMLAPP
- web與APP之間的互動—WebViewJavascriptBridgeAPPWebViewJavaScript
- iOS 多語言化之痛iOS