即使 Facebook 不喜欢被控制，也不能拿被用户抛弃来冒险。而且 Facebook 并没有掌握关键点—手机浏览器内核。如果浏览器不跟上，徒然定一堆标准草案落不了地。
而浏览器在手机上的表现是什么呢?先看 Google，Chrome 性能虽高，但 Android 上的浏览器却并非 Chrome，而是 WebKit 改出来的一个蹩脚的 Android 浏览器;再看苹果，iOS 上不允许其他浏览器引擎上架 App Store，而且其他使用 Safari 引擎的应用也无法调用苹果自己的 JavaScript 加速引擎 Nitro。结果是苹果和 Google 不但不在浏览器上积极实现 HTML5 关于移动 App 所需的规范，反而对 HTML5 做出种种限制。
不管是当时硬件能力不足，还是手机 OS 厂商的故意限制，总之结果就是：在移动互联网的初期，一定是原生应用生态系统的天下，iOS 和 Android 首先自己的地盘稳固后，产业才会向下个阶段升级。
Facebook 也好，PhoneGap 也好，想在移动互联网初期就分一杯羹是分不到的，但坚持下来，机会往往会出现。
四、 HTML5 这回真的来了
终于，在 2014 年 10 月底，W3C 宣布 HTML5 正式定稿。这个时间，不晚不早，硬件性能更强、手机 OS 迭代速度下降。
随着 HTML5 标准定稿，一切纷争将告一段落，现在，属于 HTML5 的时代到来了。
有人说，光标准定稿没用啊，配套起来了吗?HTML5 做的应用究竟能否匹敌原生 App?答案是，HTML5 不但可以匹敌原生 App，甚至它天然的很多特性超越了原生 App。
我们先谈谈 HTML5 原来不如原生应用的地方，业内俗称 HTML5 有“性工能”障碍。即 HTML5 性能不如原生、开发工具不如原生、能力调用不如原生。
这几个问题导致开发者无法使用 HTML5 做出与原生一样的 App。然而，不管是硬件升级还是 OS 厂商策略变化，以及相关软件技术的成熟，已解决了 HTML5 的“性工能”障碍。
1. 硬件升级
2011 年，iPhone 4s 的 CPU 是 A5，现在 iPhone 6 是 A8，按苹果的历次发布会的说法，速度共提升了 7.5 倍。这 3 年间 7.5 倍的速度提升，抹平了太多 HTML5 的性能问题。
2. 苹果、Google 的策略变化
Google 在 2013 年底发布的 Android 4.4，内置的 Webview 不再是蹩脚的 Android WebKit 浏览器，而是 Chromium，性能大幅提升。从最新的 Android5.0 开始，Webview 可以通过 Google Play Store 实时更新，和 Chrome 的升级保持一致，用户就可以不刷机享受到最新的浏览器引擎;再看 Apple 方面，2012 年 iPhone 5 发布后，HTML5 在 iOS 上的表现已令人满意，Safari 独家的 JavaScript 加速引擎 Nitro 不再那么重要，不过在 iOS 8 发布后，苹果还是很识趣地取消了三方程序调用 Nitro 的限制，现在任意浏览器或应用调用 iOS 的 UIWebview 都可以利用 Nitro 加速，这样在前端使用 JS 做大型运算也成为可能。两大手机操作系统霸主和浏览器巨头的态度发生了变化，使得 HTML5 在手机上的发展不再受限，而且这个变化不可逆只能继续向前，这种变化势必会产生深远的影响。
3. 软件技术的成熟
PhoneGap 的发展虽然放缓了，但其他产品技术却成熟了。2014 年的 iWeb 大会上，众多厂商的产品提供了面向开发者免费或开源的 HTML5 性工能障碍的解决方案。
(注：编者作为从业人员，也会在分析各种方案时提到我们公司的方案，但编者会客观不夸张的陈述方案，而且该方案是纯免费的，没有商业销售嫌疑。)
DCloud 公司在 iWeb 大会上发布了系统的 HTML5“性工能缺失”的解决方案，包括：
a) 性能：提升 HTML5 性能的手机端引擎，让侧滑菜单、下拉刷新等动态交互卡顿的问题得以解决;
b) 工具：HTML5 开发 IDE 产品 HBuilder, 超快的编程利器;
c) 能力：把 40 万原生 API 封装成 JavaScript 对象，以解决 HTML5 能力不足问题的 Native.js 技术;
d) 最接近原生体验的高性能框架：MUI 框架，体积只有几十K，加载、运行远快于一般框架。
基于该方案开发的 HTML5 应用完全可以达到原生 App 的功能和体验。