后端开发教程 - Java、Spring Boot 实战 - msg200.com
JavaScript 框架 - 迈向 2023 年
展望未来的奇妙之处在于，道路永远无法完全清晰。我们可以观察趋势，观察创新，并尝试规划方向。更好的是，我们可以参与这些创新，引领方向。但没有什么是确定的。
2022 年有大量重大版本发布，推动了 Web 开发的发展。Astro 和 Sveltekit 都发布了 1.0 版本。SolidStart 和 Qwik 进入 Beta 阶段。React 18 发布，增加了流式传输支持，并应用于 Next 和 Remix，同时还支持 React 服务器组件和 Next 13 应用目录。此外，我还要特别提及 TypeScript 对我们设计框架解决方案方式的影响。从 tRPC 和 Tanstack Router 到独树一帜的 Next.js 元框架 create-t3-app。
我们是如何走到这一步的
他们说：“专注于服务器”。他们说：“解决单页应用的权衡问题”。这并不是什么新鲜事，但人们常常不明白的是，它并非万能药。
服务器端渲染使我们能够更快地获取数据（通常更靠近数据源），从而更快地渲染页面，但这并非没有妥协。它减慢了我们的响应时间，并且对不断增长的 JavaScript 包大小毫无帮助。它实际上常常会增加包的大小，因为现在我们不仅需要代码进行客户端渲染，还需要代码来补充页面内容。
有一些部分解决方案：我们可以更积极地缓存，流式传输 HTML 响应，并且可以投资更小/更快的框架。但也有一些转移注意力的论点：我们可以认为渐进增强可以替代水合，或者放弃客户端缓存会显著改变计算结果。剧透：事实并非如此。
我不确定大家是否已经达成共识，但该领域的许多领军人物实际上在某件事上达成了共识。这并非一件可以掉以轻心的事情。
我们目前的位置
单页应用程序并不是最适合一切事物的架构。
我的意思是，这本不该让人感到意外，但经过过去十年的发展，这确实需要一些说服力。或许我需要进一步解释一下我所说的“单页应用”的含义。我指的是任何典型的 JavaScript 客户端路由渲染架构，甚至是那些标榜服务器渲染的架构。从 React、Next、Remix 到 Vue、Nuxt，再到 Sveltekit 和 SolidStart，无所不包。
这是一个自然而然的演变过程。创建一个将出色的用户体验与出色的用户体验完美结合的解决方案，人们就会想把它带到任何地方，即使它不属于任何地方。它属于哪里？嗯，任何为了盈利而关注页面加载性能的地方，任何关注低端设备和网络的地方，以及可以说复杂性不合理的任何地方。
如果我可以总结 2022 年框架思想领袖之间最大的共识，那就是路由属于服务器。
我们并非建议废除客户端路由（尽管这也是一种选择）。只是客户端路由和渲染架构再次面临其有效使用范围的局限。
无论是 Marko、Astro 或 Fresh 及其交互岛，还是 Next 和 SolidStart 的服务器组件，你都会看到服务器在路由任务上有所提升。在初始加载后，响应导航渲染下一页。即使是 Qwik，它可以合理地以优化的部分加载应用程序启动，并扩展到完整的 SPA，在其所有示例和演示中也更倾向于使用服务器路由 (MPA)。
回顾2022年
征服水合作用
既然服务器渲染成为焦点，Hydration 的重要性也就不足为奇了。这是我们为每个使用声明式 JavaScript 框架编写的服务器渲染应用程序所付出的代价。或者说，我们是这么认为的。
Qwik 和早期的 Marko 6 可恢复演示都表明，水合技术可能很快就会成为过去。
混合嵌套路由
在 2022 年底之前，我们看到了两项似乎兼具两者优势的实验性技术。我们实现了客户端导航与事后服务器渲染的结合。接下来的 13 个应用目录中，我们又看到了服务器组件与嵌套路由的结合。
我写了一篇关于 Solid 的方法的文章，它大大超出了捆绑包大小的预期。
虽然并非所有人都认同服务器组件，但在保持 SPA 用户体验的同时，交付的 JavaScript 代码量远低于即使是最小的 SPA 框架所能处理的数量，这一点毋庸置疑。这证明了另一种大幅减少 Hydration 的方法就是干脆不发送代码。
无处不在的信号
细粒度响应式在 2022 年卷土重来。Vue 社区会（正确地）告诉你，对他们来说，它从未过时。但直到过去一年，我们才看到它在更广泛的领域，以及在 Signal 的新旗帜下蓬勃发展。从 Solid 独特的细粒度渲染器，到使用它来增强虚拟 DOM 解决方案的 Preact 和 Qwik。Marko 6 的编译器展示了如何以类似 Svelte 的方式编译细粒度响应式，甚至 Angular 团队也在积极考虑添加这些原语。
TypeScript 驱动开发
2022 年，TypeScript 从一个选项变成了许多元框架 CLI 的默认选项。
跨客户端-服务器边界的类型安全 API 甚至不再是考虑因素。tRPC 改变了游戏规则，但在过去一年中，我们看到 JavaScript 元框架也开始考虑这一点。从 SolidStart 编译的类型安全 RPC 到 Remix 和 Next 数据加载机制的改进。
Tanstack Router 向我们展示了类型安全路由的雏形，如今已无回头路。我们仍在见证这些技术向外传播，但其带来的收益是如此显著，以至于当这些技术真正存在时，人们将不再接受像以前那样的开发方式。
展望2023年
复杂性的争论
这将继续成为新年的主题。你不可能在短时间内将一大堆创新倾注到一个领域，却不指望它能带来什么回报。Astro 和 Remix 分别针对 MPA 和 SPA 回归“它只是 PHP/Rails”的做法取得了很大成功，即使它们都缺乏更复杂解决方案所带来的重要优势。
在为 MPA 使用 Qwik 和 Marko，以及为混合路由解决方案使用 React 和 Solid 的服务器组件方面投入了大量时间之后，仍然有一些需要学习的地方。当自定义语言服务器插件是控制服务器组件的唯一方法时，或者你需要成为代码中序列化边界发生位置的专家时，你需要开始质疑一些事情。
这些技术代表着未来。但我们需要记住，我们并非第一批尝试这些技术的人。早在 2000 年代中期，后端技术就已尝试过，但后来我们基本上转向了 SPA。我们需要回答“这次有什么不同？”
最终，我们或许还是要回答这个问题：我们是否认为可以交付到浏览器端的功能最终应该交付到浏览器端？还是说，服务器才是我们应该独力利用的地方？随着 MPA 和 SPA 之间壁垒的逐渐消失，这种划分很可能只是换一种形式。
边缘：未开发的边界
在过去的12个月里，边缘函数支持几乎覆盖了所有元框架。目前，绝大多数元框架都可以部署到各种无服务器和边缘产品上。然而，这并没有改变我们的开发方式。
我们很快指出，数据并不处于边缘。而且，即使解决方案已经解决了边缘问题，我们也应该假设并非所有数据都会处于边缘。
边缘计算需要超越单体部署。我们需要弄清楚如何将计算分配到合理的位置。我指的不是微前端或微服务，而是分布式部署的单体开发。我不确定这会是什么样子，但我相信我们会在未来12个月内找到答案。
其他技术
2023 年最终会成为 Web 组件之年吗？
这很可能就是 Linux 桌面元年。至于如何看待它，就由你决定吧。
2023 年会是 WASM 之年吗？
可能还没有。但 WASM 已悄然应用于比以往更多的领域，包括 DOM 渲染。我们自以为了解的开销并非我们所想的那样，最快的 WASM Rust 库在客户端渲染方面已经缩小了与 JavaScript 的差距。
页面加载速度在很多方面仍然是一个难以掌控的指标，但你仍然可以使用 WASM 进行渐进式增强。所以，如果它对 Remix 来说足够好，那么对你来说可能也足够好。
2023 年，AI/No-Code 会取代我的工作吗？
不，但它可能帮助你将代码从一个框架迁移到另一个框架。
结论
没有人拥有水晶球，但无需水晶球就能看出我们正处于变革的时代。在经历了大约五年的相对沉寂之后，新的框架在过去一年左右涌现，这有充分的理由。这并不是说我们停止了开发它们，而是时机已经成熟。
甚至大型企业也在考虑生态系统重置技术，例如服务器组件、新的无虚拟 DOM 编译器（例如 Vue Vapor）以及新的变更机制（例如 Signals）。
但目前尚无明确的方向。现有方法已达到极限。激进的新方法并不完善，无论以何种形式，都会将复杂性转嫁给开发人员。试图将其埋藏在元框架中的尝试，也只取得了一定程度的成功。
开发者对体验的期望从未如此之高，而用户体验的需求却丝毫未减。所以，无论您是在等待下一次革命，还是身处前沿，系好安全带，因为无论您是否注册，都将踏上征程。
横幅来源：©️ 原创概念艺术品（https://www.artstation.com/artwork/nqrYo），由 Alex Feliksovich 根据《攻壳机动队》创作。
附录
如果您不清楚我在本文中提到的任何术语和技术，我建议：
