如何看待html5在移动端的未来？

回复内容：

首先反对下现在的一楼的答案，原生效果非常容易实现，他说很艰难我只能怀疑他到底搞清楚HTML5 的API了没，他的比喻

用一堆离散的石头去搭细腻的雕塑一样痛苦不堪。

这一点我是认同的，但是我不认为前端领域现有的工具和技术是离散的石头。
现在的适用于移动端的前端框架类似：

• Ionic: Advanced HTML5 Hybrid Mobile App Framework
  
• Reapp - Hybrid apps, fast
  

已经非常完善与强大了，效果非常接近原生应用（不包含性能），开发成本也非常低，构建／迭代起来非常快。

最最重要的是如果不想花时间熟悉API,并且花时间对自己目标的系统的各种特性加以了解,那么是无法避免的要掉到一些坑里面爬不出来的。

再说我的观点：


移动应用的未来取决于移动设备芯片性能提升的有多快。

我在2013年的时候读到一篇非常有意思的文章：

为什么移动Web应用程序很慢

这篇文章里面有几个有意思的观点非常值得探讨：

1. 在Benchmark中，Javascript 的速度比原生代码慢4.5 ~ 5倍

如果你在想“如果是计算密集型（CPU-bound）的功能，本地代码比Nitro JS快多少呢”，那么答案是差不多5倍。这个结果大致上和Benchmark Game在x86/GCC/V8上面的结果一致，那里面的GCC/x86通常比V8/x86快2到9倍。所以结果大致上是正确的，无论是ARM还是x86。

这里关键是要理解4.5 ～ 5倍是什么程度的差距：

如果你的C程序运行了10ms，那么一个运行50ms的JavaScript程序差不多是接近C的速度了。如果你的C程序运行了10s，那么一个运行了50s的JavaScript程序对于大多数正常人来说很可能就不是接近C的速度了。

2. x86架构的CPU比ARM 架构的 CPU 快 10倍左右

这个数据来自于作者2013年写文章的时候，对比的是 iPhone 5 和 Macbook Pro. 恰巧我手上就有一部 iPhone 5，它在现在(2015年中) 运行相当复杂的web app都可以达到令人满意的流畅度。
下面是广告：
我测试过

• https://weixin.teambition.com/ (需要关注teambition 微信公众号，在微信内访问)
• 石墨 - 最优美的在线协作文档
• https://onedrive.live.com/
  

这些webapp 基本是我能找到的市面上最复杂的mobile web app，但是离它们各自的desktop web app version 体验和复杂度都还差很远（不好具体的量化，但是可以很好的反映出desktop 和 mobile 10倍的性能差距）。而实际上，这些应用的 desktop version 的功能和体验，已经完全不输 native app了，这说明在一些场景下（在线协同文档编辑这个复杂量级及其以下的场景），webapp 已经可以差不多达到 native app 的性能以及体验了。

3. ARM 在短时间内性能很难追上 x86

作者在2013年引用了很多东西来证明这一点，但是到现在其实我还不能确定 短时间 有多短，因为按照目前的情况来看： Apple Nvidia Qualcomm 的 ppt 越写越厉害。
但我对硬件其实也没有很深入的研究，没有找到客观数据也不好确定 ARM 从13 年到15 年到底有多大的性能提升。
我的观点是，摩尔定律可能还会在一段时间内是正确的，但是性能提升的比例是否和晶体管数量增加的比例成正比值得怀疑。

4. 由于GC的存在，内存对性能的影响远比硬件性能差距带来的影响大的多的多

这个情况可能在近几年得到改善，因为现在甚至出现了 4GB RAM 的 Android 设备和 2GB RAM的 iOS设备。
这是文中最重要的一幅图：

Y轴是垃圾回收所用的时间，X轴是“相对的内存足迹”，相对于什么？相对于所需的最小内存。

这张图想说明的是，“如果你有6倍以上你实际需要的内存，那么使用垃圾回收是没有问题的。但是如果你只有小于4倍你实际需要的内存，那么灾难就要降临了。”

特别的，如果垃圾回收时系统拥有5倍于所需的内存时，它的运行时性能差不多甚至是超过显式内存管理。但是，垃圾回收的性能在必须使用小堆（small heap）的情况下会出现急剧下降。如果有3倍于所需的内存的话，它会跑得慢17%；如果只有2倍于所需的内存的话，会慢70%。垃圾回收比物理内存的换页更容易受到内存不足的影响。在这种情况下，我们所测试的所有垃圾回收器相对于手动内存管理都出现指数级的性能下降。

众所周知 Javascript 是无法手动管理内存的，这也意味着，在内存足够大（5倍于 webapp 运行时所需内存）之前，我们无法做任何事情来对这种影响进行优化。

5. Javascript 的实现在近几年 （2011 ~ 2013 ） 并没有本质的性能提升

这里是作者测试的 Chrome 10 vs Chrome 27

在我看来，在这个期间的性能提升还是太小，不足以支撑JS马上就会足够快这样的论调。然而，要说我过分强调这个情况也没错，毕竟JavaScript的计算密集型操作的确在发生变化。但是推我来说，这些数字可以得出更大的推断：这些性能提升的幅度还不足以在一定时间之内使得JavaScript的速度赶上原生代码。你需要性能达到2-9倍才能跟LLVM竞争。这些提升是好的，但还不足够好。

Javascript 引擎的性能提升确实不足以支撑 “Javascript 马上就能变得足够快” 这一假设。

6. 电池技术的发展至关重要

这一点其实是最好理解的，性能的提升带来的是功耗的增加。


总结一下我的看法：
1. 移动 web app（提问是html 5，我认为不太准确）的发展主要受到性能的制约，目前已经有足够复杂的 Desktop Web App 实现，例如Google docs， ondrive ， Teambition（广告）这样，受制于性能的差距，移动端现在还没有条件实现这么复杂的 web app.


2. 移动web app 可能很快（我的预测是3~5年）就会达到目前 （2015年）的复杂度，预测这个时间是因为我了解到在最新版本的Android 中 搭载 V8 引擎的 Chrome 将会成为默认浏览器（非常重要），以及 64 位 ARM 处理器的快速发展（更多大内存的移动设备将会出现）.


3. 前端技术的高速发展足以支撑 mobile web app能够做到足够复杂（已经有不少了），在工程化方面前端已经开始慢慢的缩小和一些有着悠久历史语言的差距了（还是差很远）。


4. mobile web app 很有前途，瓶颈不在html css Javascript 身上，每种语言都有缺陷，足够了解就可以避免踩坑。


另外，建议大家读一下引用的文章，写的非常严谨：为什么移动Web应用程序很慢 适合内容型（也就是传统网站）应用。稍微复杂一些的，都不适合。以后也不适合。

我现在用HTML5开发移动应用，也不复杂，但是比预想的麻烦很多，效果和成本都比开发两套原生程序差。

这跟HTML、JavaScript、CSS的先天缺陷有关。就像用一堆离散的石头去搭细腻的雕塑一样痛苦不堪。

尤其是客户要求实现原生一样的效果就更痛苦了。比如客户要求移动WebApp实现和iOS日期选择框一样的效果，在安卓上也一样效果。 从各个平