类似react、vue之类的工具，我称之为视图驱动，而非框架，框架大体上需要提供完整的应用架构设计，而视图驱动解决的是视图的渲染模式、数据驱动渲染模式、事件响应模式，当然，围绕视图驱动，我们可以构建出上层的框架。而这两年，市面上因此出现了一些框架，如remix等，就我个人观察而言，新一代前端框架在某些方面具有一致性，可以说，随着前端的发展，前端正在流向一种新的模式，或者说一种自然而然呼之欲出的模式。

新一代前端框架的基本特点

近期关注了remix, liveview, asta, flareact, ilc, Shopify Hydrogen等框架，它们身上有显著的一种趋势，即不局限在实现一种视图渲染的模式，而是希望在业务层面更好的结合业务本身实现其需要的业务能力，而不是专注视图驱动层面的技术追求。其主要特征包含：

• SSR
• 微服务化
• react风格流
• 云渲染
• 前端0JS化

接下来我会去分析这些特征的技术原理。

前端框架SSR趋势

新出现的前端框架或一定要支持SSR，或为配合SSR，更有甚者自己便是SSR的框架。基于服务端渲染其实是web最早期的渲染形式，在2010年前后我刚开始进入web开发领域，那时便是基于php的框架输出web界面，通过php和js的前后端配合，可以非常高效的完成页面开发。但2014年前后，整个前端开始往SPA方向发展，且在angularjs的带头模范下，模板引擎成为前端的基础设施，并开启了前后端分离的大趋势。前后端分离从表面上，就是后端只专注输出api接口，而前端基于ajax技术请求这些接口拉取数据来渲染想要的界面。但发展至2018年时，SPA的庞大体系带来了各种问题，以及整个技术领域的前进，SSR又重回大家视野，但与早期的SSR不同，此刻的SSR由前端主导，而且研究的课题更多是如何更高效的对界面进行渲染，仍然是前端的范畴，只是借用了服务端的一些能力，其前后端分离的本质是没有变化的。

为什么会出现SSR的趋势？有人是讲大量企业有SEO的需求，但我认为更重要的是，部分SPA渲染的模式很慢，用户体验不好。

新阶段的SSR技术发展也经历了多个阶段：

1. renderToString阶段，这一阶段在技术上主要是通过在后端nodejs环境下运行原本用于生成前端界面的代码，通过重写框架运行方法的方式，把原本通过js生成DOM节点的行为，变为在服务端直接生成对应HTML字符串的行为，并通过服务器发送给浏览器，当然，为了能够让用户继续体验SPA的无刷新效果，在页面加载完之后，还会有一个hydrate的过程，即页面加载完之后把原本的SPA能力赋予已出现的页面。
2. 由于renderToString的整个实现过程是执行程序拼接HTML，不仅需要启动对应的环境，还要运行框架，才能最终到一个页面的呈现，这个过程和链路都很耗费资源。为此，部分框架就试图优化这一过程，以提升其性能。例如remix、asta等框架，都用不同策略优化其渲染输出，让用户在感官上获得更好的体验。
3. react18提出一种server components的概念，即直接在服务端渲染组件，再patch到浏览器中。基于这一理念，新的框架不再走拼接HTML的思路，而是云渲染的模式，浏览器只作为一个可交互的输出设备，而非真正执行渲染过程的环境，框架的渲染全部在服务端，再将渲染结果通过socket等通信方式patch到浏览器上。

基于这一趋势，前端开发的过程也发生变化，从最早的需要服务端客户端同时编写，到只需要写服务端代码，再到不需要考虑任何与浏览器相关的代码撰写。这一变化或者说未来前端的发展趋势，会从一个侧面削弱当前前端开发中针对浏览器的部分，从而让开发本身更瘦身。而且，基于这一趋势，前端后化话也更紧迫。

前端框架微服务化趋势

前端基础设施的变更，让很多应用层的后端工作也可以让前端去胜任。后端越来越往底层的服务去收敛，而把应用层的业务，都可以交给前端去完成。基于微服务架构的流行，服务于服务之间通过非http接口的形式通信，可以获得新的组织形式。serverless等基础设施的成熟，让前端部署一个实现特定业务目标的服务也更加容易。而且服务化之后，很多依赖关系变成了更精炼的方式，甚至只有一种调用方式，这让业务的封装达到了最高级别。

前端框架也在追寻这种趋势，大部分框架都希望自己能够成为方便部署为微服务的框架，基于这一理念，开发者把自己依赖该框架的服务部署之后，就可以立即向其他业务模块提供自己完成的业务能力，提供的内容里面直接包含了界面的部分，调用微服务就像调用组件一样方便精炼。

flareact等框架直接希望成为边缘渲染等框架，不需要复杂的集群管理，直接在边缘CDN上部署产物。当然，在CDN上无法直接通过服务器内网联通到其他服务上，但也可以非常方便的让前端的产物以最接近用户的方式，产生碎片化服务化的界面提供。

我个人的预测是，未来的前端框架，将会提供除了单个业务微服务化的能力之外，还会提供集成微服务的架构能力，通过集成就可以极快的出多站点。

前端框架react风格化

代码的写作风格有往jsx+hooks的方向发展的趋势，新的框架大部分默认以jsx作为自己表达界面结构的基础，同时用hooks来管理从数据库拉取的数据或状态。这种风格化趋势已经是直接的明显的趋势。

早前的时候，由于ssr多以拼接字符串的形式出HTML页面，因此，大家认为基于模版的框架更有优势，例如solid等框架，但随着拼接字符串的模式被打破，jsx本质是js语法糖的优势就凸显出来，因为在渲染过程中，它可以做到以stream形式向浏览器patch，从而做到先出首屏再持续渲染的效果，极大的提升体验。包括liveview在内的大部分框架都遵循了react风格化。在这些框架中，你能感受到类似electron中在渲染线程里可以同时调用remote能力的效果，你可以在写类似浏览器端功能的同时，直接调用服务端的能力完成某些特殊操作。

RSC（react server components）的概念被提出后，Shopify Hydrogen是一次大胆的实验，它完全基于该概念，提供了一套用于电商平台搭建的系统，RSC的特点在于让组件运行在服务端，从而就可以做到直接在组件中直连数据库。当然，RSC还没有被正式发布，具体如何发展，还有待观望。

云渲染

这一点在liveview中体现的尽致淋漓，你可以这样理解它，它在完成渲染之后，你的每一个动作，都会被序列化为一段小段json发送给后端，后端在接受到之后，直接在后端基于这一段json对界面进行渲染，再将渲染结果与上一次的渲染结果进行diff，再将patch发送回浏览器，浏览器内的脚本拿着这段patch完成界面更新。这种模式其实在php界早就发生了，livewire这个框架是基于laravel的，它就是按照上述的运行模式进行的，只不过它的后端逻辑是laravel的风格，而前端的框架大部分是react的风格。

这种模式有一个非常奇特的福利效果，就是“实时多播”，这在协同编辑、在线教学时具有极强的适应性，例如在线教学，我们在自己的页面的操作所带来的数据变更直接被写入到后端数据库中，而后端会把这一变更直接反应到新的渲染结果上。由于不同用户所访问的页面使用了相同的数据库数据，所以，为了保持实时性，框架会向当前用户发送新的变更，即使这个变更不是当前用户的操作引起的。这一福利效果在这些场景里面可以说是神奇至极，不需要做任何的架构设计，直接基于框架的能力就能实现。

当然，也有一些不足，特别是在弱网环境下，由于每一个操作都需要与后端去通信，由云端完成渲染，那么如果网络不及时，前端就看不到实时的变更效果，这就非常不友好了，所以，我们应该按照自己的场景来选择框架，而不是一味追新。

前端0JS趋势

从nodejs出现后，前端生态出现了翻天覆地的变化，基于js的客户端渲染也占据了主导，但可能是技术的发展总会回旋式上升，时间一长，对js的厌倦感就会上升，因此，社区，特别是后端社区会涌现一些逆流工具。以htmx为代表，它们提供了迎合后端发展趋势（简洁化，功能目标化）的需要，可以做到真正的0 js代码，即全部由后端动态输出必要的数据，前端基于该数据做动态响应。

无论是否真正做到0 js的效果，我们可以从中发现，很多情况下，我们可能不需要复杂的前端架构设计，只是为了完成某些页面的需要，这种情况下，无论是后端输出也好，或者前端直接写也好，其目标都是一致的，就是快速、有效。这在很多长尾场合下非常常见，我们要知道，前端不是全部都是大型的业务开发，还有大量的展示类应用，它们不需要强大的前端架构，甚至常常不需要前端人员。

结语

在2019年的时候，react和vue的热度达到了顶峰，我们那时认为前端的发展必然是在类似的路径上往前奔，而基于马太效应，后来者必然无法追赶上react或vue，但是时间过去不到3年，如今的前端框架市场已经发生了巨大的变化，这种变化一方面是社区不断探索的结果，另一方面也说明并没有什么不可能突破的地方。而且前端这个领域，真正和后端有一个比较明确的界限，也就在2010年以后，短短12年，就翻转了4-5个代际，可见领域的年轻和未来的发展。我们只有秉持不断学习的积极心态，才能更好的面对和接纳未来可能出现的新技术。

2022-10-29 3283