<Home /><About />

React and Vue in 2024

全文纯属个人观点，words are my own.
 
近期又上演了一场 React/Vue的争论，我也借这个时间点大概聊一聊自己对于React以及前端目前渲染类库的理解。
 
notion image
 
notion image

问题陈述

前端的框架/库要解决核心问题就是页面渲染，很多框架/库在解决渲染问题时，主要采用：
  1. 自建DSL + 编译时 + 运行时 （Vue, React)
  1. 自建DSL + 编译时 (Svelte)
  1. 纯运行时 (jQuery)
 
React的解决方案是纯运行时解决方案。JSX的compile时编译不对运行时代码做任何优化，不属于任何性能优化的范畴。
 
以上3点是目前主流的前端渲染库/框架的解决方案。但是无非是想要做到
  1. 相对优雅的DX
  1. 检测数据变更 → 【differ + 更新】或 【更新 + differ】
 
React在设想整个UI界面时，是完全围绕view = fn(data)的纯函数核心思想。
此纯函数核心思想即：
  1. 一份数据，对应一份ui
  1. 任何副作用需标明是副作用
同时再通过一些“技术手段”保证每次data的变更后，fn可以持续稳定一致的执行，不断的differ，最终影响到ui的变更。可以理解为优化手段完全控制在运行时。
 
在这种前提下，React需要给出闭包的各种hack解法，例如：
  1. JavaScript闭包带来的各类快照
  1. 状态记忆和清理
  1. 各类快照的对比
 
这也就带来了很多新手会碰到的DX问题，例如useRef, useState的选择，useEffect的概念和onMount概念的区别等等，甚至加入了strict mode，在dev模式下强制执行两遍effect来保证用户代码的正确运作。
 
所以其实对于React来说，每一步设计的加入都是相当的困难，因为目前的DX体验已经完全走下坡路了。在设计API时，不仅要考虑到开发者体验（写法，理解能力），还要为了保证内部很多的hack手段的正常工作。
 
React在官网上花了无数的笔墨去解释很多hook的内部到底是怎么工作，用户应该如何编写去让这些hook正确运作，例如
  • 使用 Effect 同步
  • 你可能不需要 Effect
  • ref 和 state 的不同之处
  • 保持组件纯粹
官方的一些compile时的优化想法
  • https://react.dev/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler
用一些新的hook来解决已有的DX问题：
  • https://react.dev/reference/react/use
  • https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md
 
React的hook理念在推出之初绝对是相当革新的设计，但是目前React在这条路上已经没法回头了🥺
 
我觉得就搞搞React Server Component挺好的，狗头保命（
notion image