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

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

php中文网(www.php.cn)提供了最全的编程技术基础教程,介绍了HTML、CSS、Javascript、Python,Java,Ruby,C,PHP,MySQL等各种编程语言的基础知识。同时本站中也提供了大量的在线实例,通过实例,您可以更好的学习编程。..

回复内容:

从另一个角度说一下:

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

给我的经验是,在移动上,完全是用户体验驱动的。移动上的设计至少现在还是根深蒂固的路径。
推荐阅读
  • Framework7:构建跨平台移动应用的高效框架
    Framework7 是一个开源免费的框架,适用于开发混合移动应用(原生与HTML混合)或iOS&Android风格的Web应用。此外,它还可以作为原型开发工具,帮助开发者快速创建应用原型。 ... [详细]
  • HTML 5定稿了?背后还是那场闹剧
    HTML5虽然只是一个技术标准,但是眼下更多承载着颠覆苹果与谷歌移动生态的理想。我并不想单纯从技术角度谈论HTML5的现实处境,因为技术从来不会成为发展的绝对瓶颈,尤其是HTML5 ... [详细]
  • 一、使用HTML5构建移动应用世界正在走向移动化,每天都有数百万部智能手机被激活。因此,为消 ... [详细]
  • 送给设计师们的礼物:10个网站提高你的创意理念
    MyModernMetropolis,这个是我很喜欢的一个网站,细心的朋友会发现DDDesign有一部分文章是来自这里,如果你寻找创意灵感,这个也许是个很好的开始。2.FFFFou ... [详细]
  • LDAP服务器配置与管理
    本文介绍如何通过安装和配置SSSD服务来统一管理用户账户信息,并实现其他系统的登录调用。通过图形化交互界面配置LDAP服务器,确保用户账户信息的集中管理和安全访问。 ... [详细]
  • 自动验证时页面显示问题的解决方法
    在使用自动验证功能时,页面未能正确显示错误信息。通过使用 `dump($info->getError())` 可以帮助诊断和解决问题。 ... [详细]
  • 本文介绍了如何使用 CMD 批处理脚本进行文件操作,包括将指定目录下的 PHP 文件重命名为 HTML 文件,并将这些文件复制到另一个目录。 ... [详细]
  • 解决Bootstrap DataTable Ajax请求重复问题
    在最近的一个项目中,我们使用了JQuery DataTable进行数据展示,虽然使用起来非常方便,但在测试过程中发现了一个问题:当查询条件改变时,有时查询结果的数据不正确。通过FireBug调试发现,点击搜索按钮时,会发送两次Ajax请求,一次是原条件的请求,一次是新条件的请求。 ... [详细]
  • 本文详细介绍了DMA控制器如何通过映射表处理来自外设的请求,包括映射表的设计和实现方法。 ... [详细]
  • Spark中使用map或flatMap将DataSet[A]转换为DataSet[B]时Schema变为Binary的问题及解决方案
    本文探讨了在使用Spark的map或flatMap算子将一个数据集转换为另一个数据集时,遇到的Schema变为Binary的问题,并提供了详细的解决方案。 ... [详细]
  • 本文源自极分享,详细内容请参阅原文。技术债务如同信用卡负债,随着时间推移,修复成本会越来越高,因此程序员必须对此有深刻认识。此外,团队应致力于培养一种持续维护和优化代码的文化,以减少技术债务的累积。 ... [详细]
  • 作为140字符的开创者,Twitter看似简单却异常复杂。其简洁之处在于仅用140个字符就能实现信息的高效传播,甚至在多次全球性事件中超越传统媒体的速度。然而,为了支持2亿用户的高效使用,其背后的技术架构和系统设计则极为复杂,涉及高并发处理、数据存储和实时传输等多个技术挑战。 ... [详细]
  • 概念:懒蚂蚁效应日本北海道大学进化生物研究小组对一群黑蚂蚁进行了研究。他们把蚂蚁分为三个小组,每组30只,观察他们的行为。研究人员发现,大部分蚂蚁都很勤快地工作,寻找、搬运食物,但 ... [详细]
  • PhoneGap 介绍
    一、PhoneGap是什么1、PhoneGap是一个用基于HTML,CSS和JavaScript的,创建移动跨平台移动应用程序的快速开发框架。2、它使开发者能够利用iPhone,A ... [详细]
  • 如何完美的解决时间轴开发中的
    这些天,正在赶一个Ionic+phoneGap+Angular1.0的项目整改,具体涉及到的一个时间轴的开发。首先贴出UI设计图,是图中的蓝色部分的开发:备注:由于这部分 ... [详细]
author-avatar
手机用户2502905381
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有