©2020-2024 ioDraw All rights reserved,
Privacy Policy
好处
相比 vue2 更快 更小，开发时搭配 vite 热编译瞬间完成。
组合式API 搭配 es6 的语法编写代码很舒适。
坏处
setup 内编写代码时，每个页面需要 Import
大量的依赖例如：ref、reactive、getCurrentInstance、useStore、watch、computed 、onMounted
这些频繁使用的必须函数。引起不适，其次语法也不够简洁明了。
读写 ref 的操作比普通值的更冗余，因为需要访问 .value，而在模板中又不需要加 .value，这无疑造成了一定程度的混乱和割裂感。
你会在 setup 内发现许多这样的语法：const { xxx } = importFn1()，const xxx =
importFn2({xxx})，对一个代码洁癖的人很不友好。
贬低全局 mixin ，支持 import 显式的从 js 文件中引入 任何状态 或 从合成函数返回的方法来解决
“命名冲突和隐式依赖”。理由是：“mixin模式表面上看起来很安全。然而，通过合并对象来共享代码，由于它给代码增加了脆弱性，并且掩盖了推理功能的能力，因此成为一种反模式。”
可是被 “命名冲突和隐式依赖” 困住的人不是因为自己不够细心，代码设计没规范好吗？mixin + store 非常舒适，频繁的 import 很粗鲁。
vue3 失去了 vue2 生态中大量的轮子，对开发者造成的负担可想而知。
框架主体思想和 vue2 相悖。
体验
快、混乱、割裂、粗鲁。
现代项目开发不应该只注重在 快、极客 的编程方式上面。毕竟独木难支，更应该注重团队的协作开发。而 vue3
在语法表现力上甚至退步了，平白增多了成员间代码理解的时间成本。
vue3 的思想体现就是大量的 import 和 构建函数，import 让你在各个分散的文件之间反复横跳，到处出现的构建函数让人心烦意乱。
人的前额叶注定同一时间只能专注思考一件事情，思维过多的跳跃会让人大脑混乱、效率低下。
维护这种代码，只会感到烦躁，更别提进入心流状态了。
以上都是个人拙见，喜欢升级 vue3 的人不少，不过也有很多是跟风。
工程化之前的田园时代，html + css + javascript 最多再加个 jqeury，埋头深耕就够了。
前端工程化之后各种框架雨后春笋般出现，它们都建立在 javascript 上面，但思想和过程却大不相同。框架都很好，只是快速的迭代让人感到焦虑。
环境里大多数人都吹鼓、崇拜新的框架，其实自己也只是粗略的了解使用。但说出去的话却让其他开发者产生了危机感：“他们都会了，我不会就会被淘汰”，而后连
javascript 都没有精通这就开始了框架内卷。
说不定你刚熟练了一个框架，转眼它就出了下个版本，或者被另一个新出的框架淘汰，之前所做的学习了解都成了无用功。框架的效率缩短了工期方便了老板，学习的成本和迭代的焦虑几何增长，这都让程序员承担了。每天上班时间还是
8 小时，薪水也没有变化，职位要求的技术栈却日新月异。
很久没有体会过田园时代编写原生轮子的满足感了，那种轮子永远可以使用。
引用一下同行的感想：
一开始我们团队求新，也是采用script setup去写。
后面越写越发现不对劲，大部分同事的js基础参差不齐。
放弃option api改用setup
api之后，就出现了“乱停乱放”的现象，事件处理函数，普通函数，响应式变量，普通变量，hook等等到处乱写。反正template模板到script代码，看懂别人的代码很费劲。
然后review的时候发现这样下去吃枣药丸，必须加规范去约束。
等规范制定出来之后，约束着先写什么，再写什么，怎么命名等等，最后发现，这不就是又造了一个option api了么？那干嘛不直接使用vue本身就支持的功能？
于是团队乐呵呵地回退到option api了。
但setup也不是一点用都没有。
举个例子，以前vue2的时候如果开一个定时器，会直接这样写：this.timeout=setTimeout();
然后这个this.timeout是运行时直接挂在组件实例上，在无论是jsdoc还是ts都是检测不到的。
有了setup之后，你可以在setup函数的返回值里面声明这个变量，然后用jsdoc或者ts标注类型。这样无论在组件的什么地方，通过this都可以检测到这个变量的存在。
另外，在一些与第三方库集成的场景，比如集成一个monaco
editor，这些库往往还是会返回一个对象，让你通过这个对象去操作它，这时候你就可以把这个对象挂在setup里而不是data里面，可以有效避免第三方库操作对象内部更新导致你页面刷新。