共计 1434 个字符，预计需要花费 4 分钟才能阅读完成。
大家好，我卡颂。
近几年，前端畛域呈现了很多新框架，比方 Svelte、Solid.js、Astro、Qwik 等。
随同他们呈现的，还有很多 高大上 的新概念 —— 运行时 / 编译时框架、Islands 架构、Selective Hydration……
这些概念的实质，就是 通过各种形式，让页面更快。
这里的 快次要包含两方面：
- 让
HTML加载更快（一众和SSR相干的概念与此有关，比方Islands 架构） - 更快响应交互（一众采纳 细粒度更新 的框架与此有关，比方
Vue、Solid.js）
然而，快 就是评估 Web 将来倒退方向的唯一标准么？
一位有 32 年开发教训的老程序员在他的博文 get-in-zoomer-we-re-saving-react 中提出了不同的观点。
本文是对该博文的局部解读。
欢送退出人类高质量前端框架群，带飞
对利用来说，什么才是重要的？
下面提到，当初前端框架的新个性，是 通过各种形式，让页面更快。
这里的主语是 页面 而不是 利用。
事实上，尽管开发者常常议论Web App，但大部分开发者开发的，只能称为页面。
页面与利用的一大差异，就是 交互体验的差别。
如果一个页面中某些交互相似 IOS 原生利用，咱们会说这个页面交互做的很棒。
所以，尽管 速度快 是交互体验中重要的一环，但绝不是全副，还有大量细节值得思考。
以业界用户体验的标杆 Mac OS 举例：
- 在
Mac OS中，关上利用的状态栏时，按住 command + option 之类的快捷键可能开启进阶性能：
- 撤回（command + z）操作的后果对各种操作指标都是合乎预期的（不论指标是文本还是文件等）
- 富文本内容的复制、粘贴与富文本内容通过拖拽的体现统一
做过富文本编辑器的同学应该能感触到上述性能的难度
上述这些 合乎预期 的细节背地，是一套 响应式零碎。
响应式零碎
Mac OS X是第一款宣称本人为 响应式 的操作系统。在此之前，业界的效仿对象是 Windows 操作系统。
在 Windows 中，数据是 非响应式 的。除非开发者手动刷新或者轮询更新，否则获取的数据不会自动更新。
这种底层模式对下层利用的操作会有直观的影响。
比方，上面是 Windows 95 中扭转桌面外观的配置项，用户扭转配置后，只有在点击 OK 或Apply后，能力看到 扭转配置后的成果。
这一状况，有些相似前端框架遍及前，开发者手动操作 DOM 的状况。
相比于 Windows，Mac OS X 则采纳响应式更新，在 Mac OS 中的很多配置项扭转后用户可能立即看到成果。
这一状况，相似开发者应用前端框架后，状态变动 可能主动触发 视图更新。
操作系统的演进，对前端框架倒退是有借鉴意义的。
前面的故事正如下面所说，Mac OS X的倒退方向是 为了更好的用户体验，打磨各种细节 ，而前端框架的倒退方向是 更快。
前端框架走歪了么？
React 并发个性 应该是往年前端畛域比拟热门的话题了。
然而，从社区对于 并发个性 的文章看，相比于 应用并发个性并从中获益 ，更多文章是对于 并发个性的科普，以及解释他造成的影响。
从这个角度看，并发个性 仿佛叫好不叫座。
如果从更广的范畴思考 用户体验 ，React 可不可以有其余倒退方向呢？
比方，以后间断事件（Continuous Events，指间断触发的事件，比方鼠标事件、滚动事件）触发的频率、速度通常比 React从新渲染的速度要快，容易造成不好的用户体验。
通常的解决方案是应用ref。换句话说，就是降级到手动操作DOM。这里是不是有很大优化空间呢？
除了 React 外，其余框架是不是也能从这个角度思考倒退方向呢？
你认为前端框架的倒退方向走歪了么？
