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