JavaScript框架--迈向2023年

本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一时间和你分享前端行业趋势，学习途径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi ，包含一线大厂面试完整考点、资料以及我的系列文章。

窥视未来的奇妙之处在于，道路永远不会完全清晰。我们可以看看趋势，看看创新，并尝试制定一个路线。更好的是，我们可以成为这些创新的一部分，引导方向。但没有什么是确定的。

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 包大小。由于现在需要在客户端渲染之外的代码来激活页面，因此它通常会增加我们的包大小。

为什么JavaScript框架中的高效水合是如此具有挑战性

地址：https://dev.to/this-is-learning/why-efficient-hydration-in-javascript-frameworks-is-so-challenging-1ca3

有一些部分的解决方案。我们可以更积极地进行缓存，流式处理我们的HTML响应，并且我们可以投资于更小/更快的框架。有一些假解决方案：我们可以认为渐进式增强可以替代水合作用，或者认为放弃客户端缓存可以有意义地改变计算结果。剧透一下：它没有。

我并不确信每个人都在同一页面上，但是该领域的许多领先思想实际上对某件事情有共识。这不是一件可以轻视的事情。

我们所处的位置

单页应用程序并不是最适合一切的架构。

我的意思是，这不应该令人惊讶，但是在过去的十年中，这需要一些说服力。也许我需要对我所说的单页应用做一些解释。我指的是任何典型的 JavaScript 客户端路由和渲染架构。甚至是那些宣称支持服务器渲染的架构。从 React、Next 和 Remix 到 Vue 和 Nuxt，再到 Sveltekit 和 SolidStart。

这是一种自然的演变。创建一个拥有优秀用户体验和优秀开发体验的解决方案，人们希望将它带到任何地方。即使是它不属于的地方。那里是哪里？好吧，任何关心页面加载性能以提高底线的地方，任何关心低端设备和网络的地方，并且可以说任何复杂度不合理的地方。

如果我能总结出 2022 年框架思想领袖之间最大的一致性，那就是路由属于服务器。

服务器端路由的回归

地址：https://dev.to/this-is-learning/the-return-of-server-side-routing-b05

我们并不是建议放弃客户端路由（尽管这是一个选择）。只是客户端路由和渲染架构再次面临着能够有效使用的范围的限制。

无论你是在考虑 Marko、Astro 或 Fresh 及其交互性岛屿，还是 Next 和 SolidStart 的服务器组件，你都会看到服务器在路由职责上承担起了重任。在初始加载之后，根据导航渲染下一页。即使是 Qwik，它本来可以作为优化的部分加载应用程序启动，并且可以扩展到完整的 SPA，但它在所有示例和演示中都更喜欢服务器路由（MPA）。

对2022年的反思

征服水化作用

随着服务器渲染成为焦点，水化成为一个重要的话题也就不足为奇了。这是我们为每一个用声明式JavaScript框架编写的服务器渲染的应用程序所付出的代价。或者我们是这样认为的。

征服JavaScript的水化作用

地址：https://dev.to/this-is-learning/conquering-javascript-hydration-a9f

Qwik和早期Marko 6的可恢复演示都表明，水化很快可能成为过去。

混合嵌套式路由

在 2022 年底之前，我们看到了两种似乎提供双方优势的实验技术。我们得到了客户端导航与after-the-fact服务器渲染相结合的应用程序。Next 13 应用程序目录看到服务器组件与嵌套路由相结合。

不使用JavaScript的客户端路由

地址：https://dev.to/this-is-learning/client-side-routing-without-the-javascript-3k1i

虽然并不是所有人都支持服务器组件，但很难否认，它们可以在保留 SPA 用户体验的同时，比即使是最小的 SPA 框架也能够实现的所有 JavaScript 都少得多。这是一个证明，另一种大幅减少Hydration的方法是简单地不发送代码。

到处都是 Signal

在 2022 年，细粒度的响应性再次流行起来。Vue 社区（正确地）会告诉你，对于他们来说，它从来没有过时。但直到过去一年，我们才看到它在更广泛的范围内并以新的Signal旗帜出现。从 Solid 独特的细粒度渲染器到 Preact 和 Qwik 使用它来增强他们的虚拟 DOM 解决方案。Marko 6 的编译器展示了如何以 Svelte 类似的方式编译细粒度的响应性，甚至 Angular 团队也正在积极考虑添加这些原语。

TypeScript驱动的开发

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

tRPC改变了游戏规则，但在这一年里，我们看到JavaScript元框架也在考虑这个问题。从SolidStart的编译类型安全的RPC到Remix和Next的数据加载机制的改进。

Tanstack Router向我们展示了类型安全路由的模样，现在已经没有回头路了。我们仍然看到这些技术在向外传播，但收益是如此之大，当这些技术存在时，人们将不会接受以前的开发方式。

转向 2023 年

复杂性中的争论

这将在新的一年继续成为一个主题。你不能在短时间内在一个领域倾注大量创新，而不希望出现什么问题。Astro 和 Remix 分别回归到“这只是 PHP/Rails”的 MPA 和 SPA，虽然它们都缺少更复杂解决方案的重要优势，但都取得了很大成功。

在Qwik和Marko中花了很多时间用于MPA，在React和Solid的混合路由解决方案中花了很多时间用于Server Components的味道，这里仍有一些东西需要学习。当自定义语言服务器插件是保持服务器组件的唯一方法，或者你需要成为代码中发生序列化边界的专家时，你就需要开始质疑了。

这些技术是未来的趋势。但我们需要记住，我们并不是第一个尝试这样做的人。后台技术在2000年代中期就已经尝试过了，相反，我们基本上都转向了SPA。我们需要回答 "这次有什么不同？"

这可能仍然要归结为回答这个问题：我们是否相信最终可以发送到浏览器的内容应该被发送，还是服务器是一个我们应该独特利用的地方？随着 MPA 和 SPA 之间的障碍消失，这种划分很可能会以新的形式出现。

Edge ：未曾探索的边界

在过去的 12 个月中，几乎所有元框架都支持了边缘函数。在这一点上，绝大多数元框架都可以部署到各种服务器less 和边缘产品中。但是，这并没有改变我们的开发方式。

我们很快就会指出，数据并不在边缘上。而我们应该假定，即使在解决边缘问题的时候，也不是所有的数据都会在边缘上。

边缘需要超越单体部署。我们需要弄清楚如何将计算分配到合理的位置。我不是在谈论微前端或微服务。而是单体软件的分布式部署。我不知道这是什么样子，但我相信我们会在接下来的 12 个月内找到答案。

其他技术

2023年将最终成为 Web 组件的一年吗？

就像今年将成为Linux桌面年一样。随你怎么想。

2023年将是WASM的一年吗？

可能还没有。但悄悄地，WASM已经发现自己比以前适用于更多的空间。这包括DOM渲染。我们认为我们所理解的开销并不是我们所想的那样，最快的WASM Rust库已经在客户端渲染上与JavaScript拉开了差距。

对于很多事情来说，页面负载仍然是一个令人望而却步的指标，但你仍然可以用WASM做渐进式增强。因此，如果它对Remix来说足够好，对你来说可能也足够好。

2023年，人工智能/低代码会抢走我的工作吗？

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

总结

过去大约 5 年相对沉寂之后，在过去一年左右出现了新的框架。这不是我们停止制作它们的原因，而是时机已经成熟了。

即使大公司也在与系统重置技术（如 Server Components）、新的 Virtual DOM-less 编译器（如 Vue Vapor）和新的变更机制（如 Signals）调情。

但目前还没有明确的方向。现有的方法已经到了极限。激进的新方法是不完整的，无论采取什么形式，都会将复杂性转嫁给开发者。试图将其埋藏在元框架中的做法只取得了一定的成功。

开发者对体验的期望从未如此之高，而对用户体验的要求却没有减少。因此，无论你是在等待下一次革命，还是生活在流血的边缘，都要系好安全带，因为无论你是否报名，你都会有一个机会。

原文：https://dev.to/this-is-learning/javascript-frameworks-heading-into-2023-nln

代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。

交流

有梦想，有干货，微信搜索 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试完整考点、资料以及我的系列文章。