几个月前，作者重新学习了反应性相关知识，发现错过了围绕信号的非结构化反应性开发的一个大领域。选择信号而非基于函数组件的框架（如 React）的原因与应用数据和 UI 视图之间的形状不匹配以及性能要求能否容忍这种不匹配有关。

对于大多数性能要求中等的 Web 应用，基于函数组件的框架（如 React）效果很好，尤其是当应用状态与 UI 结构紧密匹配时。但当应用状态和 UI 视图的形状差距增大时，React 的声明式执行模型可能导致更新效率低下，影响性能。此时开发者会转向信号，以换取更精确和高效的状态更新。

React 的基本假设是状态依赖图的形状与组件树相似，但实际中并非总是如此，这可能导致大量不必要的 UI 重新渲染，增加出错风险。而信号可以定义独立的依赖图，跟踪状态更新的流向，只更新依赖的部分，从而提高性能，但也存在信号易混乱等问题。

在编程领域，这种在简化状态管理和追求性能之间的权衡普遍存在。在改善声明式系统的执行内部方面，如解决 JavaScript 在检测嵌套属性变化、处理 immutability 以及组件粒度等方面的限制，可以通过使用真正的不可变复杂值、版本时钟、代数效应等方式来尝试，但都存在各自的问题。

也可以通过定义声明式策略来提示框架进行智能分组更新，以实现部分更新，但实现这样的系统仍具有挑战性。纯粹的声明式系统在处理精细更新时会逐渐失去其简洁性，需要在保持声明式风格和实现精细控制之间找到平衡。

总之，声明式框架在处理常见情况时表现出色，但在处理如实时应用等边缘情况时，其他范式能更好地定位变化，不存在既纯粹又无限适应的完美解决方案。