从历史说起
英国科学家Tim Berners-Lee在1989年发明了万维网（World Wide Web），他发明了三项关键技术：
- 统一资源标识符（URI），全球网络资源唯一认证的系统。
- 超文本传送协议（HTTP），客户端与服务器交互的协议。
- 超文本标记语言（HTML），超文本文档的结构和格式。
随着Web的发展，Tim Berners-Lee 意识到，只有任何人在任何地方都可以使用而无需付费或获得许可，Web才会发挥出真正的潜力。在1993年他说服了CERN同意永久免费提供WWW的基础代码，极大的推动了全球开发者的创造力，协作和创新浪潮。Tim Berners-Lee 在1994年推动成立了万维网联盟（W3C），一个致力于开发开放式网络标准的国际社区。
- 无中心： 没有*控制节点，可以*的在网络发布任意内容。
- 无歧视：所有网络参与者可以平等的进行交流，不受操作系统，网络运营商，等等的影响。
- 自下而上设计： 鼓励大家参与和实验，而不是由一小部分专家编写和控制。
- 普遍性：所有人都可以在网络上发布任何东西，不受硬件，地理位置，信仰文化，等等的影响。
- 共 识：大家可以*的参与规范的讨论，但必须遵循已形成标准的规范。
正是这种*平等开放共享的精神，使得Web面对各种挑战，依然能一次又一次的焕发生机。
Native技术的兴起
从Web的发展历史我们可以看到，W3C标准化组织在非常早期就成立了，这对Web的标准化发展至关重要。但是，我们也可以看到，W3C标准的落地周期可能非常长，提出讨论，实现，定稿，过程很漫长。而人们对性能体验等方面的需求是与时俱进的，甚至是越来越挑剔的。
那么，如果在某个时间段，使用标准的Web技术无法实现用户需求，怎么办呢？没有实现不了的需求，无论使用什么技术都是要解决问题的。这样我们就非常可能会使用非标准的手段去解决阶段性局部性的问题。
举个例子，在移动互联网之初，网络性能极差，资源走网络加载基本是不可接受的。这就催生了很多离线包技术，就是使用标准的WebViewClient.shouldInterceptRequest去拦截资源请求，返回本地离线包资源，以达到提升资源加载性能的目的。这种Web与Native技术的结合方式，其实是非常推荐的。为什么呢？因为它本质上还是标准的技术，使用了标准的接口去做资源拦截，而且是不影响前端页面的写法，前端页面还是根据W3C的规范去写，只不过在没有实现离线包功能的客户端里运行，就享受不到离线包的优化而已。
再举个例子，很多人认为WebView的渲染性能比不上View的渲染性能，这样就提出了类似weex之类的技术，通过自定义一套规范，增加一系列约束条件，而达到更好性能体验的目的。这些技术在某些阶段的确是快速解决了用户的痛点，而且也间接加速了Web技术的发展，但作为底层基础技术也存在一些明显的问题，比如，它不是标准的技术，意味着在某个体系之外是不可使用的；它能实现的是CSS的一个子集，很可能一些新特性无法支持或者需要客户端开发支持；它如果要跟进Web技术的发展，必然需要逐步增加功能，变得越来越臃肿，设计之初的优势就不存在了。
再谈性能与体验
在很多人的印象里，WebView的渲染性能比不上View的渲染性能，是Web性能体验的瓶颈所在。
事实真的是这样吗？我们先看看页面的性能的组成部分，
（1）资源加载
资源加载，通常会包含HTML文档，CSS，JS，首屏数据，模块资源 和 图片。
（2）JS执行
JS执行，通常会包含页面依赖的一系列JS执行，页面JSON数据解析，页面节点插入和排版。
（3）页面内容渲染
页面内容渲染，通常是指文本渲染，图片解码和图片渲染。
我们跟进了非常多亿级PV的业务性能体验，发现页面内容渲染通常不是瓶颈，在非常低端的手机里都能在200ms内完成，而资源加载和JS执行却波动非常大，往往会成为性能瓶颈。比如，资源在离线包里，数据被预加载了，就会非常快，反之就非常慢，可能需要好几秒；再比如，JS依赖非常多，JS渲染的内容非常复杂，则会比较耗时。
也就是说，Native技术宣传的View渲染速度并不是页面的性能瓶颈所在，资源加载和JS执行才是页面性能的关键。而资源加载和JS执行方面的优化，并不是Native技术的专利，如果这些优化能用在Native技术场景，通常也能用在Web技术场景。所以，我们也可以看到今年双11天猫主会场的页面，在中高端手机上，其实Web的性能体验更好。
我们判断，移动端的Web性能体验问题，在最近两年内会彻底解决掉。我们作出这样的判断，是基于，
（1）Web引擎的飞速发展
渲染引擎和JS引擎发展迅速，V8 codecache技术基本解决了大型JS解析性能问题，JS引擎性能在不断变好，中高端手机上JS执行性能问题已经很小。
（2）手机硬件性能快速提升
手机CPU性能不断提升，iPhone X的CPU已经能媲美PC机了。手机内存也在不断变大，2019年6G内存基本会成为标配。
（3）移动网络不断变好
目前WIFI+4G网络，在一些端已经超过98%，国内网络在不断的变好，流量费用也会越来越低，甚至不远的将来还会全面推进5G网络。
从技术优化的角度，我们也总结出了Web优化模型，就是 首屏离线渲染方案。
所谓首屏离线渲染，就是首屏渲染需要的内容都能从本地存储获得。那么，怎么才能做到这个事情呢？首屏内容一般包括资源和数据。资源就比较简单，使用离线包技术完全可以做到离线化。
数据其实有两种，一种是描述型的JSON数据，一种是渲染完成的DOM结构数据。描述型的JSON，一般还需要通过JS执行转换为DOM结构数据，从性能的角度当然是直接离线获取到DOM数据的效果更好。数据离线化一般是通过预取或者存储旧数据来实现。比如，今日头条刷新列表时，就会把列表里的文章内容都下载到本地；再比如，天猫超市非首次打开，会先从LocalStorage里获取前一次的数据进行渲染，再同时进行Dom-Diff更新。
也就是说，在移动端其实我们也有很多方案能实现首屏离线渲染，实现极速的完美Web体验。
Web与Native的融合
那么，是不是说Web技术就无缺点了呢？也不是的，在一些特殊场景下，和Native技术结合，能带来更好的性能体验。
比如，在地图渲染的场景，在WebView中嵌入NativeView去渲染，往往可以带来更优的效果。U4内核也实现了混合渲染技术，可以在WebView中嵌入Native对象，并和WebView进行混合渲染，这些技术在手淘和支付宝上已经应用起来，并且推广到了iOS端。
在特定时期特定场景，Web技术与Native技术融合，是非常推荐的。在衡量这些技术的价值时，我们往往会考虑，
（1）前端是否能通过标准或者标准扩展的方式去使用这些技术
（2）这些技术是否能真正为业务带来更优的体验
需要说明的是，绝大部分场景，Web技术都已经能做得非常好，没有必要为了追求新鲜而硬往Web页面插入一个Native控件，这会让在分享传播的场景增加额外的适配逻辑。
Web技术与Native技术并不是竞争关系，而是互补关系，Web技术可以使用Native技术去优化特定场景的体验，Native技术也可以借鉴Web技术的成果去促进自身的发展。事实上，JS引擎和排版渲染引擎也是很多Native技术的核心组成部分，而这些一直都在跟随着Web引擎的演进而发展。
业务技术选型
我们在进行业务技术选型的时候，是选Web技术还是Native技术呢，需要考虑什么？
（1）技术安全
技术安全主要是指技术是否可控，是否存在解决不了的问题。可控又包括版权，技术支持，技术团队稳定性，等等。
Web技术天然就是开放共享的，有全世界成千上万的科学家在保驾护航，也有庞大的开源社区，还有世界*公司的倾力支持。这些都决定了Web技术的根基是非常牢固的，不会因为某些公司策略或团队变动而产生巨大影响。
那么，有没有短时间内难以解决的问题呢？这还真有，往往是因为标准落地较慢，WebView碎片化，WebView本身存在BUG，等等。但是，在阿里体系，这些其实都不是大问题，U4内核已经基本覆盖了阿里系的app，能较好解决WebView碎片化问题，也能较好的解决业务遇到的任何疑难问题。
（2）开发成本
通常业务会有非常多的跨端或分享传播需求，比如，页面要跑在支付宝，手淘，钉钉，Android端，iOS端，Linux，Windows，新零售终端，曲面屏，等等，这种场景Web技术的优势就非常明显了。我们无法预见将来会出现什么端，但我们可以预见Web技术能较好的适应所有的端，根源在于Web技术是W3C标准技术，这就是标准的力量。
那么，在各个端是否存在要适配多个WebView的问题呢？这必然是存在的，但问题可能越来越小。2018.12 微软宣布全面转向使用Chromium Blink内核，他们的考虑是，Blink内核发展非常迅速，领先标准很多，如果要快速跟进则成本很大，如果不跟进则会造成Web的分裂，综合衡量决定转向使用Blink内核。这其实是一个风向标，Web引擎正在趋向于统一，Web引擎不想再分裂下去，期望进一步降低Web开发的成本。国内也是类似，国内也在快速跟进高版本Blink内核，绝大部分app里的Blink内核版本都超过了M50，极大的保证了Web新特性在各个端的统一。
（3）性能体验
性能体验问题，前面已经有比较多的讨论，总结起来就是Web性能体验已经能完全媲美Native技术。即使一些场景下还有短板，也能使用混合渲染技术去解决。
（4）可维护性
可维护性一般有两个方面，长期的维护成本和解决问题的成本。长期的维护成本，其实有很多方面，技术的根基是否牢固，是否有推倒重来的风险，是否存在被禁用的风险。解决问题成本，包括在互联网上是否能快速搜索到解决方案，或者提供技术的团队是否能及时提供有效的帮助。
Native动态技术其实存在一定的风险，iOS很可能会禁用一些非标准的Native动态技术，Facebook可能会修改React的授权协议。如果在一些关键的时间节点，Native技术的版本无法上线，就影响比较大了。
（5）个人与团队成长
这个就见仁见智了，不同的团队可能有不同的判断。如果从整个集团的角度去考虑，就需要综合衡量所有的点了。
在进行业务选型时，我们应该从业务本身去考虑，从整个集团去考虑，选择更加符合业务发展的技术方案。可能在不同的时期不同的场景，同一个业务有不同的业务选型，这也是很正常的。
未来的Web技术
从更长远的方向去看，Web Page会往Web App的方向去发展，浏览器内核也会往操作系统的方向去发展。在将来，很可能浏览器内核就变成了操作系统的外壳，页面通过浏览器内核能够使用越来越多的系统底层基础能力。那个时候的Web可能就是现在的Native了，只不过它还继续保持着Web跨平台容易传播等天然的优点。
这样演进的优点是什么？Web页面能具备Native应用的性能体验，而且不需要下载安装包，能跑在所有的平台，能快速分享传播，多么美好的事情！开发者只需遵循W3C标准去开发页面，就能跑在所有平台所有客户端，不需要关心页面是跑在客户端上，还是跑在操作系统上，这就是标准技术的魅力！
无论Web技术如何发展，它必将会继续保持着*平等开放共享的互联网精神，这些才是Web的精髓。