JavaScript框架--迈向2023年

前端面试全家桶：从求职准备到面试演练2023最新

download：https://www.51xuebc.com/thread-537-1-1.html

(资料图片)

窥视将来的巧妙之处在于，道路永远不会完整明晰。我们能够看看趋向，看看创新，并尝试制定一个道路。更好的是，我们能够成为这些创新的一局部，引导方向。但没有什么是肯定的。

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年的深思

降服水化作用

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

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

混合嵌套式路由

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

固然并不是一切人都支持效劳器组件，但很难承认，它们能够在保存 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）调情。

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