瞥见未来的奇妙之处在于，这条道路永远不会完全清楚。我们可以查看趋势，并研究创新并尝试绘制课程。更好的是，我们可以成为指导方向的创新的一部分。但是什么都不确定。
2022拥有大量的大版本，可以推动网络开发的前进。我们看到了Astro和Sveltekit的1.0版本。 Solidstart，Qwik进入了Beta。 React 18释放了添加流支持，该支持将其进入Next和Remix，以及为React Server组件和下一个13个应用程序目录提供动力。而且，我会被遗忘，以跳过TypeScript对我们设计框架解决方案的影响。从trpc和tanstack路由器到自以为是的下一步。
“专注于服务器”。他们说：“解决单页应用程序的权衡”。这并不是什么新鲜事物，但是经常不了解的是它不是灵丹妙药。
服务器端渲染使我们能够通过更快获取数据（通常更接近我们的数据源）来更快地渲染页面，但这并非没有妥协。它减慢了我们的响应时间，并没有帮助不断增长的JavaScript捆绑包大小。实际上，它实际上增加了我们的捆绑包大小，因为现在我们不仅需要代码来渲染客户端，而且还需要保湿页面。
有一些部分解决方案：我们可以更积极地缓存，流式传输HTML响应，并可以投资于较小/更快的框架。有一些红色的鲱鱼：我们可以认为渐进式增强是水合的替代品，或者远离客户端缓存有意义地改变了数学。剧透：不是。
我并不相信每个人都在同一页面上，但是空间中的许多领先思想实际上就特定的事情一致。这不是要轻轻的东西。
单页应用程序不是所有内容最合适的架构。
我的意思是，这并不令人惊讶，但是在过去的十年之后，这需要令人信服。也许我需要对单页应用程序的含义进行详细说明。我的意思是，任何典型的JavaScript客户端都路由和渲染架构。即使是拥有服务器渲染的那些。通过Sveltekit和SolidStart。
这是自然的进化。创建一个解决方案，该解决方案将出色的UX与出色的DX配对，人们希望随身携带它。即使在不属于的地方。哪里是？好吧，任何关心页面加载性能的地方都可以使其底线，任何关心低端设备和网络的地方，并且可以说复杂性的任何地方都不合理。
如果我可以总结2022年框架思想领导者之间的最大一致性，那就是路由属于服务器。
我们不建议我们取消客户端路由（尽管这是一种选择）。再次按下客户路由和渲染的体系结构可以有效地使用它们的限制。
无论您是在寻找Marko，Astro还是Fresh及其互动岛，还是Next和SolidStart的服务器组件，您都会看到服务器加强路由职责。初始加载后，渲染下一页以响应导航。即使是Qwik，也可以合法地从优化的部分加载应用程序开始并扩展到成熟的水疗中心，在所有示例和演示中都喜欢服务器路由（MPA）。
服务器渲染为重点，水合已经成为一个重要的话题也就不足为奇了。这是我们为用声明的JavaScript框架撰写的每个服务器渲染的应用程序所支付的费用。或所以我们想。
Qwik和早期Marko 6 Requmable Demos都表明，水合是过去的一天可能是一天的东西。
在2022年底之前，我们看到了两种似乎提供两全其美的实验技术。我们将客户端导航与事后服务器渲染配对。下一个13个应用程序目录SAW服务器组件与嵌套路由配对。
我写了关于Solid的方法，这些方法吹散了捆绑尺寸的期望。
虽然并非每个人都在服务器组件上出售，但与最小的水疗框架相比，交付JavaScript的交付少得多，在维护该水疗中心的同时也很难。
。
Pawel Kozlowski@pkozlowski_os
信号是新的vdom。
兴趣爆炸：许多人正在尝试事情。这将使我们探索空间，尝试不同的策略，理解和优化事物。
不确定我们最终要解决什么，但是这种集体探索很棒！20:41 pm- 2022年9月24日
细粒度的反应性在2022年卷土重来。VUE社区（正确）告诉您，对于他们来说，它永远不会过时。但是，只有在过去的一年中，我们才看到它在更广泛的范围和新的信号横幅下才能发展。从Solid独特的细粒渲染器到在其vdom solutions中使用它。 Marko 6的编译器展示了如何以较巧妙的方式来汇编细粒度的反应性，甚至角团队也强烈希望添加这些原语。
2022 SAW Typescript从作为默认值的选项到许多元框架Clis。
在客户端服务器边界上具有类型安全的API，甚至不再考虑了。 TRPC是一个改变游戏规则的人，但是在一年中，我们在JavaScript Meta-Frameworks中看到了这一点。从SolidStart的编译类型安全RPC到改进到Remix和Next的数据加载机制。
tanstack路由器向我们展示了哪种类型安全路由的样子，现在没有回头路。我们仍在看到这些技术向外传播，但是收益是如此重要的人不会接受开发这些技术存在时以前的方式。
这将继续成为新年的主题。您不会在短时间内将一堆创新倾倒在一个空间中，也不期望会有一些东西。 Astro和Remix分别为MPA和水疗中心返回“仅是PHP/Rails”，即使他们都缺乏更复杂的解决方案的重要好处，也取得了成功。
。在Qwik和Marko花费了很多时间，用于MPA和React和Solid的服务器组件的混合路由解决方案的固体风味，这里仍然需要在这里学习一些东西。当自定义语言服务器插件是检查服务器组件的唯一方法时，或者您需要在代码中序列化边界发生的何处成为专家，则需要开始质疑事物。
这些技术是未来。但是我们需要记住，我们不是第一个尝试此操作的人。后端技术在2000年代中期进行了尝试，相反，我们在很大程度上转移到了水疗中心。我们需要回答“这次有什么不同？”
，它仍然可能归结为回答这个问题：我们是否相信可以运送到浏览器，最终应该是，或者服务器是我们应该独特利用的地方？随着MPA和Spa之间的障碍融化，很可能会采用新的形式。
Edge功能支持已在过去12个月中几乎所有元框架。在这一点上，其中绝大多数可以部署到各种无服务器和边缘产品。但是，这并没有改变我们的发展方式。
我们很快指出数据不在边缘。我们应该假设，即使解决方案为此解决，并非所有数据都将处于边缘状态。
边缘需要超越整体部署。我们需要弄清楚如何将计算分配到有意义的地方。我不是在谈论微货币或微服务。但是具有分布式部署的单片创作。我不确定这是什么样的，但我敢肯定我们会在接下来的12个月中找到。
2023最终将成为Web组件的一年？
大约是Linux桌面年的可能性。以你的方式。
2023年是WASM的一年？
可能不是。但是静静的Wasm一直发现自己适用于比以往更多的空间。其中包括DOM渲染。我们认为我们知道的头顶不是我们的想法，最快的Wasm Rust库已在客户端渲染上使用JavaScript缩小了差距。
瑞安·卡尼亚托（Ryan Carniato）@Ryancarniato23:58 PM- 2022年10月12日
页面负载仍然是许多因素的超值指标，但是您仍然可以使用WASM进行渐进式增强。因此，如果它足够好，可以对您来说可能足够好。
AI/No-Code会在2023年接我的工作？
否。但这可能会帮助您将代码从一个框架迁移到另一个框架。
没有人有水晶球，但是没有一个人才能看到我们正在发生变化。经过大约5年的相对沉默，新框架在过去的一年左右出现，这是有充分理由的。不是我们停止制作它们，但时间是正确的。
即使是大型玩家也正在调情生态系统重置技术，例如服务器组件，新的虚拟圆顶编译器（例如Vue Vapor）和新的更改机制（例如信号）。
但是还没有明确的方向。现有的方法处于极限。激进的新方法是不完整的，并以他们采用的任何形式将复杂性传递给开发人员。试图将其埋在元框架中只是有些成功。
开发人员的经验期望从未如此高，而对用户体验的需求并没有减少。因此，无论您是在等待下一次革命还是在流血边缘生活，无论您是否签约，都可以搭扣。
。附录
如果您在本文中提到的任何术语和技术都不清楚，我建议：