如何理解扎克伯格说「Facebook 最大错误是在 HTML5 上押注过大,在移动平台上浪费两年时间」?

企鹅博客
企鹅博客
企鹅博客
25193
文章
0
评论
2020年8月28日20:28:52 评论 32 views

回复内容:

从另一个角度说一下:

今天业界热议的事情是Facebook创始人兼CEO马克·扎克伯格在接受采访的时候承认「专注在HTML 5上面是他有史以来犯过的最大的错误。」然后,透露出来的数据是:用户浏览的 Feed 信息流是之前的 2 倍。

Facebook 最初使用 HTML 5 的主要原因是什么呢?一次开发,跨平台发布肯定是其中考虑的一个因素,当然,开发上可以做到快速迭代,这和 Facebook 的工程文化也是相符的。不过,这样实际上是节约了开发成本,获得了开发上的「速度」,这样做也牺牲了用户的体验上的「速度」,牺牲了「性能」。

为什么 Facebook 过度在移动上压注 HTML 5 是不对的?最大可能的原因或许就是「性能」的问题,没有更好的速度就没有更好的用户体验,而用户体验一直是扎克伯格最看重的东西。

扎克伯格从 Facebook 创建之初就认识到,对 Facebook 这样的的网络服务而言,「性能表现就是关键。假如向用户传送新页面的速度开始减缓,那就是致命的一击。」从技术的角度看,Facebook 一向在网站优化上不遗余力,无论是 BigPipe 还是 HipHop for PHP, 这些不遗余力的优化实践以及技术创新为 Facebook 带来了绝佳的用户体验,而移动端押注 HTML 5 则恰恰是无形中背离了 Facebook 的这一准则。

iOS 原生应用发布之后,浏览信息是原来的两倍意味着什么?用户会在意你用 HTML 5 开发还是用的本地原生应用?绝大多数用户都不在乎这个,甚至都不知道,用户更关心的是「应用的速度」,App 是否足够快? 是否可以更流畅的阅读信息,没有人愿意在手机上等待某个应用慢吞吞的打开,就这么简单。

接下来面对 Facebook 的挑战是能否像在 Web 产品上进行的那些最佳实践那样也在移动产品上建立起更有效的研发机制,毕竟这是另外一个战场,一个互联网巨头在移动领域是否还是绝对的统治者? 没有人能知道。

事后诸葛亮一样来评价这个事情的对错本身并不重要,重要的是,我们是否可以从中学到某些教训?

--EOF--

对 HTML 5 来说,谈不上是什么「打击」,或许是好事情也说不定,让更多人认识 HTML 5 的优点和缺点,而不是一窝蜂的冲上去。

我在去年这个时间曾经说过这样一句话「我的两个固执的观点:1 HTML 5 不是移动开发的救星,至少现在不是;2 因为有 1 , 所以类似 PhoneGap 之类的解决方案还不靠谱,没有银弹。还需要再等 18 个月再看。」

现在看起来,还要再等 18 个月了。

本文首发: 福布斯中文网 (URL)。 引用自
http://
internet.solidot.org/in
ternet/12/09/12/0216205.shtml


Mark Zuckerberg则表示,押在HTML5上是Facebook最大的错误。由于
HTML5应用性能差到不能忍受,Facebook只好把所有基于HTML5的移动应用全部改写为原生应用。他还表示这不仅仅是移动设备的问题,
过份相信HTML5本身就是个问题

从编程语言趋势来看,javascript的下降和objectiveC的上升也证明了HTML5并不适合移动应用的开发,
无论怎样用GPU加速,HTML5图形渲染仍主要依赖CPU,无法达到当下软件流畅度的需求

现在看来,Quora这种将HTML的灵活性和本地应用的原生UI结合起来,或许是个更好的做法。 錯估 HTML5 的效能和發展速度,投入兩年時間開發維護和完善一套框架,以為這樣可以統一多個平台的開發,可以加速產品更迭更快推送新特性,最後才發現 HTML5 不夠用,效能有限,移動設備用戶端使用體驗不佳,不能達到預設目標,得到的全是負面反饋。最後又重新轉投 Native. 相當於浪費了兩年的時間同時也錯過了一些可能。我覺得這個事情跟 Joe Hewitt 有著莫大關係,他基本上就是一個 web platform man,他影響了 Facebook 的一些重大決策。 原因是扎克伯格的发现了自己的愚蠢。

HTML5做到极致,就是与原生并无两样,听上去牛逼实际形同放屁。

而且,很难做到极致因为设备差异大。

facebook做了HTML5却实际上没有什么好处,反而坏处多多,各种兼容问题降低了UE,用户才不会去体会HTML做到这种程度已属不易。

同样的还有linked in,也放弃了HTML5。

好像还要往下讲一讲,但是算了。估计也没人看我的答案的。 通过这个事件,我想能Facebook应该反省的一件事是,
如果是选择一项技术作为平台,用“押注”的心态去做,这个心态本身就是错的

像Facebook这样的,包括华为等等大一些的技术性公司,他们最应该担心的平台选择问题是“
受制于人”,这也是我想为什么Google要搞android,微软要搞WP,而Nokia一开始想搞MeeGo。

HTML 5虽然是一个开放的体系,但是其首先远未达到成熟,其次Facebook在标准制定中的话语权并不够大,所以从最后的结果来看,弃用它也是有一定理由的。

不过我觉得现在换用Native方式开发移动应用也不算晚。对于Facebook来说,其移动应用的价值主要还在于Facebook本身所提供内容而不在于界面,同时移动平台本身也有比较充分的文档说明该如何开发高质量Native代码,所以应该可以比较快速的利用Native代码达到超越HTML5界面所带来的使用体验。 html5用于移动互联网的解决方案无疑是最理想的,但问题在于当前设备对html5的支持差异太大,android2.3(189/500), ios5.1(324/500)在加上并非完美支持,在facebook这种用户基数下,这么复杂的使用环境下,问题很多是必然的。facebook在这上面押的注,我理解是试图扫清这些障碍打造一个完美的html5移动平台,或是期待用户手机更快的更新换代,但是两年过去,没有达到预期效果。

但是这并不说明html5不适合移动开发。在ios5.x/ios6上我相信一定能做出不逊于native app体验的应用。只是更多的人还在用低端一些的设备。如果mobile site不是模仿native app,从可用性出发,保证性能,尤其内容消费型产品,也不需要很复杂的交互,目前html5的方案是完全没问题的。现在以及未来都会是web site + mobile site + native apps共同组成一个完整的multiscreen ecosystems。

facebook的工程师blog也说了拥抱原生应用,并不是放弃html5,原生应用中很多部分仍然是用html5做的。 完整的上下文中, Mark说完那句被到处引用的话后,又补充了如下两段

It's not that HTML5 is bad. I'm actually, 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...

We built this internal framework that we called FaceWeb, which was basically this idea that we could take the infrastructure that we built out for pushing code every day, not having to submit to an app store, to build Web code on the Web stack that we have, and that we could translate that into mobile development. We just never were able to get the quality we wanted...

从中我们可以看出:

  • Mobile Web App的用户数仍然大于原生应用, Mark也仍然看好HTML5的长期价值。
  • 从技术上, 基于FaceWeb平台来构建Mobile Web App在当前移动平台上显得超前了, Facebook自己和第三方开发者要保证Mobile Web App在复杂环境下的质量够感到有较大的难度
  • 结合对Instagram的收购,从产品上,Mark意识到以Facebook当前的处境,移动环境下原生API带来的多种丰富可能性在以前被低估了.

我的观点:

  • 如果要面向最广泛的用户群, Mobile Web仍然应该以最高优先级对待.
  • 具备高兼容性的优秀的Mobile Web App所需的工程难度不亚于原生App
  • 以Mobile Web构件基础服务的同时,也要随时关注原生API,具备API掘金者的感觉

facebook的错误在于使用了超前的、不成熟的技术开发产品,从而导致产品体验不佳。

选择在移动平台用html5,大概有几个目的:

1、快速开发和迭代;

2、跨平台兼容性。

但是从目前的现实来看:

1、由于目前处于智能终端快速发展期,各个平台对html5支持的良莠不齐,所以html5开发的应用并不能做到很好的跨平台的兼容性。

2、无线网络发展严重不均衡,导致网速较差的地区html5应用可用性相当差。

3、html5由于渲染方式的不同,性能和native app的性能相比差太多。

综上,html5目前不适合用在移动平台的开发。等待上面的三个问题都得以解决之后,基于html5的web应用才会成为现实的可选项。 讲讲我的理解,应试说,我们目前正在做着类似的事情。

#1,FB也看到了移动互联网未来,这从之前的暴出要做FB手机的传闻可以看出FB对移互联网的重视。对,这确实是未来,但看得到并不一定做得到,尤其是当用旧方式来做的时候。

#2,电脑和手机还是有很多差别的,总结起来就是四多三小。想想之前做互联网时只要搞定IE,IMAC,现在做移动互联网却有无穷屏幕点阵和OS版本的组合。但HTML5,貌似给出总体解决方案。让传统互联网巨头可以不付出太艰辛则可以在移动上获得得同样的成功。提供给了FB从一个山顶跳到另一个顶的可能性和诱惑。于是结果就自然明显了。

#3,最后,人和人之间的关系,通过FB,被扩大了,而世界被缩小了。但FB最吸引外部的“新人”加入的用户的Profile,却在手机上表现得相当糟糕。人来社交,是宣示自己的存在和找到别人的存在,于是如果说Profile不比关系更重要的话,至少是一样重要的。

手机本来就是由于社交而产生的,未来,应该会产生手机上的FB。 关于native和html5带给用户的差别:

去咖啡馆,8秒钟进去,3秒后咖啡端上来。

和3秒钟进去,8秒后咖啡端上来。

你喜欢哪个?

作为旁观者,我看到的几个地方:

错误的想在移动上复制web的成长经验

错误的预估更多的移动设备将会普及

错误的时间选择直奔长远利益

给我的经验是,在移动上,完全是用户体验驱动的。移动上的设计至少现在还是根深蒂固的路径。

继续阅读
企鹅博客
  • 本文由 发表于 2020年8月28日20:28:52
  • 转载请务必保留本文链接:https://www.qieseo.com/346127.html
canvas 动态图表 H5教程

canvas 动态图表

前言 canvas 强大的功能让它成为了 HTML5 中非常重要的部分,至于它是什么,这里就不需要我多作介绍了。而可视化图表,则是 canvas 强大功能的表现之一。 现在已经有了很多成熟的图表插件都...
推荐10款常用的图片压缩上传用法,欢迎下载! H5教程

推荐10款常用的图片压缩上传用法,欢迎下载!

下面小编就为大家带来一篇深入研究HTML5实现图片压缩上传功能。小编觉得挺不错的,现在分享给大家。也给大家一个参考,一起跟随小编过来看看吧上篇文章中提到移动端上传图片,我们知道现在流量还是挺贵的,手机...
HTML5和Webkit实现树叶飘落动画 H5教程

HTML5和Webkit实现树叶飘落动画

HTML5和Webkit在一起会实现什么样的动画呢?本文给大家分享一段实例代码给大家介绍基于HTML5+Webkit实现树叶飘落动画效果,需要的朋友参考下吧,希望能帮组到大家。 实现如图所示的东西效果...
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: