本文首发于微信公众号：大迁世界, 我的微信：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 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。