RV大战之2024年我还想写React
全文纯属个人观点，words are my own.
大家好，我是HopHop。
近期又上演了一场 React/Vue 大战，我也借这个时间点大概聊一聊自己对于React以及前端目前渲染类库的理解。
问题陈述
前端的框架/库要解决核心问题就是页面渲染，很多框架/库在解决渲染问题时，主要采用：
- 自建DSL + 编译时 + 运行时 （Vue, React)
- 自建DSL + 编译时 (Svelte)
- 纯运行时 (jQuery)
React的解决方案是纯运行时解决方案。JSX的compile时编译不对运行时代码做任何优化，不属于任何性能优化的范畴。
以上3点是目前主流的前端渲染库/框架的解决方案。但是无非是想要做到
- 相对优雅的DX
- 检测数据变更 → 【differ + 更新】或 【更新 + differ】
React在设想整个UI界面时，是完全围绕view = fn(data)的纯函数核心思想。
此纯函数核心思想即：
- 一份数据，对应一份UI
- 任何副作用需标明是副作用
同时再通过一些“技术手段”保证每次data的变更后，fn可以持续稳定一致的执行，不断的differ，最终影响到ui的变更。可以理解为优化手段完全控制在运行时。
在这种前提下，React需要给出闭包的各种hack解法，例如：
- JavaScript闭包带来的各类快照
- 状态记忆和清理
- 各类快照的对比
这也就带来了很多新手会碰到的DX问题，例如useRef, useState的选择，useEffect的概念和onMount概念的区别等等，甚至加入了strict mode，在dev模式下强制执行两遍effect来保证用户代码的正确运作。
所以其实对于React来说，每一步设计的加入都是相当的困难，因为目前的DX体验已经完全走下坡路了。在设计API时，不仅要考虑到开发者体验（写法，理解能力），还要为了保证内部很多的hack手段的正常工作。
React在官网上花了无数的笔墨去解释很多hook的内部到底是怎么工作，用户应该如何编写去让这些hook正确运作，例如
官方的一些compile时的优化想法
用一些新的hook来解决已有的DX问题：
React的hook理念在推出之初绝对是相当革新的设计，但是目前React在这条路上已经没法回头了🥺
我觉得就搞搞React Server Component挺好的，狗头保命（
转载自:https://juejin.cn/post/7321910136616108070