一个新视角:前端框架们都卷错方向了?

大家好,我是卡颂。

近年来,前端领域涌现了许多新框架,如Svelte、Solid.JS、Astro、Qwik等。伴随这些框架的出现,还出现了许多高端的新概念,如「运行时/编译时框架」、「Islands架构」、「Selective Hydration」等。这些概念的核心目标是「通过各种方式,让页面加载和响应更快」。

这里的「快」主要体现在两个方面:

  1. html加载更快(与SSR相关的概念,如「Islands架构」);
  2. 更快响应用户交互(采用「细粒度更新」的框架,如vue、Solid.js)。

然而,「快」是否是评判Web未来发展方向的唯一标准呢?

一位拥有32年开发经验的老程序员在他的博文《get-in-zoomer-we-re-saving-react》中提出了不同的观点。本文是对该博文的部分解读。

立即学习前端免费学习笔记(深入)”;

对于应用来说,什么才是重要的?当前前端框架的新特性主要关注「通过各种方式,让页面更快」。这里的主语是「页面」而不是「应用」。事实上,虽然开发者经常谈论web app,但大部分开发者开发的,只能称为页面。

页面与应用的一大差别在于「交互体验的差异」。如果一个页面的某些交互类似于ios原生应用,我们会说这个页面的交互体验非常出色。因此,虽然「速度快」是交互体验的重要一环,但绝不是全部,还有许多细节值得考虑。

以业界用户体验的标杆Mac OS为例:

在Mac OS中,打开应用的状态栏时,按住「command + option」等快捷键可以开启进阶功能:

一个新视角:前端框架们都卷错方向了?按住command + option前

一个新视角:前端框架们都卷错方向了?按住command + option后

撤回(command + z)操作的结果对各种操作目标都是符合预期的(不管目标是文本还是文件等)。富文本内容的复制、粘贴与通过拖拽的表现一致。这些「符合预期」的细节背后,是一套「响应式系统」。

Mac OS X是第一款声称自己为「响应式」的操作系统。在此之前,业界的效仿对象windows操作系统。在Windows中,数据是「非响应式」的。除非开发者手动刷新或轮询更新,否则获取的数据不会自动更新。这种底层模式对上层应用的操作会有直观的影响。

例如,下面是Windows 95中改变桌面外观的配置项,用户改变配置后,只有在点击「OK」或「Apply」后,才能看到「改变配置后的效果」。

一个新视角:前端框架们都卷错方向了?这一情况类似于前端框架普及前,开发者手动操作dom的情况。

相比之下,Mac OS X采用响应式更新,用户在Mac OS中改变许多配置项后能够立刻看到效果。这类似于开发者使用前端框架后,「状态变化」能够自动触发「视图更新」。

操作系统的演进对前端框架的发展具有借鉴意义。正如上面所说,Mac OS X的发展方向是「为了更好的用户体验,打磨各种细节」,而前端框架的发展方向是「更快」。

前端框架走歪了吗?「React 并发特性」应该是今年前端领域比较热门的话题。然而,从社区关于「并发特性」的文章来看,相比于「使用并发特性并从中获益」,更多文章是关于「并发特性的科普,以及解释其造成的影响」。从这个角度看,「并发特性」似乎叫好不叫座。

如果从更广的范围考虑「用户体验」,React是否可以有其他发展方向呢?例如,当前连续事件(Continuous Events,指连续触发的事件,如鼠标事件、滚动事件)触发的频率和速度通常比React重新渲染的速度要快,容易造成不好的用户体验。通常的解决方案是使用ref,换句话说,就是降级到手动操作DOM。这里是否有很大的优化空间呢?

除了React外,其他框架是否也可以从这个角度考虑发展方向呢?

你认为前端框架的发展方向走歪了吗?

参考资料[1]

get-in-zoomer-we-re-saving-react: https://www.php.cn/link/67236033be4f58d696d0d4ada931c543

© 版权声明
THE END
喜欢就支持一下吧
点赞6 分享