上一篇文章《HTML5定稿了？背后还是那场闹剧》谈到了HTML5所谓“定型”背后的商业利益博弈。本文将继续这个话题，反思两年前的“WebApp和NativeApp”大论战，提出一些建设性的意见。2013年是HTML5在中国最惨淡的一年，但直到现在还很少有人反思这种惨淡的根源。“体验经济”的盛行，让“用户体验至上”成为互联网企业的铁律。各行各业也谈用户体验，但在HMTL5从业者的思维中，用户体验被刻意忽视甚至成为“某种借口”。2012年HTML5惨烈的500天HTML5在全球的流行迅速蔓延到中国，业界掀起了一场“WebApp和NativeApp谁生谁死”的大辩论。却不曾想，就在HTML5的话题在国内最火的时候，欧美却接连传来噩耗，不少HTML5的大牌支持者纷纷倒戈：比如Facebook承认，HTML5移动策略是错误的，Apple的AppStore拒绝充当外壳。WebApp分发渠道等等。很快国内支持WebApp和HTML5的排头兵相继死去，当时为数不多的被VC看好的HTML5创业公司也在2013年被迫转型甚至解散。直到500天后2014年那只挑动HTML5“神经”的猫再次出现打破了这种悲观的趋势。一般来说，“用户”的需求会放在具体的“业务”逻辑中，然后选择具体的“技术”来实现，即来自UserBusinessTech。也就是说，技术是底层基础，业务逻辑是基于技术实现的，用户需求是通过业务逻辑封装的技术来满足的。而在HTML5的情况下，技术逻辑成为了优先的部分，打着用户需求的幌子满足野心家的业务需求。这些谎言和谎言可以概括为以下四个方面：谎言一：用户在使用原生应用时，必须去AppStore进行搜索，这是一个繁琐且不友好的过程。答：如果用户不愿意去应用商店搜索，他们还期望像PC一样去手机浏览器搜索网页应用吗？手机浏览器很重要，但在ios和android生态中没有办法和用户的桌面入口竞争。谎言二：原生应用更新频繁，用户对更新感到厌烦。答：应用更新流程经过应用商店和众多手机助手的全面优化，用户习惯已经养成。此外，原生APP的更新意味着更好的用户体验，更多新的系统功能的加入不断提升用户体验。对于WebApp“功能弱”、“体验弱”的属性，凭借所谓的无需手动更新的优势，很难赢得用户的青睐。谎言三：下载和更新原生应用会消耗流量，影响用户使用。答：在如今的网络环境下，流量问题已经不再是用户优先考虑的痛点。wifi的普及甚至为大型游戏和视频应用程序带来了生机。目前，优质的原生应用小至10兆，大至数百兆已是常有的事。此外，根据实际结果的评估，在移动浏览器中重复使用网络应用程序并不会真正减少用户流量。谎言4：用户不愿意下载太多原生应用答：用户真的不愿意下载太多应用吗？用户的手机平均安装了多少个应用程序？对于需要复用的应用（即使短时间内需要复用），用户会毫不犹豫地选择下载原生应用。虽然确实有大量用户打开手机浏览器通过手机百度搜索然后访问手机网页的场景，但属于传递流量，粘性要求不高。如果webapp只能拥抱这种低质量的用户需求，那作者也无话可说了。目前，深度和粘性用户的需求仍然需要NativeApps来满足。做HTML5的人和使用HTML5的人HTML5和WebApp支持者所谓的“站在用户角度”的机会，都是为了脱离iOS和Android生态的控制，希望回归到免费流量模式PC端web时代。找了各种借口。至少在目前的云生态中，原生应用比Web应用代表着更成熟的使用习惯和更好的用户体验。无需使用业务逻辑来绑架HMLT5技术和用户需求。如果我们进一步分析扎克伯格那句“我们最大的错误是在HTML5上押下太多赌注”的话，那么真正的教训应该是：“你不能把HTML5的业务逻辑的野心置于用户需求和市场规模之上，凌驾于环境之上”。我从不怀疑HTML5注定会随着时间的推移作为跨平台开发标准发挥更大的作用。那么抛弃业务逻辑，想把HTML5和WebApp纯粹当成技术来用，怎么办？记得2004年前后，Web2.0在中国互联网兴起的时候，作为领军人物的谢文曾把互联网分为两类人，一类是“做互联网”，一类是“用互联网”.所谓做互联网的人，把互联网本身当做生意，而用互联网的人，把互联网当做渠道。同样的类比，HTML5从业者也可以分为“做HTML5”的和“用HTML5”的。“做HTML5”的人：这包括HTML5工具和平台厂商、游戏厂商、WebApp开发商和渠道商（比如微信和手机浏览器）。“用HTML5”的人：有其他业务，用HTML5技术和WebApp展示自己的业务，将微信、手机浏览器等作为众多流量入口之一的用户。对于“做HTML5”押注生态的人来说，下一步仍是完全未知和艰难，因为iOS和Android生态短期内看不到重大机会，可能需要很长时间才能迎来曙光.即使微信已经成为WebApp非常好的渠道，但大环境仍然缺乏更广泛的优质WebApp渠道商（至少手机浏览器和搜索入口在第一轮竞争中输了），而业务用虎皮就可以做到。挑战有多大。对于“用HTML5”的人来说，选择很简单。互联网是流量生意，布局不同的流量入口是明智的选择。如果有足够的预算，那么nativeapp、webapp、微信公众号甚至百度的轻应用轻应用都可以覆盖，最大限度地提高流量。这也是很多有资源的互联网公司的通行做法。因为从“用”的角度来说，没必要像“做HTML5”的那群人那样去扩充投注元素。当然，如果预算不够，微信或者原生app从实用角度来说是更可行的方案，因为这是两个成熟的生态系统，具有很高的商业价值。从技术角度看，HTML5梦工厂负责人田爱娜曾说过：“拿HTML5与原生或Flash比较是没有意义的”，潜台词“HTML5只是技术，不要被业务逻辑绑架”。接下来我们从三个技术角度来看webApp和NativeApp的对比：页面布局：HTML5结合CSS3和Canvas在跨平台界面布局和展示方面确实在效率和成本上有优势。相比之下，nativeapp的开发技术在开发时间、人员需求和综合成本等方面都有非常大的差距。但是对于一个能够充分满足用户需求的（web/native）app来说，除了界面布局之外，还有两个更重要的技术要求。一是终端设备自身调用已有API的能力API，二是众多的云端能力API。对两个云API的调用。那么这两方面的HTML5技术能否满足市场和用户的需求呢？终端API：HTML5标准本身就支持设备API部分，但遗憾的是，终端和操作系统的发展已经不能用日新月异来形容，各种新能力层出不穷。缓慢更新和过时的标准完全无法适应终端的发展提供最先进的终端API，所以可以说HTML5在终端API方面有比较大的弱点。如果HTML5仅仅局限于满足用户在某些显示领域的需求，可能需要纠正市场对HTML5应用范围的过高期望。CloudAPI：“云架构”已被确定为互联网最明确的发展趋势之一。很多服务都是以云API的形式提供的，各领域也涌现出一大批云API服务商。微信微博分享、支付宝移动支付、云存储等常用功能。此外，融云IM即时通讯、美查手机客服等常用APP功能以云API的形式提供给开发者。此外，很多应用程序还将自己的服务打包成API，嵌入到另一个应用程序中。例如，优步与星巴克合作，以云API的形式嵌入其网约车服务，实现服务扩展和更多的流量聚合。云API不仅简化了APP的开发，还增强了移动APP的能力。在众多的云API中，几乎大部分都同时提供nativesdk和jssdk，同时服务于nativeapp和webapp。因此，在云API领域，仍然有很多服务可以对接HTML5技术。但是总的来说，JS版的sdk在功能和体验上都与原生sdk有所不同。例如百度地图云服务API的sdk，当用户使用webapp内嵌的JS版sdk使用手势缩放地图时，通常体验较差。不同之处。HTML5与原生技术的性能差异仍然取决于硬件和浏览器性能的提升，但应该会在可预见的时间内得到解决。从技术和用户需求的角度，WebApp和NativeApp只是适合不适合，不存在所谓的“生死存亡”问题。“使用HTML5”的人只需根据自己的预算选择适合自己的技术，就可以摆脱赌徒的迷思。真正的考验留给那些“做HTML5”的人。随着HTML5技术的进一步普及和配套环境的成熟，市场机会将会出现，如何把握是最大的变数。在这种环境下，“资金支持、团队组建、灵活多变”是生存和发展的基础。HTML5又火了，WebApp和NativeApp的生死大论已经讨论得太多了，没必要再讲了。开发者只要紧跟“移动应用开发生态”的变化，总能抓住机遇，获得最佳回报。从梦网时代开始，持续关注移动Web开发，个人邮箱：hi.seanliu@yahoo.com
