JS 前端框架的新年预言

免责声明

本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考。英文原味版请传送 2024 Predictions by JavaScript Frontend Framework Maintainers。

本期共享的是 —— 来自 React/Next.js/Angular/Solid 的维护者和创建者科普了它们计划在新年里框架改进的未来规划。

React：新年预览

Meta（前脸书）的 React 工程经理 E.W. 表示，React 团队预计在新的一年里会有更多的框架采用 RSC（React 服务服务端组件）。

“对于大多数人而言，RSC 已经对其所了解的 React 作用域产生了重大变化，从只是一个 UI 层，到对构建 App 的方式产生更大的影响，以享受最佳的用户体验和开发体验，尤其以前对于 SPA（单页应用程序）还不够好，”E.W. 如是说。

虽然它没有具体爆料来年的任何新进展，但 E.W. 确实表示它们会发布并共享某些去年开始可公开的进展。举个栗子，在 React Advanced 上，该团队向与会者展示了 React Forget，这是 React 的自动记忆编译器。E.W. 表示，React Forget 意味着，开发者不再需要使用 useMemo/useCallback。

“在 React Native EU 上，我们表示，从 0.73 版本开始，我们会把 Web 开发者熟悉的 Chrome 开发工具移植到 React Native 中，”E.W. 补充道。“我们还共享了我们对 Static Hermes 的研究，它是我们的 JS 原生编译器，它不仅有可能加快 React Native App 的速度，还能从根本上改变 JS 的有效用途。”

Next.js：正在运行的新编译器

Next.js 推出了一款新的 App 服务器，旨在支持去年的 RSC（React 服务端组件）和 SA（服务端操作）。Vercel 的产品主管 L.R. 表示，它会继续支持旧版的 App 服务器，并且它们的路由系统是可互换的。这种互操作性意味着，开发者可以把时间花在添加新功能上。

“有些客户已经使用 Next.js 开发了五六年，它们采用这些新功能也需要多年时间，”L.R. 讲道。“我们希望让大家尽可能顺利地度过这段旅程。”

新的一年里，Next.js 想要解决一大坨问题，但其中一个优先事项可能是简化缓存。它说，就开发体验而言，这可能会更容易。

“通常情况下，生态系统中的一大坨开发者必须引入一大坨额外软件包，或学习如何使用其他工具来请求、缓存和重新验证，”L.R. 说。“Next.js 现在已经内置了一大坨十分给力的同款功能，但这也意味着，大家需要学习其他东西，目前用户初步的反馈是，‘这很棒棒哒；它十分给力，但如果能更简单一点的话，我们会不吝赞词。’”

Next.js 团队还会继续关注性能优化，它称之为“我们的持续投资”。

它补充道，这可能会在新年里以新编译器的形式出现，这将加快在开发者的机器上启动 Next.js 的速度。该编译器已经投入使用了大约一年，Vercel 一直在内部将其用于其产品和 App。它说，由 Rust 提供支持的编译器，在无缓存的情况下比以前有缓存的编译器更快。

L.R. 说：“我们推出该功能指日可待，大家都可以默认启动它，而且它比现存的 Webpack 编译解决方案更快。” “开发者希望它们的工具更快。它们永远不会抱怨它变得更快。因此，很有趣的是，可以看到工具作者，而不是工具的用户，而是实际的工具开发者转向 Rust 等较低阶的工具，帮助斩获咫尺之间的性能优势。”

目标三是继续为 Next.js 的未来 10 年奠定基础。

“你知道的，这个新的路由系统显然让我们十分鸡冻。我们相信这是未来的基础，”它说。“但这也需要时间。大家会尝试，用户会提出功能请求，它们会希望看到事情发生改变。我们认为这是未来五到十年的一项非常长期的投资。”

它补充说，“有一天”但可能不是今年的目标是，寻求一种更棒的方案来处理 Next.js 内部的内容。

“今天，它能奏效，我们仍然可以连接到想要的任何内容源，但存在某些方案可以简化开发体验，”它补充道。“与其说这是一项要求，不如说是一种美好的享受，这就是为什么私以为我们无法在新年实现此目标，但我想在未来用它搞点事情。”

Angular：可选的 Zone.js

谷歌 Angular DevRel 技术主管兼经理 M.G. 表示，在过去的一年里，Angular 的两大成就是：

• 
  
• 引入了 Signal（信号）的细粒度响应性
  
• 引入了可延迟视图
  

它讲道，明年会在此基础上，进一步关注细粒度响应性，并使 Zone.js 成为可选选项。

在 Angular 中，Zone 是跨异步任务持续存在的执行上下文。Zone 的 GitHub 仓库对此进行了详细解释，但 Zone 有五大职责，包括但不限于拦截异步任务调度和包装错误处理的回调，以及跨异步操作的 Zone 追踪。Zone.js 可以创建跨异步操作持久存在的上下文，并为异步操作提供生命周期钩子。

“我们正在探索为现存项目启用可选的 Zone.js，开发者应该可以通过重构现存 App 来利用该功能，”M.G. 如是说。“诉诸可选的 Zone.js，我们期望优化加载时间，并提升初始渲染速度。研究细粒度响应性将其提升到另一个水平，使我们能够只检测组件模板的局部变化。”

它说，这些功能将带来更快的运行时间。

在另一个性能游戏中，Angular 正在考虑是否默认启用混合渲染。它补充说，可以选择退出混合渲染，因为它会增加托管要求和成本。

“我们瞄到了 SSG（静态站点生成）和 SSR（服务端渲染）的巨大价值，凭借我们在 v17 中奠定的坚硬基建，我们正在努力进行最后的润色，以便从一开始就实现这种体验，”M.G. 如是说。

它补充道，另一个优先事项是落实 Signal 的征求意见。

开发者还可能会见证 Angular 文档的改进。根据其开发者调查，开发者希望享受进阶的学习体验，其中一部分包括使 Angular.dev 成为 Angular 的全新官网主页。它补充道，开发者还优先考虑了初始加载时间（混合渲染、部分水合和可选的 Zone.js 部分应该解决此问题），以及组件创作（Angular 计划进一步简化组件创作）。

“我们致力于可持续迭代功能，并与时俱进地渐进增强它们，”M.G. 讲道。“开发者将能够从新年里的所有优化中受益，并将在接下来的几年中享受更好的开发体验和性能。”

Solid：聚焦原语

“Solid 之父”R.C. 表示，Solid 开发者可以关注新年的 SolidStart 1.0 和 Solid.js 2.0。SolidStart 是一个元框架，这意味着，它构建于 Solid.js 框架之上。它说，它相相当于 Svelte 的 SvelteKit。

SolidStart 的官网文档是这样解释的：

“Web App 通常包含一大坨组件：数据库、服务器、前端、打包器、数据请求/变更、缓存和基建。编排这些组件极具挑战性，并且通常需要跨 App 堆栈大量共享状态和冗余逻辑。进入 SolidStart：一种元框架，它提供了将所有这些组件万法归一的平台。”

由于 SolidStart 仍处于测试阶段，R.C. 基本上有机会使用生态系统中已有的内容来使其变得更好。

“其中一个重要的部分是，我们现在不再编写自己的部署适配器，而是使用 Nitro，它也为 Nuxt 框架提供支持，这让我们可以部署到所有不同的平台，”R.C. 讲道。

另一个例子是，任何 Solid 路由器都可以在 SolidStart 中奏效。

“这意味着，对路由器的底层部分大量更新，这样它们能够“梦幻联动”，但我非常满意的最终结果是，我们的志愿者小团队需要维护的代码更少了，而且它为开发者提供了很大的灵活性和控制力，”它说。“它们不会被迫采用单一的解决方案，这对我而言兹事体大，因为每个人都有自己的需求。正如我所言，如果您构建正确的基建，并弄清楚这些构建模块是什么，大家可以做更多的事情。”

它说，最终的结果是一个具有“可交换”部分的元框架，而且不太我行我素。在越来越多的元框架决定开发者技术方案的世界中，Solid 团队一直在思考正确的原语片段的影响。

“于我而言，它始终是关于构建基元块，这是一个非常工程化的焦点，我认为这是它与众不同的部分原因，”它说。“我一直喜欢提供选择，而且私以为如果我们有正确的原语、正确的片段，我们就可以构建正确的解决方案。”

它表示，Solid 2.0 应该会在新年中后期的某个时间点发布。它说，目前它们正在设计如何处理异步系统的原型。

“Solid 2.0 也将是重量级版本，因为我们正在重新审视响应式系统，并研究如何解决异步 Signal 或异步系统，”R.C. 讲道。

它补充道，Solid 试图平衡控制与性能。

“我们的社区中有一大坨热心人，它们非常有技术头脑，既关心性能，也关心控制，”它说。“我们确实吸引了一大坨自己真正想要控制构建的方方面面的用户。”