Angular 之父为什么怼 React ？（下）

区别1：序列化方式

最大的区别体现在「序列化数据」方式的不同。

在Resumable技术下，SSR时会将大量数据序列化为HTML属性或注释，比如：

• DOM与Qwik组件的关系
  
• 状态（是的，状态都会在服务端序列化为HTML属性，再在客户端恢复）
  
• 代码逻辑（比如上述示例中的点击回调逻辑）
  

服务端完成了大部分工作，客户端需要做的仅仅是按需反序列化数据，并执行对应逻辑。

在RSC中，服务端组件会被序列化为一种自定义JSX协议，并被流式传输。之所以没有被序列化为HTML字符串（就像Resumable那样），是因为数据被反序列化后并不直接是HTML，而是JSX，JSX经由React处理后才会映射到HTML，这么做能保持服务端组件的子孙客户端组件不丢失状态。

比如如下RSC，根据id props从数据库取不同数据，再将数据传递给子组件（客户端组件）：

function ServerCpn({id}) {
  const data = db.get(id);
  return <ClicentCpn {...data} />;
}

当id props变化后，ClicentCpn组件内的状态并不会丢失。就是因为服务端传输来的ServerCpn是一种自定义JSX协议，而不是HTML字符串。

区别2：变化监测方式

通过区别1可以发现，RSC中序列化的数据描述的是组件级别的内容（JSX描述组件）。

而Resumable中序列化的数据粒度更细（比如描述点击事件的回调逻辑，或者某个状态）。之所以会有这种区别，是因为两个框架采用不同的变化监测方式。

当状态变化后，React需要遍历完整的组件树才能计算出「状态变化产生的影响」。所以序列化数据只需要描述组件级别的内容就行。

而Qwik（实现Resumable技术的框架）使用Signal监听状态变化，这使得他能精确定位「状态变化所产生的影响」，即精确定位状态变化需要反序列化哪些数据。

区别3：后续的发展

由于React是重客户端运行时的框架，所以虽然RSC是SSR技术，他的后续发展还是会与重客户端运行时的技术绑定（比如Suspense、Selective Hydration）。

Resumable是重服务端技术，所以后续发展应该会围绕服务端展开，比如：

• 支持更多类型数据的序列化（当前不支持class序列化）
  
• 支持序列化数据的流式传输
  
• 支持对「是否序列化数据」更精细的控制
  

Miško的想法

了解了这些技术细节，让我们回到开篇，为什么「Miško」会怼React呢？

实际上，这并不是「Miško」第一次对React发表看法。之前「Miško」就曾表示：即使React Forget Compiler成功问世，他也没法解决props下钻场景下的性能问题，并以此论证Signal技术的优越性：

在这里我们不比较技术优劣。只是说单纯用脚投票，除了React外，确实有很多框架都使用了Signal相关技术，比如：

• Vue
  
• Preact
  
• Qwik
  
• 新版Angular
  
• Solid.js
  

在「Miško」看来，React团队之所以不采用更优秀的技术，是由于一旦采用新技术，就没法完美的向后兼容，势必造成社区生态的割裂。

作为Angular的作者，「Miško」对这种后果再清楚不过了。

但是，React团队却认为 —— React之所以没有采用这些技术，是因为自身的技术路线更优秀。

这里「Dan」举出的例子是Hooks和RSC。

本文已经做过RSC与Resumable的比较。在笔者看来，两者是不同技术路线（CSR优先还是SSR优先）下的优秀代表。

但就Hooks而言，笔者认为Hooks优秀在其理念，而不是实现。同样基于Hooks理念实现的Vue Composition API在使用体验上比React Hooks更佳，比如：

• 没有闭包陷阱
  
• 没有显式指明依赖的心智负担
  

之所以同样理念的不同实现使用体验不同，完全是由于底层的技术实现区别造成的（这里指「底层变化监测方式」）。

所以，从这个角度想，笔者并不赞同React团队的说法。

我想，这也是为什么「Miško」会认为React团队吃不到葡萄说葡萄酸。

总结

大佬们的讨论总是理性、互相尊重且克制的。「Miško」在后续也表示了自己对React的误判。

在Qwik v1.0发布时，「Dan」第一时间送上祝福。

有意思的是，对于「Dan」的祝福，「Miško」回复道：我们都站在巨人（指React）的肩膀上。

这是不是说，我还是比巨人要高呢？