导读：送给大家一句话：能够看见未来很美妙，但道路永远不会百分百清晰。

能够看见未来是很美妙的事，但道路永远不会百分百清晰。

但是，我们可以观察到趋势，观察到创新，并尝试规划路线，以及想象更美好的事情，我们可以成为这些创新的一部分，来指导自己前进的方向。

在 2022 年前端业界发布了大量推动 Web 开发的应用。我们看到，有 Astro 和 Sveltekit 的 1.0 版本。包括SolidStart 和 Qwik 进入了 Beta 阶段。而React 18 也已发布，加入诸多的新特性。

还有 TypeScript 对设计框架解决方案方式的影响，包括从 tRPC 和 Tanstack Router 到 Next.js 元框架 create-t3-app。

我们如何到达这里

目前的页面渲染，大多使用服务器端呈现，它可以让代码更快地获取数据来呈现页面，但这种情况也有缺点，它会减慢网页的响应时间，并且会面临不断增长的 JavaScript 包，通常情况下会增加数据包尺寸，因为现在不仅需要代码来做客户端呈现，还需要水化（交互处理，事件处理以及用户体验等）页面。

目前存在一部分解决方案：开发者可以更积极地使用缓存，使用流式传输 HTML 响应，我们还可以选用更小更快的框架。

还有一些转移注意力的问题。有些开发者们可以认为渐进式增强是水合作用的替代品，或者禁止客户端缓存会有意义地，但是事实并非如此。

我不太相信每个人都在同一页面上，但该领域的许多领先思想实际上都基于这种情况，这可不是一件可以掉以轻心的事情。

我们在哪里

单页应用程序并不是适合所有情况的架构。

这个结果，不应该让人感到意外。但这项目技术的十年之后，需要一些说服文字。

详细说明一下单页应用程序的含义。它指的是任何典型的 JavaScript 客户端路由和渲染架构。还有些吹嘘服务器渲染的框架，从 React、Next 和 Remix 到 Vue 和 Nuxt，再到 Sveltekit 和 SolidStart等，应有尽有。

这是一种自然进化。创建一个将出色的 UX 与 DX 相结合的解决方案，人们当然希望随身携带它。

哪里适合这些场景？任何关心页面加载性能以达到最底部的地方，任何关心低端设备和网络的地方，以及复杂性不合理的相关地方，这些地方它们都适合。

我们总结了 2022 年框架思想领导者之间最大的一致性，那就是路由属于服务器。

我们并不建议取消客户端路由（尽管这是一个选项）。只是客户端路由和渲染架构将再次被限制在可以有效使用的地方。

无论是在查看 Marko、Astro 或 Fresh ，还是 Next 和 SolidStart 的服务器端组件，你都会看到服务器正在加强路由职责，在初始页面加载后呈现下一页以响应。比如Qwik，它以合法的方式优化加载应用程序启动，并且这种机制已扩展到成熟的 SPA。在所有示例和演示中，开发者们都更喜欢服务器端路由 (MPA)。

回顾 2022 年

征服水合作用

随着服务器渲染成为焦点，水合作用成为重要话题也就不足为奇了，它也是为每个使用声明性 JS 框架编写的服务器呈现应支付的成本。

Qwik 和早期的 Marko 6 都在恢复演示，这一切都在表明，水合作用的问题可能很快就会成为过去时。

混合嵌套路由

在 2022 年底，我们看到了 2 项实验性新技术，它们提供了两全其美的优势——我们将客户端导航与服务器渲染配合使用。

虽然不是每个人都在服务器组件上开发，但很难否定在保持 SPA 用户体验的同时交付 JavaScript， 这种方式比最小的 SPA 框架能够提供的尺寸少得多。

这证明另一种大幅减少水合作用的方法就是不去发送代码。

无处不在的信号

细颗粒度的反应性特性在 2022 年卷土重来。Vue 社区会告诉人们，它永远不会过时。在过去的2022年里，我们看到它在更广泛的范围内被应用，并在信号（Signal ）的新旗帜下取得了成功。

从 Solid 独特的细粒度渲染器到Preact 和 Qwik 使用它来增强虚拟 DOM 解决方案。Marko 6 的编译器展示了如何以 Svelte 风格的方式编译细粒度的反应性，甚至 Angular 团队也在强烈考虑添加这些原语和技术。

TypeScript 驱动的开发

2022 年，TypeScript 从一个可选项变为许多元框架 CLI 的默认选项。

跨客户端-服务器边界拥有类型安全的 API 不再是考虑因素，tRPC 已经改变了游戏规则。在过去的一年里，我们看到 JavaScript 元框架正在思考这一点——从 SolidStart 的已编译类型安全 RPC 到改进 Remix 和 Next 的数据加载机制。

Tanstack Router 向我们展示了类型安全路由的样子。我们仍然看到这些技术向外传播，但收益却是非常之大，当这些技术来临时，人们不会再接受以前的开发方式。

前进到 2023 年

上面将继续成为新的一年的主题。

人们不会在短时间内将大量创新倾倒在一个空间中，也不会期望有所更大作为。Astro 和 Remix 分别针对 MPA 和 SPA 回归“它应该是 PHP/Rails 的方式”，这在很大程度上取得了成功，即使它们都还缺乏更复杂解决方案的优势。

在 Qwik 和 Marko 上花费大量时间用于 MPA 以及 React 和 Solid 风格的服务器组件，用在混合路由解决方案上，但这些仍然需要学习一些东西。当自定义语言服务器插件是检查服务器组件的唯一方法，或者你需要成为代码中出现序列化边界的专家时，需要对它进行测试和检验。

这些技术就是未来。

但是需要记住，我们不是第一个尝试这样做的人。如果我们转向了 SPA，需要回答一个问题：“这次有什么不同？”

边缘：未开发的边界

在过去的 12 个月里，边缘功能支持已经推广到几乎每个元框架，而且绝大多数可以部署到各种无服务器和边缘计算产品。

我们很快指出数据不在边缘。我们应该假设即使解决方案解决了问题，也并非所有数据都处于边缘中。

边缘需要超越整体部署。我们需要弄清楚如何将计算分配到有意义的地方。

我们不是在谈论微前端或微服务，但应该具有分布式部署的整体创意。我不确定那是什么样子，但我相信会在接下来的 12 个月内找到答案。

其他技术

2023 年会成为 Web 组件之年吗？

与 Linux 桌面之年的可能性差不多，且让它随遇而安。

2023 年会是 WASM 年吗？

可能还不是。但悄悄地，WASM 适用于比以往更大的空间。这包括 DOM 渲染。我们认为理解的开销并不是如我们想象的那样大，最快的 WASM Rust 库已经缩小了与 JavaScript 在客户端渲染方面的差距。

页面加载对于很多事情来说仍然是令人难以言表的指标，但是你仍然可以使用 WASM 进行渐进式增强。

人工智能和零代码技术在 2023 年抢走我的工作吗？

不会，但它可能会帮助你将代码从一个框架迁移到另一个框架中。

总结

没有一个人能够拥有全部的水晶石，我们都正处于变革时期。

在经历了大约 5 年的相对沉默之后，新的框架在过去一年左右出现了一些。

即使是大厂玩家也在尝试新生态系统重置技术栈，如服务器组件、新的无虚拟 DOM 编译器（如 Vue Vapor）以及新的变更机制（如信号）。

但是目前仍没有明确的方向。虽然现有方法已达到极限，但激进的新方法还是不完整的，并且会将复杂性传递给开发人员，隐藏在元框架中的尝试只是前进了一小步。

开发者对框架的期望越来越高，而对用户体验的需求也在不断递增。

所以，无论是在等待下一次革命还是想生活在最前沿，都请系好安全带，因为无论你是否有驾驶证，我们都在乘坐着这辆车。