尤雨溪大神的live
确实是大神，讲的方向很多，随意哪个方向都是值得深入研究的领域。逻辑清晰有条理，听完之后只会觉得有时候人和人的差距实在是大到无法想象。佩服。
live中给出了很多推荐的链接，要花一些时间去学习、理解相关的知识和内容。
划重点：
- 理论上讲，服务端数据对于前端来说是不可变的，前端不能随意更改服务端数据，如果要更改，必须与服务端确认。所以将服务端数据放到store中是有些多此一举的。
- 技术方案都是先有问题，再有思路，同时伴随着取舍。在选择衡量技术的时候，尽量去思考这个技术背后是在解决什么问题，它做了怎样的取舍。这样一方面可以帮助我们更好的理解和使用这些技术，也为以后哪天你遇到业务中的特殊情况，需要自己做方案的时候打好基础。
- 对于前端框架的学习，理解思想最重要，熟悉源码是为了提升与业务无关的工程化的理解等，对自己写框架、做方案有帮助。
Vue源码学习
组件化
组件分为：
- 纯展示型组件
- 接入型组件container，包含与数据源打交道的逻辑，将数据传给纯展示型组件
- 交互型组件，比如表单组件，强调复用性
- 功能型组件，例如<router-view><transition>，作为一种扩展、抽象机制存在
JSX与模板
JSX在实现功能型组件时是远超与模板的
模板更善于实现纯展示型组件，更容易书写样式
变化侦测和渲染机制
命令式：jQuery，直接通过命令完成功能，会遇到维护性的问题
声明式：声明文档与变量之间的映射关系
Vue采用的是一种混合式的策略，以组件为单位进行响应式的更新，进行virtualDOM的比对。pull是一种暴力的便利比对，进行全局的更新，是粗粒度的，而push是响应式的通知系统哪些数据发生了变化，需要进行更新，是更细粒度的。虽然push更新范围小，会带来性能的提升，但是由于对每一个需要侦测的变量都需要增加观察者，同时响应更新的机制也会带来内存方面的压力。
状态管理
常见的状态管理框架Redux、Mobx， vuex
状态管理的本质：从原事件（source events）映射到状态的迁移，在映射到UI的改变。
（鼠标点击事件→应用状态改变→UI（dom）的改变）
声明式的渲染解决了状态到UI的管理，状态管理解决的是管理事件源映射到状态变化的过程，将映射过程从试图组件中剥离出来，提高可维护性
Redux VS Mobx VS Vuex
范式（paradigm）不同，Redux强调数据不可变，函数式的，reducer是纯函数
Mobx和Vuex是响应式的，数据是可变的，数据可变的副作用是声明式的
本质相同的。
都没有回答如何处理异步。
状态管理如何处理异步
建议使用RXJS来做一层封装处理异步。利用RXJS跳过状态的改变（Redux中的reducer，Vuex中的mutation），利用“流”来管理（需要对RXJS的理解非常高--我就不理解）
状态管理的尴尬
- 组件内部状态的管理，内部状态和全局状态界限不明显。
- 全局状态和服务端数据关系
路由
单页应用的路由，本质上是将url映射到组件树结构的过程
React-Router V4
去中心化的路由，利用组件本身去做路由，将路由与组件结合，用组件生命周期做跳转
Web路由与原生路由
浏览模式的区别：Web路由的跳转需要抛弃跳转之前的状态，而原生路由是由新的页面叠加在旧的页面上，后退时将当前页面拿掉
鼓励Vue社区向原生路由的方向发展
主流的 CSS方案
- 跟 JS 完全解耦，靠预处理器和比如 BEM 这样的规范来保持可维护性，偏传统
- CSS Modules，依然是 CSS，但是通过编译来避免 CSS 类名的全局冲突
- 各类 CSS-in-JS 方案，React 社区为代表，比较激进
- Vue 的单文件组件 CSS，或是 Angular 的组件 CSS（写在装饰器里面），一种比较折中的方案
传统 css 的一些问题
- 作用域 2. Critical CSS（加载首屏需要的CSS文件） 3. Atomic CSS（将类按最小功能拆分） 4. 分发复用 5. 跨平台复用
CSS-IN-JS未必是未来的方向，很多功能都可以通过对CSS的静态编译实现。
构建工具
磨刀不误砍柴工，构建工具就是在磨刀。
浏览器的限制（代码环境）导致了构建工具的必要性。
- 任务的自动化
- 开发体验和效率（新的语言功能，语法糖，hot reload 等等）
- 部署相关的需求
- 编译时优化
gulp/grunt：用的较少了，主要价值在于task runner，用于任务自动化，但是现在npm srcipts可以代替其大部分功能，或者用nodeJS手写脚本完成这部分功能，而且这两者在模块化构建方面基本没有特长
关于部署
由于部署要考虑的问题很复杂（代码的打包合并、本地资源的映射、小尺寸图片的处理等等），导致了webpack配置的复杂，本质上是因为webpack要实现的功能的复杂性
服务端数据通信
GraphQL对复杂关联的数据获取比传统的REST抽象要强，对数据量的优化更精确。使用门款较高， 需要后端的支持
是否要将服务端数据放到store中管理
理论上讲，服务端数据对于前端来说是不可变的，前端不能随意更改服务端数据，如果要更改，必须与服务端确认。
所以将服务端数据放到store中是有些多此一举的。
（但是对于大量的数据是不是存在store中，进行增量的修改对性能更有利？）
服务端渲染
跨平台渲染
将渲染过程与DOM节点解耦。
Web Component
Web Component 和类 React、Angular、Vue 组件化技术谁会成为未来？
Web Assembly
类似于JS的汇编语言，适合做一些JS中不适于做的大量的计算、3D动画、挖矿等，但是目前无法与DOM接触，对框架影响有限。
react和Vue的场景
场景区别很小，基本可以互换。决定于团队的习惯、技术水平等
前端框架的学习需要到什么程度
理解思想最重要，熟悉源码是为了提升与业务无关的工程化的理解等，对自己写框架、做方案有帮助。
为什么要用服务端渲染
除了SEO的考虑之外，前端渲染的前提是JS全部加载完成，而服务端直出渲染可以减少用户看到内容的时间，对于某些产品，减少用户1s的等待可能会带来更高的转换率，所以是有必要的。
（对于CRM这种内部工具就无所谓了，让他们等着呗。）