前端晋升ppt_【PPT】快手前端架构师分享：前端发展史

原标题：【PPT】快手前端架构师分享：前端发展史

2019年8月28-29日在台北国际会议中心举办ModernWeb2019上，由快手前端架构师@俞天翔分享《从网页到应用 - 所经历的前端发展史》。本PPT由@俞天翔授权分享。

@俞天翔,目前就职于快手，负责快手游戏直播前端团队；曾就职于百度，汽车之家负责广告投放系统相关的前端开发工作，在 2B/2C 的工作领域内都有过不少的积累

本次分享将会通过介绍讲师从业以来所经历的项目，以及在不同项目中的思考、技术选型、发现的问题等角度，来阐述前端发展过程中“变”的部分与“不变”的部分，希望能帮助大家对前端演进与发展，提供更多的思考。分享大纲：

工程化的发展史，从前端到全栈

移动互联网的发展史，从前端到全端

历史发展过程中，我们所能沉淀下来什么

早期Web1.0时期的形态，纯静态展现，前端工作非常简单

针对传统软件工程中MVC编程中前端所处的位置是处于View层中的，早期的MVC主要都是针对后端场景下的，所以当时我们使用的是asp.net

所以大家如果经历过早期的时候，一定绕不过的就是各种jQuery插件，以及最XXXX的XXXX套模板

逐步进入Web 2.0时代，交互上其实会开始有更多的要求

“面向过程的代码”

Backbone.js算是一个在前端MVC尝试的先驱者，当时同时期框架还有类似于ember.js

工程化的雏形，对资源的预处理，以及模块化需求逐渐诞生

SPA以物理层分隔的前后端分离

这个时候我们需要同时关注Model(data)，Dom操作(View)

当时那个时期所诞生的mvvm框架，包括最早期借鉴于微软WPF框架

业务形态导致前端Model其实是弱模式，所以选择使用Service来代替Model做API聚合

前端工程的初具规模

但是这时候的问题在于前后端对于模型的定义是有些不一致的，简单的聚合发现工作量逐渐会变多

贫血的模型好处是：

1、每个贫血对象职责单一，所以模块解藕程度很高，有利于错误的隔离。

2、非常重要的是，这种模型非常适合于软件外包和大规模软件团队的协作。每个编程个体只需要负责单一职责的小对象模块编写，不会互相影响。

大概从07 第一部iPhone发布开始，移动端交互发 翻天覆地的变化，交互形式、新增加的API让前端在这个过程一直处于劣势。

针对当时的场景， 先被提出来的场景，是否可以做混合开发，既能动态化， 能解决Web能 的问题

这时候有想法的会觉得，是否可以直接把Web封装成App

codrdova提供系統功能的封裝，GUI编程还是前端的模式

简单介绍 下cordova的架构模式Java调 Native， 通过插件管 PluginManager 根据service找到具体实现类 Native调 java，主要包括三种 式:loadUrl 、 轮询、反射WebViewCore执 js

因为那个时期的手机内存以及性能普遍偏低，WebView开销相对较 ，中间还涉及内存回收等等问题

从UI分层上来说，介绍 下GUI编程的本质

通过反射拿到Native的API以及UI 法，并针对 同平台进行完全适配，抽象出 的组件层以及API层级

所以这时候其实要简单讲 下Web对于业界的价值在哪

以Weex为 ，介绍 下他的整体架构设计

以Weex为 ，介绍 下他的整体渲染流程

对照之前的UI编程，描述 下Weex相应的部分都是怎么去做的

Flutter的整体架构

JS RCTBridge作为通信，新计划中准备使用 JSI

直接使 绘图层，并 代表的绝对的优势，因为所有的原 控件全部需要重新实现， 能复 现有平台交互习惯。

实际上原来的瓶颈在于JS Bridge的使

所以React Native提出 新的规范

责任编辑：