热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

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

回复内容: 从另一个角度说一下:今天业界热议的事情是Facebook创始人兼CEO马克·扎克伯格在接受采访的时候承认「专注在HTML 5上面是他有史以来犯过的最大的错误。」然后,透露出来的数据是:用户

回复内容:

从另一个角度说一下:

今天业界热议的事情是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)。 引用自 internet.solidot.org/in
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的成长经验
错误的预估更多的移动设备将会普及
错误的时间选择直奔长远利益

给我的经验是,在移动上,完全是用户体验驱动的。移动上的设计至少现在还是根深蒂固的路径。
推荐阅读
  • 一、使用HTML5构建移动应用世界正在走向移动化,每天都有数百万部智能手机被激活。因此,为消 ... [详细]
  • 知识图谱——机器大脑中的知识库
    本文介绍了知识图谱在机器大脑中的应用,以及搜索引擎在知识图谱方面的发展。以谷歌知识图谱为例,说明了知识图谱的智能化特点。通过搜索引擎用户可以获取更加智能化的答案,如搜索关键词"Marie Curie",会得到居里夫人的详细信息以及与之相关的历史人物。知识图谱的出现引起了搜索引擎行业的变革,不仅美国的微软必应,中国的百度、搜狗等搜索引擎公司也纷纷推出了自己的知识图谱。 ... [详细]
  • 基于layUI的图片上传前预览功能的2种实现方式
    本文介绍了基于layUI的图片上传前预览功能的两种实现方式:一种是使用blob+FileReader,另一种是使用layUI自带的参数。通过选择文件后点击文件名,在页面中间弹窗内预览图片。其中,layUI自带的参数实现了图片预览功能。该功能依赖于layUI的上传模块,并使用了blob和FileReader来读取本地文件并获取图像的base64编码。点击文件名时会执行See()函数。摘要长度为169字。 ... [详细]
  • HDU 2372 El Dorado(DP)的最长上升子序列长度求解方法
    本文介绍了解决HDU 2372 El Dorado问题的一种动态规划方法,通过循环k的方式求解最长上升子序列的长度。具体实现过程包括初始化dp数组、读取数列、计算最长上升子序列长度等步骤。 ... [详细]
  • 本文讨论了Alink回归预测的不完善问题,指出目前主要针对Python做案例,对其他语言支持不足。同时介绍了pom.xml文件的基本结构和使用方法,以及Maven的相关知识。最后,对Alink回归预测的未来发展提出了期待。 ... [详细]
  • 本文讨论了如何优化解决hdu 1003 java题目的动态规划方法,通过分析加法规则和最大和的性质,提出了一种优化的思路。具体方法是,当从1加到n为负时,即sum(1,n)sum(n,s),可以继续加法计算。同时,还考虑了两种特殊情况:都是负数的情况和有0的情况。最后,通过使用Scanner类来获取输入数据。 ... [详细]
  • 本文介绍了OC学习笔记中的@property和@synthesize,包括属性的定义和合成的使用方法。通过示例代码详细讲解了@property和@synthesize的作用和用法。 ... [详细]
  • Mac OS 升级到11.2.2 Eclipse打不开了,报错Failed to create the Java Virtual Machine
    本文介绍了在Mac OS升级到11.2.2版本后,使用Eclipse打开时出现报错Failed to create the Java Virtual Machine的问题,并提供了解决方法。 ... [详细]
  • 1,关于死锁的理解死锁,我们可以简单的理解为是两个线程同时使用同一资源,两个线程又得不到相应的资源而造成永无相互等待的情况。 2,模拟死锁背景介绍:我们创建一个朋友 ... [详细]
  • 《数据结构》学习笔记3——串匹配算法性能评估
    本文主要讨论串匹配算法的性能评估,包括模式匹配、字符种类数量、算法复杂度等内容。通过借助C++中的头文件和库,可以实现对串的匹配操作。其中蛮力算法的复杂度为O(m*n),通过随机取出长度为m的子串作为模式P,在文本T中进行匹配,统计平均复杂度。对于成功和失败的匹配分别进行测试,分析其平均复杂度。详情请参考相关学习资源。 ... [详细]
  • 动态规划算法的基本步骤及最长递增子序列问题详解
    本文详细介绍了动态规划算法的基本步骤,包括划分阶段、选择状态、决策和状态转移方程,并以最长递增子序列问题为例进行了详细解析。动态规划算法的有效性依赖于问题本身所具有的最优子结构性质和子问题重叠性质。通过将子问题的解保存在一个表中,在以后尽可能多地利用这些子问题的解,从而提高算法的效率。 ... [详细]
  • Java验证码——kaptcha的使用配置及样式
    本文介绍了如何使用kaptcha库来实现Java验证码的配置和样式设置,包括pom.xml的依赖配置和web.xml中servlet的配置。 ... [详细]
  • 高质量SQL书写的30条建议
    本文提供了30条关于优化SQL的建议,包括避免使用select *,使用具体字段,以及使用limit 1等。这些建议是基于实际开发经验总结出来的,旨在帮助读者优化SQL查询。 ... [详细]
  • 在project.properties添加#Projecttarget.targetandroid-19android.library.reference.1..Sliding ... [详细]
  • Hadoop源码解析1Hadoop工程包架构解析
    1 Hadoop中各工程包依赖简述   Google的核心竞争技术是它的计算平台。Google的大牛们用了下面5篇文章,介绍了它们的计算设施。   GoogleCluster:ht ... [详细]
author-avatar
不要哭开心就好_723
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有