十多年前的前端，开发者还在为兼容 IE6 而头疼，框架上 jQuery 是老大，有追求的前端开发可能会使用 Zepto.js 以减少网页体积。这个时候，前端页面主要还是以 PC 为主，这个时候根本没有移动前端的概念，在小小的手机屏幕上流量的页面则是以纯文本为主。在 2011 ~ 2014 年之间的历史阶段里，模块化的思路占为主导。当时为了进行 Assets 资源加载器的设计，就制定了模块化的协议规范。当时比较流行的模块化协议就是 AMD（RequireJS）、CMD（Seajs 为代表）、KMD（Kissy 为代表）。在淘宝、天猫，Kissy 应用的很火，所以 KMD 主导天下；在支付宝及外部社区，Seajs 应用的很火，所以 CMD 主导天下，玉伯大大的名气和威望也在前端圈里特别高；

而 AMD 在国外比较流行，但渐渐也被后来出现的 CommonJS 规范削弱了气势。随着 3G、4G 的发展和 iOS 和 Android 手机在市场的普及量大增，PC 业务主战场也逐渐过渡到移动端。前端的思维模式由 PC 转向了移动端，并向 App 的用户体验看齐。移动端的 HTML5 协议支持不完善，前端的生产配套不全，Android 的屏幕碎片化，所以那个时候的前端开发移动端页面适配的痛苦要远远超过 PC 时代。在前端社区，Angular、React、Vue、RN （React Native） 这样的 MV* 框架一个接着一个出现，让前端接受了数据驱动思想的洗礼之外，还借助 RN 完成了移动端的体验升级，包括后来的 Weex、Flutter。

在这个阶段，前端开始有了终端的底层架构组，开始构思前端页面在移动终端上的加载性能和用户体验表现。在阿里巴巴内部，为了解决多端复用的问题，Rax 借助 VDOM 打通 WebView 和 Weex 两端，一套代码跑天下。随着初代 iPhone 的发布，大屏幕手机逐渐变成了主流，移动端的需求开始爆发。在淘宝天猫，每年双十一的移动端成交额逐年攀升，并逐渐占领绝 对领 先地位。前端的领域也随着这种趋势逐渐细分，按照场景可以简单分为移动(无线)前端开发和中后台前端开发。移动前端开发面向的是消费者端的 Web 与 轻 App 业务场景，在这个场景下，淘系经过多年的营销活动沉淀，逐渐形成了移动端独特的、轻量级的解决方案，以及模块维度的、面向运营的页面搭建系统。

中后台前端则是面向企业 ERP、CRM 、OA 等偏后的业务场景，如商家后台等系统。在这个场景下，借助飞冰、Fusion Design 等中后台物料，形成可视化的中后台搭建解决方案，为业务的前端、开发或产品角色提供一站式中后台生产解决方案。移动客户端开发和前端开发是两条没有交集的平行线，但现在我们越来越拥抱两者的合作产物：混合式(Hybird)应用开发，或者用最近比较火的一个概念 -- 大前端技术。从技术的表现形式思考，本质上客户端开发与前端开发都是终端技术，它的特点是直接面向用户 UI 编程。随着 iOS + Android 确立了移动操作系统的统治地位，前端开发者也在寻找使用操作系统提供的能力进行业务开发的模式。

Web 的开发方式远比 iOS 和 Android 更加方便和高效，Web 上层出不穷的各种库和框架也远比 Android 和 iOS 的各种库和框架方便的多。Web 上我们可以方便的使用各种前端框架，及时预览效果（想想大型 Android/iOS 工程的编译时间）。从阿里巴巴的角度来看，随着中台化的理念逐渐被接受：业务需要追求快速发展，前台的 UI 和需求会随着商业决策快速迭代，前端和客户端不同的岗位也形成了分工化的研发模式。前端向上，前置作为业务方的唯 一接口，逐渐演变为大前端的业务层。在这一层，它的职责是负责定义规范，通过框架规范业务的开发过程，同时封装统一的解决方案和工程化能力，将重复的工作抽离。客户端向下扎，解耦业务需求，转为大前端的架构层，给上层的业务开发者提供能力支持。

通过将客户端的系统级 API 以及宿主应用的能力暴露给上层前端，提高前端页面对更多富交互场景的承载能力。