Vue Conf 2022 笔记
“库和框架什么区别？” 框架需要一些最佳实践和配套工具，库则是拿来就用。Vue一开始就只是一个库 第一阶段：Library Phase(Pre 1.0) 自己写了介绍和博客，然后在github上第一周400个星
当时各种IE的支持还是有需求的。
我们现在也不那么套词了（指类似MVVM这样的说法），因为觉得没必要把现代的设计套上一个什么词 做成类似jQuery的“一把梭”也是Vue能流行起来的原因之一
这里的“耦合”指的是都绑定在this上。一开始其实完全没考虑逻辑复用的问题…
petite-vue可以认为是对1.0的一种现代工程化的再现，如果对工程化要求不是那么严格，希望轻量一点的，可以试试 第二阶段就进入框架阶段了 （这里画面卡了）
1.0的设计重点，是稳定模板和作用域的设计；
另一个重点是，把Vue的定位，扩展到了SPA等
第三阶段，进入了通用框架阶段 这个时候yyx也是离职，全职开始开发
（这里少一张图）
从2.0开始才真正有了编译的概念（不过也只有一个策略），当时和react的渲染是类似的 现在回头看，Flow是选错了 之前的类型定义都是手动维护，而非自动生成 当时一个比较有意义的ssr的demo就是vue-hackernews2.0
还有如何在同构的架构中使用路由等等 还启发了一些上层框架，比如next.js
通过webpack打包生成的manifest，分析打包出来的东西用到哪些源码，来实现预加载； 在静态分析直接做成字符串，跳过生成virtual dom，节省一部分开销，但是限于当时编译器的能力，只做了部分优化 后来大部分时间花在开发工具上，现在大家认识的vue-cli是基于webpack并提供各种集成的 其实工具类的东西是跨框架，而非绑定的，所以当时想多做一些东西，但前端的工具进化是相当快的，维护成本是很高的（这里可以看看下面vite是什么策略——借助更多的开源力量）
然后就来到了第四阶段
以前编译器对运行时没有概念，运行时对编译器也一样，分的比较开，但是浪费了可优化的空间。 编译器和运行时都是框架的一部分，编译器应该提供更多信息给运行时，而运行时应该知道。 react是唯一一个没走这个方向的，但react现在最终也是往这个方向走了
18~19年都在调研
后来发现IE11的支持要求越来越低了，正好去掉。 之前Vue2的源码里用Flow对类型声明成本高、类型支持也不太好。Vue从中小型项目向大项目、大企业转，也遇到很多挑战。 当时开发也是和ES标准的进化也有关系，因为一些Api的设计，可能和一些提案有关系，所以最后选择函数组合的api，不过在高发布的时候，其还是体现了许多缺陷
没有vm的开销了，只要使用模板写，所有能转静态字符串的都转了。后来看到了Vite的潜力，所以修改了计划投入了一部分
跨框架的工具，从而也有更活跃的社区，也有了自己的一个社区，可以借助更多的力量来维护（比如各种测试工具），收益也会让Vue的体验变得更好。
3.1是为了让vue2的用户更容易往vue3迁移 现在可以看看作为一个框架，为什么花了这么多时间才把生态建立起来
在浏览器是vm，在服务端是字符串
Vue2还是很稳定的，所以并不是一定要升级
把一些实验特性变成稳定特性 懒水合/按需水合
新的编译策略
Q&A
- Vite现在的发展方向还是比较确定的，其更多的价值在于“上层框架共享工具链”，目前的下载量增加的非常夸张，所以趋势还是很好的
- 开源项目之间互相借鉴是很常见的，可以更关注设计意图，Vue组合式api利用了js的闭包，符合单次调用的直觉。
- vite现在已经用了很多原生的能力，但是如果使用时对开发者要求太高，也会影响开源项目的推广。比如前端熟悉node，搞vite就不难，但是如果改成rust来写，就不一样了
- Vue下一个大版本的规划：暂时没有。接下来会在不影响用户的使用体验的基础上去优化，而不是2到3这样破坏式的更新。接下来会类似react引入hooks的过程。（1到2时，第一届vueconf上yyx你也是这么说的）
