回复内容：
首先反对下现在的一楼的答案，原生效果非常容易实现，他说很艰难我只能怀疑他到底搞清楚HTML5 的API了没，他的比喻
用一堆离散的石头去搭细腻的雕塑一样痛苦不堪。 这一点我是认同的，但是我不认为前端领域现有的工具和技术是
离散的石头。 现在的适用于移动端的前端框架类似：
Ionic: Advanced HTML5 Hybrid Mobile App Framework
Reapp - Hybrid apps, fast
已经非常完善与强大了，效果非常接近原生应用（不包含性能），开发成本也非常低，构建／迭代起来非常快。
最最重要的是如果不想花时间熟悉API,并且花时间对自己目标的系统的各种特性加以了解,那么是无法避免的要掉到一些坑里面爬不出来的。 再说我的观点： 移动应用的未来取决于移动设备芯片性能提升的有多快。 我在2013年的时候读到一篇非常有意思的文章：
为什么移动Web应用程序很慢
这篇文章里面有几个有意思的观点非常值得探讨：
在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/
石墨 - 最优美的在线协作文档
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倍你实际需要的内存，那么灾难就要降临了 。”
相对于手动内存管理都出现指数级的性能下降 。 众所周知 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日期选择框一样的效果，在安卓上也一样效果。
从各个平台来看，移动端是趋势，这也是为什么这几年移动互联网创业火热的原因，就连菜市场卖菜的大妈都要搞自己的app,当然是不是泡沫就另当别论了。我觉得H5的发力点就是在app,H5+js+css-->打包app，简洁、高效、一次开发多平台适用的这种模式将会被越来越多的人接受。HBuilder,AppCan这些整体解决方案的出现，也能让那些嘲笑H5App性功能障碍的native高富帅们消停会了，phonegap+sencha已成过去时，前端的福音已经到来。
我在看老周的《方法论》时，他有一个观点我特别认同，‘‘你永远打不败的竞争对手就是趋势，趋势一旦爆发，就不会是一种线性发展，它会积蓄力量于无形，最后突然爆发成雪崩效应，任何不愿意改变的力量都会被毁灭，被市场边缘化’’，H5就是未来的趋势，虽然发展有些曲折，但你看看w3c不断推出的H5特性，各大公司的招聘启示，就连我卖茶叶蛋的同学都知道H5game...,你知道为什么所有的前端都对ie嗤之以鼻吗？难道是因为界面丑吗？图样图森破！
APP html5化是一个趋势 微信 支付宝等超级APP 非核心功能基本上都用html5实现的 这种优势就是更新快 部署快 不需要用户升级APP 不需要苹果审核 但如果html5想要完全替代原生APP 个人不看好
H5的生态圈正在完善，引爆H5是迟早的事，拭目以待。
首先，移动是未来的趋势，移动可以让人们充分利用碎片时间，满足各种需求。
其次，html5是一种实现移动应用的方式，随着device API的丰富，给了h5各种可能性
那么，html5可以做什么？
大家讨论的比较多的是html5和native的性能对比，开发速度，维护，升级等方面的问题，但这些在我看来不是大问题，随着硬件的提升，相信html5的性能会越来越好。我比较看好的是device API在未来可以应用的空间：
1. 利用重力感应开发物理游戏
2. 陀螺仪实现摇一摇
3. video和audio开发语音识别和视频通话、虚拟现实、增强现实
4. 湿度和温度传感器可以开发智能家居
5. webnfc可以用来开发近场通讯支付
6. 震动API
7. 距离传感器
8. 噪音检测
未来还会有更多的传感器API实现，相信这将会让前端开发者有机会开发智能应用。
前景还是不错的。一是手机的CPU和GPU越来越强，二是在iOS8和安卓5.0以上，所有应用程序内嵌的Web浏览器控件都得到了跟原生浏览器一样的性能支持，这是个引爆点。
开发语言降低门槛和人类可续技术进度都是一定会发生的事情。
为什么有很多名人让人们警惕人工智能？ - 科技
看了这篇文章你就能感觉到 了。
