在前端社区，Angular、React、Vue、RN （React Native） 这样的 MV* 框架一个接着一个出现，让前端接受了数据驱动思想的洗礼之外，还借助 RN 完成了移动端的体验升级，包括后来的 Weex、Flutter。

在这个阶段，前端开始有了终端的底层架构组，开始构思前端页面在移动终端上的加载性能和用户体验表现。在阿里巴巴内部，为了解决多端复用的问题，Rax 借助 VDOM 打通 WebView 和 Weex 两端，一套代码跑天下。

随着初代 iPhone 的发布，大屏幕手机逐渐变成了主流，移动端的需求开始爆发。在淘宝天猫，每年双十一的移动端成交额逐年攀升，并逐渐占领绝对领先地位。前端的领域也随着这种趋势逐渐细分，按照场景可以简单分为移动(无线)前端开发和中后台前端开发。

移动前端开发面向的是消费者端的 Web 与 轻 App 业务场景，在这个场景下，淘系经过多年的营销活动沉淀，逐渐形成了移动端独特的、轻量级的解决方案，以及模块维度的、面向运营的页面搭建系统。

中后台前端则是面向企业 ERP、CRM 、OA 等偏后的业务场景，如商家后台等系统。在这个场景下，借助飞冰、Fusion Design 等中后台物料，形成可视化的中后台搭建解决方案，为业务的前端、开发或产品角色提供一站式中后台生产解决方案。

曾几何时，移动客户端开发和前端开发是两条没有交集的平行线，但现在我们越来越拥抱两者的合作产物：混合式(Hybird)应用开发，或者用最近比较火的一个概念 -- 大前端技术。

从技术的表现形式思考，本质上客户端开发与前端开发都是终端技术，它的特点是直接面向用户 UI 编程。

1. 资源加载：HTML、JS、CSS、图片等静态资源存放于远端的服务器，需要动态的异步拉取，再拉取数据进行展示，初始化效率上比 Native 慢的多
2. 渲染机制：在浏览器的设计中，JS 的执行和页面的布局、Paint 都在同一个主线程，无法并行化，再加上 JS 的性能赶不上 AOT 语言，执行复杂逻辑时导致的卡顿通常会阻塞 UI，再加上冗长的渲染管线，导致浏览器的渲染体验在等量对比 Native 时并不占优势。
3. 页面切换：在浏览器中并不存在路由的概念，这导致页面间的切换体验完全依赖于浏览器 Shell 提供的能力，在页面切换的时候会反复加载。当然前端社区中也出现了单页面应用的概念，但是多个页面的资源也显著增加了 JSBundle 的体积，也使页面的开发更加复杂化了。
4. API 能力：浏览器的安全机制是基于同源策略的沙箱机制，这套沙箱机制阻止了前端开发者使用原生系统能力，你只能使用 W3C 标准定义的功能，而且考虑到终端碎片化的问题，这些接口往往不能直接使用。这在 PC 端的场景中是没有什么问题的，但是在移动端则相反，开发者希望有能力调用系统接口实现一些更富交互的场景。
5. 交互性能：浏览器的实时交互性能体验差，在复杂交互场景中大规模的重排限制了 UI 帧率，这种限制在中低端移动设备中尤为严重。
6. 脚本语言，动态解析执行
   JS 是一门 JIT 语言，也就是需要动态解析执行，对比预先编译机器码的 AOT 语言的执行性能就差得多了。

1. 动态性：客户端开发通常是有固定的版本发布计划，而且受制于 Apple 的 App Store 审核规则，版本发布的不确定性还会受到政策影响，Android 在国内的渠道众多，每次发版都要反复检查渠道，一旦发现线上问题需要依赖再次发版，容错成本非常高，这也大大增加了对业务的局限性。
2. 开发成本：客户端的开发成本高，然而生态还不如 Web 丰富，npm 社区的几万开源包，加上更活跃的开发者社区，导致对企业来讲客户端的研发成本是高于 Web 开发的。
3. 跨端一致性：传统客户端开发一套业务，是需要实现 Android iOS 两套代码的，而且由于 Android 和 iOS 的操作系统能力差异，同样的需求往往会用不同的视觉和交互来实现，这也导致了业务成本居高不下。

随着 iOS Android 确立了移动操作系统的统治地位，前端开发者也在寻找使用操作系统提供的能力进行业务开发的模式。Web 的开发方式远比 iOS 和 Android 更加方便和高效，Web 上层出不穷的各种库和框架也远比 Android 和 iOS 的各种库和框架方便的多。Web 上我们可以方便的使用各种前端框架，及时预览效果（想想大型 Android/iOS 工程的编译时间）。

从阿里巴巴的角度来看，随着中台化的理念逐渐被接受：业务需要追求快速发展，前台的 UI 和需求会随着商业决策快速迭代，前端和客户端不同的岗位也形成了分工化的研发模式。

前端向上，前置作为业务方的唯一接口，逐渐演变为大前端的业务层。在这一层，它的职责是负责定义规范，通过框架规范业务的开发过程，同时封装统一的解决方案和工程化能力，将重复的工作抽离。

客户端向下扎，解耦业务需求，转为大前端的架构层，给上层的业务开发者提供能力支持。通过将客户端的系统级 API 以及宿主应用的能力暴露给上层前端，提高前端页面对更多富交互场景的承载能力。

在这样的大背景下，各种混合开发技术层出不穷，在这里我们简单的把混合式应用的发展定义为三个阶段：

在这个阶段，主要还是以 WebView 为主，并配合 JSBridge 提供了 Naive 与 JS 之间的通信链路，基于这个通信基础，Native可以暴露出一些标准服务 API 提供给 JS 调用，同样的 JS 也可以以此封装一些基础API给 Native 调用。前端开发者使用传统的 JS HTML CSS 进行页面的开发，并且调用 JSBridge API 驱动客户端能力。在这个阶段，Apache Cordova 是业内的佼佼者，大多互联网公司内部也有自己的 JSBridge 框架实现，可以说 JSBridge 第一次给了前端开发者调用 Native 的能力。

但是 JSBridge 方案的主要缺点在于性能方面及高级组件扩展能力缺失，流畅性始终无法与 Native 媲美。

虽然 Web 的动态性和高效的开发效率，是原生开发望尘莫及的，但是浏览器技术的瓶颈也非常明显：

1. W3C 作为开放的技术标准，历史悠久，包袱多，显著拖慢了浏览器的性能。
2. WebView 渲染引擎设计的上的缺陷，渲染流水线非常长，导致浏览器对合成器动画和非合成器动画区别对待，非合成动画性能不好。
3. 单线程模型，无法发挥现代硬件架构特别是 ARM 架构多核心的性能。
4. 异步光栅化的设计，在进行长列表滚动时，不可避免出现白屏的现象。

有没有一种两全其美的方式?

React Native/Weex 的出现给前端开发者带来了一道曙光。

React Native/Weex 利用 JS 引擎来调用 Native 端的组件，从而实现相应的功能。React Native 和 Weex 都允许前端开发者使用 JS 进行业务逻辑开发，使用 VDOM 来描述文档结构，并配合 CSS 的子集来定制样式，样式和模板分离。

Weex 体系中， JS 的执行在 JS Thread，Layout 执行在独立的 Layout Thread ，渲染执行在系统的 MainThread ，三个线程相互独立，并行执行。

在 WebView 的体系中 JS 的执行、 Layout 、 Paint 都在 MainThread ，相互影响，在进行复杂任务时会导致界面卡顿。

这种方案的优势在于最大化的复用前端的生态和 Native 的生态体系。

在阿里巴巴，Weex 的大规模应用，甚至支撑起了双十一亿级的流量。