大家好，我是Kason。近年来，前端领域涌现出许多新的框架，如Svelte、Solid.js、Astro、Qwik等，与之相伴的，还有许多“高端”的新概念——“runtime/compile”-timeframework”、“Islandsarchitecture”、“SelectiveHydration”……这些概念的本质是“通过各种方式让页面更快”。这里的“快”主要包括两个方面：让HTML加载更快（很多与SSR相关的概念都与此相关，比如“IslandsArchitecture”）和响应交互更快（很多框架使用“细粒度”update”与此相关，如Vue、Solid.js）然而，“快”是评价Web未来发展方向的唯一标准吗？一位有着32年开发经验的老程序员在他的博文中提出了不同的观点[1]。本文是对博文的部分解读。什么对申请很重要？前面说了，前端框架的新特性是“通过各种方式让页面变快”。这里的主题是“页面”而不是“应用程序”。事实上，虽然开发者经常谈论WebApps，但大多数开发者开发的东西只能称为页面。页面和应用程序之间的一个很大的区别是“交互体验的差异”。如果一个页面中的某些交互类似于IOS原生应用，我们会说这个页面交互很棒。因此，虽然“速度快”是交互体验的重要组成部分，但绝不是全部，还有很多细节值得考虑。以业界用户体验标杆MacOS为例：在MacOS中，打开应用程序状态栏时，按住“command+option”等快捷键可以打开高级功能：按住command+optionbeforepressingcommand+option后的undo（command+z）操作的结果对于各种操作目标（无论目标是文本还是文件等）都是符合预期的。富文本内容的复制和粘贴与富文本内容的拖放一致。做过富文本编辑器的同学应该能感受到以上功能的难易程度。在这些“意料之中”的细节背后，是一个“响应式系统”。响应式系统MacOSX是第一个声称“响应式”的操作系统。在此之前，业界的仿真对象是Windows操作系统。在Windows中，数据是“无响应的”。除非开发人员手动刷新或轮询更新，否则获取的数据不会自动更新。这种底层模式会对上层应用的运行产生直观的影响。例如下面是Windows95中更改桌面外观的配置项，用户更改配置后，只有点击“确定”或“应用”后才能看到“更改配置后的效果”。这种情况有点类似于前端框架普及之前开发者手动操作DOM的情况。与Windows相比，MacOSX采用响应式更新，MacOS中的很多配置项更改后，用户可以立即看到效果。这种情况类似于开发者使用前端框架后，“状态变化”可以自动触发“视图更新”。操作系统的演进是前端框架发展的参考。其背后的故事如前所述，MacOSX的发展方向是“打磨各种细节以获得更好的用户体验”，而前端框架的发展方向是“更快”。前端框架歪了吗？《ReactConcurrencyFeatures》应该是今年前端领域的热门话题。但是，从社区关于“并发特性”的文章来看，相比“使用并发特性并从中受益”，更多的文章是关于“并发特性的科普及解释其影响”的。从这个角度看，“并发特性”似乎很受欢迎。如果从更广的角度考虑“用户体验”，React是否可以有其他的发展方向？例如，当前连续事件（ContinuousEvents，指持续触发的事件，如鼠标事件和滚动事件）的频率和速度通常比React的重新渲染速度更快，这很可能导致不良用户经验。通常的解决方案是使用ref。换句话说，降级为手动操作DOM。这里有很大的优化空间吗？除了React，其他框架是否也能从这个角度考虑发展方向？你觉得前端框架的发展方向是不是走错了？参考文献[1]get-in-zoomer-we-re-saving-react：https://acko.net/blog/get-in-zoomer-we-re-saving-react/。
