尤雨溪-不吹不黑聊聊前端框架

Posted 2021-04-05 挨踢屌丝

本文是自己在知乎购买的live，将尤大的语音整理成文本，算是发福利吧。如果这样不被允许，只要有人通知我，我一定删除。

如何根据不同的场景需求去选择工具？

基于经验和工具本身的理解

组件：

1 主流框架都已经将组件作为一个抽象单元（*.vue文件）

2 最早的前端以页面为单位，应用的出现使得模块切分出现需求

3 React的贡献就是揭示了组件可以是一个函数

4 一个组件是一个函数，一个组件可以调用其他函数，组件可以调用组件，在这个过程中vdom在被操作，从而更新的时候页面发生了变化

5 vue组件中的script是受限作用域的，包括模板中的事件绑定的执行函数也是受限的，而不是全局的；全局的函数你根本不知道这个函数会调用哪里的变量，这会造成维护性的问题

组件分为四类：

1 纯展示型的组件

2 接入型组件：会跟数据层的service打交道，container

3 交互型组件：对表单组件的封装和加强：element，强调复用

4 功能型组件：路由<router-view>，作为一种扩展抽象机制存在，jsx实现

jsx：本质上就是javascript

变化侦测和渲染机制：

声明式：

1 直接描述数据跟dom结构之间的映射关系，这样就不用手动的去做更新操作 ；

2 view = render（state）；

3 view的目标也是编译成渲染函数的；

4 输入state，输出dom

5 输入变了输出就变了，这样就不用顾虑输入到输出之间发生了什么事情。

6 底层实现可以是virtual dom，也可以是细粒度的绑定，比如vue1

7 不同的底层实现在不同的场景下更新的效率不同，本质相同

8 Vue服务端渲染指南：https://ssr.vuejs.org/

9 跨平台渲染：跨平台渲染的本质是在设计框架的时候，让框架的渲染机制跟dom解耦；有多种实现方式，并不一定要是virtual dom；每个平台都有一个渲染引擎并暴露节点操作的API，只要将框架的运行时对接到渲染引擎的API即可达到跨平台渲染；三大主流框架都做到了跟具体的底层渲染解耦，但是比较的时候要考虑开发体验、性能、稳定。要分开比较。

变化侦测：

1 尤雨溪：巴黎演讲的PPT https://docs.google.com/presentation/d/1_BlJxudppfKmAtfbNIcqNwzrC5vLrR_h1e09apcpdNY/edit?usp=sharing

百度云：https://pan.baidu.com/s/1KeM3iV4O7DgBacZ6BST0iQ

2 变化侦测主要包括：push和pull两种

3 pull ：

1）Angular1,2 脏检查；

2）系统需要给出一个信号说数据可能变了，这个时候系统进行一次比较暴力的比对；

3）React里面是vdom的diff；在Angular里面是脏检查的整个流程；之所以这么做是因为我们根本就不知道哪些数据变了；

4）能够这么做是因为JavaScript目前足够快；

5）最粗粒度的更新

6）在大型应用里，我们需要帮助这个系统来减少一些无用功，在组件树中跳过一部分来避免暴力比对

4 push：

1）Vue的响应式的数据；

2）数据变动机制使得数据变了以后我们立刻就会知道数据变了；

3）一定程度上知道是哪些数据变了，从而可以进行更细粒度的更新；

4）代价就是每一个绑定都有一个watcher，从而带来相应内存的开销，依赖追踪的开销；

5）Vue2里面选择了一个中等粒度的开销：组件级别是push（当数据变了的时候我们可以知道哪个组件变了）；每一个组件内部是一个响应式的watcher，使用vdom比对；

状态管理：

1 最早来自于Flux。Flux 初期混乱，后来合流到Redux（2015年），再后来出现Mobx（几乎和Vue的Vuex一样）

2 Vuex一定程度受Redux影响

3 状态管理的本质：从源事件(source event)映射到状态的改变，再映射到UI的变化。通俗的说就是有人按了个按钮，触发了鼠标点击事件，映射到了一次应用状态的改变，应用状态的改变最后成为UI dom的改变。

4 状态管理的本质2：将事件源到状态改变的映射过程从视图组件中剥离出来，如何组织这部分代码来提高可维护性。

5 Vue可以当做redux用，也可以当做mobx用很难说谁比谁好，更多的是相似，也都有相同的问题。这些方案其实都没有回答如何处理异步。各种方案都有，写出来的代码也几乎完全不同。大多都是杀鸡用牛刀。典型的rest API是不存在比较复杂的异步的（比如服务端推送、实时）。

6 状态管理的问题：组件的局部状态和全局状态如何区分；有些状态需要被多个组件公用，所以使全局状态；有些状态只被一个组件使用；全局状态和局部状态并没有一个明显的区分

路由：

1 只有大型的单页应用才会遇到路由的问题。

2 最早是ember使用路由，很重的一个框架，而且是侵入式的。写应用要先写路由。

3 Vue和React出现之后，发现路由和组件可以解耦，而且可以更灵活

4 路由本质上是把一个URL映射到组件树结构的一个过程

5 重定向、别名、晚加载、跳转（需要提供各种钩子）

6 去中心化的路由有利也有弊，不利于跳转，不利于统一管理，路由和组件耦合

7 push做的跳转回丢弃当前页面的状态

CSS：

主流的 CSS 方案

- 跟 JS 完全解耦，靠预处理器和比如 BEM 这样的规范来保持可维护性，偏传统

- CSS Modules，依然是 CSS，但是通过编译来避免 CSS 类名的全局冲突

- 各类 CSS-in-JS 方案，React 社区为代表，比较激进

- Vue 的单文件组件 CSS，或是 Angular 的组件 CSS（写在装饰器里面），一种比较折中的方案

传统 css 的一些问题：

1. 作用域：Vue中css scoped，其他框架也都有解决方案

2. Critical CSS：首屏风格。服务端渲染如果没有在首页发送给用户之前就加载所有CSS，会导致用户先看到一个没有CSS的首页，看起来很奇怪；如果在首屏发送给用户之前加载所有CSS又会导致性能问题；CSS in JS做这个是比较简单的，可以灵活控制加载那些CSS

3. Atomic CSS

4. 分发复用：由于CSS in JavaScript是JavaScript，所以可以发包引用import

5. 跨平台复用

6 整体上对CSS in JavaScript持有保留态度，因为没有什么是必须要这么做的，其他方案更简单

构建工具：

1 之所以会出现构建工具，是因为web前端平台能力变的越来越强；需求越来越复杂，要求越来越高；

2 构建工具解决的其实是几方面的问题：

- 任务的自动化

- 开发体验和效率（新的语言功能，语法糖，hot reload 等等）

- 部署相关的需求

- 编译时优化

3 前端代码最终要跑在浏览器里面，一些新的语法特性都必须依赖构建来做一个翻译；我们对最终代码跑的环境没有控制权，所以我们只能在构建这一步去下功夫；这种转关规则也都有现成的各种开源工具；

4 极大的提高了开发效率

5 webpack复杂是因为它要解决的问题本身就复杂，比如请求合并，静态资源缓存等等设计到访问效率的场景：https://www.zhihu.com/question/20790576

但是webpack会让你在配置上花一次时间，后面可以反复受益。

6 编译优化是这方面主要的解决方案

服务端数据通信：

1 长久以来，这部分都是围绕restful api ，对于传统的CRUD的应用来说，这种是比较简单的情况。

2 复杂的情况： 数据之间有很大的关联性；实时推送、同步需求。传统的基于REST API的抽象遇到这种场景会比较痛苦。

3 实时的方案有metia、单纯做数据层的有filebase、实时数据库有rthinkdb、jxjs最适合处理事件流、数据关联性很强的场景有基于图的API解决方案