移动前端开发和 Web 前端开发的区别是什么
回顾：前端发展史
阶段一：刀耕火种
十多年前的前端，开发者还在为兼容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编程。
同是UI编程，我们面对的痛点是什么？
传统Web前端技术的技术局限性
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以及宿主应用的能力暴露给上层前端，提高前端页面对更多富交互场景的承载能力。
在这样的大背景下，各种混合开发技术层出不穷，在这里我们简单的把混合式应用的发展定义为三个阶段：
阶段一：JSBridge
在这个阶段，主要还是以WebView为主，并配合JSBridge提供了Naive与JS之间的通信链路，基于这个通信基础，Native可以暴露出一些标准服务API提供给JS调用，同样的JS也可以以此封装一些基础API给Native调用。前端开发者使用传统的JS+HTML+CSS进行页面的开发，并且调用JSBridge API驱动客户端能力。在这个阶段，Apache Cordova是业内的佼佼者，大多互联网企业内部也有自己的JSBridge框架实现，可以说JSBridge次给了前端开发者调用Native的能力。
但是JSBridge方案的主要缺点在于性能方面及高级组件扩展能力缺失，流畅性始终无法与Native媲美。
阶段二：原生UI
虽然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的大规模应用，甚至支撑起了双十一亿级的流量。
阶段三：自绘引擎
什么是自绘引擎？
所谓自绘引擎，就是不依赖操作系统提供的布局、原生组件能力，直接调用GPU或者底层抽象层进行绘制的渲染引擎。
在上一个阶段，前端开发者已经可以使用JS引擎驱动原生UI了，为什么还需要自绘引擎？
React Native/Weex充分将Native的View体系输出到前端体系中，在进行Android/iOS Native View的封装过程中，存在不少难以逾越的障碍。如：难以抹平的双端一致性问题、复杂样式能力难以实现、Layout动画需要执行两次（WeexCore Layout和Android Native本身的Layout）。组件的封装成本随着复杂度增加也越来越高，难以逾越Native View限制提供更细致的W3C标准能力。
2018年Flutter诞生，通过Dart语言构建一套跨平台的开发组件，所有组件基于Skia引擎自绘，在性能上和Native平台的View相媲美，同时解决了上一代架构难以解决的双端一致性等问题。引起大家广泛关注，充分验证了通过绘制构建组件做到Native View媲美的UI渲染引擎的可行性。
但是Flutter本身是缺乏动态更新特性的，社区上也有一些项目在探索Flutter的动态化特性，我们团队内部也在实现面向前端的动态化Flutter引擎：Kraken，与其它方案不同的是Kraken并没有基于Flutter自带的Widgets框架进行扩展，而是从底层扩展了W3C标准的API，这使得它更像一个浏览器，也让Flutter面向Web开发者的使用门槛大大降低。
未来：回归本源
天下大势，分久必合，合久必分。移动前端开发本质上还是终端开发的一种形态，不管容器、框架、语言怎么变，在前端开发者中只有W3C的标准是永远不变的。笔者认为，随着Web的发展，在解决一系列性能、体验问题之后，浏览器技术会成为更通用的UI编程标准。
PWA
早先年，Google就已经在这一领域内努力，推出了PWA(Progress Web Application)的概念。
PWA通过在移动端浏览器提供标准化框架，在Web App中实现和Native App接近的用户体验。它的特性其实是一系列W3C标准和私有标准集合，简单的说PWA支持：
离线加载：通过Service Worker等提供的缓存机制，允许用户在断网或者弱网的情况下直接读取离线资源。
后台驻留进程：正常情况下，浏览器的页面关闭后它的整个生命周期就结束了，内存也得到了释放。Service Worker允许页面在关闭的情况下继续运行，这了类似于离线缓存、主动推送等。
消息通知：允许Web开发者实现类似App的主动推送机制。
其它移动App的功能特性，如直接保存图标到桌面，允许用户像正常使用App一样打开PWA应用；可以隐藏UI中的默认浏览器元素，让Web内容全屏展示，从视觉上看让Web应用更像一个原生应用，有时候你根本无法分辨到底是Web应用还是原生应用。
PHA
当然在标准能力不完善，业务又需要定制化能力的当下，混合式应用还会继续发展。
PHA(Progress Hybird Application)的概念应用而生，PHA是一种渐进式的混合应用增强策略，提供端测的辅助能力，提升WebView的渲染性能与体验。广义地说，当下比较火的小程序、快应用都是PHA的一种实现。
在淘系内部，我们也在实现一套轻量级的PHA方案，并且在大促中也取得了不错的效果，我想后面单独出一篇关于PHA的文章来阐述。
关于未来，随着技术方案的多样化、以及端边界的扩展，我们认为最重要的就是效率与性能的问题。
基于大数据的机器学习能力，移动端上会拥有更高效的UI编排能力，最终能让UI渲染实现实时个性化。
基于最近比较热的WebAssembly能力，让浏览器突破JavaScript的限制，能拥有更大的想象空间。
