最近，Facebook 掌门人扎克伯格表示，Facebook 在过去几年中的最大错误在于对 HTML5 押注过多，忽视了原生应用，同时他对 HTML5 的长期趋势依然看好。针对扎克伯格的言论，国内开发社区对此展开了广泛的讨论，其中不乏真知灼见。
张克军认为 HTML5 非常适合移动互联网，但是 Facebook 的用户量太大，难以支持各种移动设备：
HTML5 用于移动互联网的解决方案无疑是最理想的，但问题在于当前设备对 HTML5 的支持差异太大，Android2.3(189/500), iOS5.1(324/500) 再加上并非完美支持，在 Facebook 这种用户基数下，这么复杂的使用环境下，问题很多是必然的。Facebook 在这上面押的注，我理解是试图扫清这些障碍打造一个完美的 HTMLl5 移动平台，或是期待用户手机更快的更新换代，但是两年过去，没有达到预期效果。
但是这并不说明 HTML5 不适合移动开发。在 iOS5.x/iOS6 上我相信一定能做出不逊于原生应用体验的应用。只是更多的人还在用低端一些的设备。如果移动网站不是模仿原生应用，从可用性出发，保证性能，尤其内容消费型产品，也不需要很复杂的交互，目前 HTML5 的方案是完全没问题的。现在以及未来都会是 Web site + Mobile site + Native APP 共同组成一个完整的 Multiscreen Ecosystems。
Facebook 的工程师博客也说了拥抱原生应用，并不是放弃 HTML5，原生应用中很多部分仍然是用 HTML5 做的。
Fenng 认为 Fackbook 反思 HTML5 的最可能原因是没有提供更好的用户体验：
为什么 Facebook 过度在移动上压注 HTML 5 是不对的？最大可能的原因或许就是性能的问题，没有更好的速度就没有更好的用户体验，而用户体验一直是扎克伯格最看重的东西。
扎克伯格从 Facebook 创建之初就认识到，对 Facebook 这样的的网络服务而言，性能表现就是关键。假如向用户传送新页面的速度开始减缓，那就是致命的一击。技术的角度看，Facebook 一向在网站优化上不遗余力，无论是 BigPipe 还是 HipHop for PHP， 这些不遗余力的优化实践以及技术创新为 Facebook 带来了绝佳的用户体验，而移动端押注 HTML 5 则恰恰是无形中背离了 Facebook 的这一准则。
iOS 原生应用发布之后，浏览信息是原来的两倍意味着什么？用户会在意你用 HTML 5 开发还是用的本地原生应用？绝大多数用户都不在乎这个，甚至都不知道，用户更关心的是“应用的速度”，App 是否足够快? 是否可以更流畅的阅读信息，没有人愿意在手机上等待某个应用慢吞吞的打开，就这么简单。
接下来面对 Facebook 的挑战是能否像在 Web 产品上进行的那些最佳实践那样也在移动产品上建立起更有效的研发机制，毕竟这是另外一个战场，一个互联网巨头在移动领域是否还是绝对的统治者? 没有人能知道。
事后诸葛亮一样来评价这个事情的对错本身并不重要，重要的是，我们是否可以从中学到某些教训?
对 HTML 5 来说，谈不上是什么「打击」，或许是好事情也说不定，让更多人认识 HTML 5 的优点和缺点，而不是一窝蜂的冲上去。
我在去年这个时间曾经说过这样一句话“我的两个固执的观点：1 HTML 5 不是移动开发的救星，至少现在不是；2 因为有 1 , 所以类似 PhoneGap 之类的解决方案还不靠谱，没有银弹。还需要再等 18 个月再看。”
现在看起来，还要再等 18 个月了。
Levski 认为“如果是选择一项技术作为平台，用“押注”的心态去做，这个心态本身就是错的。”
通过这个事件，我想能 Facebook 应该反省的一件事是，像 Facebook 这样的，包括华为等等大一些的技术性公司，他们最应该担心的平台选择问题是“受制于人”，这也是我想为什么 Google 要搞 android，微软要搞 WP，而 Nokia 一开始想搞 MeeGo。
HTML 5 虽然是一个开放的体系，但是其首先远未达到成熟，其次 Facebook 在标准制定中的话语权并不够大，所以从最后的结果来看，弃用它也是有一定理由的。
不过我觉得现在换用 Native 方式开发移动应用也不算晚。对于 Facebook 来说，其移动应用的价值主要还在于 Facebook 本身所提供内容而不在于界面，同时移动平台本身也有比较充分的文档说明该如何开发高质量 Native 代码，所以应该可以比较快速的利用 Native 代码达到超越 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 形式）。
郭瑞超则根据自己的经验分析了采用 HTML5 技术面临的问题：
看似它有了一套严格的标准，但是它扛不住不同平台的本地实现的不同，它看起来可以帮我们偷懒，却很难使我们的产品在一个平台将那个平台的特性发挥到极致。
更深入的，使用 HTML5 可以脱离商店的束缚，你的商店规则对我无效了，这看似自由了，但你相当于同时放弃了对平台资源的利用，这样的对比下，显然放弃平台资源并不理智，除非你自己有很强大的渠道。
而且 HTML5 是一个完善中的标准，它随时产生变化，稳定性还不如平台，为了兼顾这套标准，我的成本非但没有降低，还增加了。
读者朋友对此有何看法？
评论