2024年前端的前景如何？

公众号：程序员白特，*********

2024 年前端的前景如何？自从我们打破了前后端不分离的局面以来，The New Stack 与来自 React、Next.js、Angular 和 Solid 的创建者和维护者讨论了他们 2024 年的计划。以下是前端开发人员在未来一年可以期待的概述。

React：2024 年预览

Meta 的 React 工程经理 Eli White 表示，React 团队预计在新的一年里会有更多的框架采用 React Server Components。

“对于大多数人来说，RSC 对他们所认为的 React 的范围来说是一个重大变化，从只是一个 UI 层到对你构建应用程序的方式产生更大的影响，以获得最佳的用户体验和开发人员体验，特别是对于 SPA（单页应用程序）不够好的应用程序，”White 说。

虽然他没有具体说明 2024 年的任何新进展，但怀特确实表示他们将在 2023 年的一些启示上发布和分享更多进展。例如，在 React Advanced 大会上，该团队向与会者展示了 React Forget，它是 React 的自动记忆编译器。White 说，React Forget 将意味着开发人员不再需要使用 useMemo 和 useCallback。

“在 React Native EU 上，我们分享说，从 0.73 开始，我们将 Web 开发人员熟悉的熟悉的 Chrome 开发工具引入 React Native，”White 补充道。“我们还分享了我们对 Static Hermes 的研究，Static Hermes 是我们的 JavaScript 原生编译器，它不仅有可能加速 React Native 应用程序，而且从根本上改变了 JavaScript 的有效用途。”

Next.js：新的编译器正在工作

Next.js 在 2023 年推出了一个新的应用服务器，旨在支持 React 服务器组件 （RSC） 和服务器操作。它继续支持旧的应用程序服务器，它们的路由系统是可以互换的，负责监督该框架的Vercel产品主管Lee Robinson说。这种互操作性意味着开发人员可以花时间添加新功能。

“有些客户已经使用 Next.js 构建了五六年，他们采用这些新功能也需要数年时间，”Robinson 说。“我们希望尽可能顺利地带动人们的旅程。”

在新的一年里，Next.js 想要解决许多问题，但一个优先事项可能是简化缓存。他说，就开发人员体验而言，这可能更容易。

Robinson说：“通常情况下，生态系统中的许多开发人员必须引入一堆额外的软件包，或者学习如何使用其他工具来执行获取、缓存和重新验证。“Next.js 现在已经构建了很多这样的功能，这非常强大，但这也意味着你需要学习其他东西，最初的反馈是，'这太棒了;它非常强大，但如果它更容易一点，我们会很高兴。

Next.js团队还将继续专注于性能改进，他称之为“对我们的持续投资”。

他补充说，这可能会在新的一年里采用新的编译器的形式，这将加快在开发人员的机器上启动Next.js所需的速度。编译器已经工作了大约一年，Vercel 一直在内部使用它来开发其属性和应用程序。他说，由 Rust 提供支持的编译器在没有缓存的情况下比以前的编译器在缓存时更快。

Robinson说：“我们非常接近推出它，到每个人都可以默认打开它的地步，而且它比现有的Webpack编译解决方案更快。“开发人员希望他们的工具更快。他们永远不会抱怨它更快。因此，有趣的是，看到工具制造商，而不是工具的用户，而是实际的工具开发人员转向这些较低级别的工具，如 Rust，以帮助获得最后一英里的性能胜利。

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

“这个新的路由系统，你知道，我们显然对此感到非常兴奋。我们相信这是未来的基础，“他说。“但这也需要时间。人们会尝试，他们会有功能请求，他们会希望看到事情发生变化。我们认为这是未来10年的一项非常长期的投资。

他补充说，“有朝一日”但可能不是今年的目标是一种更好的方式来处理Next.js中的内容。

“今天，它可以工作，你仍然可以连接到任何你想要的内容源，但有一些方法可以简化开发人员的体验，”他补充道。“与其说是要求，不如说是件好事，这就是为什么我认为我们不会在 2024 年实现它，但我想在未来用它做点什么。”

Angular: Optional Zone.js

在过去的一年里，Angular 的两大成就是引入了 Signals 和可延迟视图的细粒度响应性，Google Angular DevRel 的技术负责人兼经理 Minko Gechev 说。他告诉The NewStack，明年将在此基础上进一步关注细粒度的反应性，并使Zone.js成为可选。

在 Angular 中，区域是跨异步任务持续存在的执行上下文。此 GitHub 存储库中详细介绍了区域，但区域有五项职责，包括拦截异步任务调度和包装回调以进行错误处理和跨异步操作的区域跟踪。Zone.js 可以创建跨异步操作持久存在的上下文，并为异步操作提供生命周期挂钩。

“我们正在探索为现有项目启用可选的Zone.js，开发人员应该能够通过重构现有应用程序来利用该功能，”Gechev说。“有了可选的 Zone.js，我们期待加载时间的缩短和更快的初始渲染。在细粒度反应性方面的工作将其提升到另一个层次，使我们能够仅检测组件模板部分的变化。

他说，这些功能将导致更快的运行时间。

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

Gechev 说：“我们看到了 SSG（静态站点生成）和 SSR（服务器端渲染）的很多价值，凭借我们在 v17 中奠定的坚实基础，我们正在努力进行最后的润色，以便从一开始就实现这种体验。

他补充说，另一个优先事项是履行其信号征求意见。

开发人员可能还会看到 Angular 文档的改进。根据其开发人员调查，Gechev 开发人员希望获得升级的学习体验，其中一部分包括将 Angular.dev 作为框架的新家。开发人员还优先考虑初始加载时间——他补充说，混合渲染、部分水化和可选的 Zone.js 部分应该解决——以及组件创作，Angular 计划进一步简化。

“我们致力于以迭代方式交付功能，并随着时间的推移逐步增强它们，”Gechev 说。“开发人员将能够从 2024 年的所有改进中受益，并将在未来几年获得更好的开发人员体验和性能。”

Solid：专注于基元

根据Solid创建者Ryan Carniato的说法，Solid开发人员可以在1年关注SolidStart 0.2和Solid.js 0.2024。SolidStart是一个元框架，这意味着它建立在Solid.js框架之上。他说，它可以与 Svelte 的 SvelteKit 相媲美。

SolidStart 的文档是这样解释的：

“Web 应用程序通常包含许多组件：数据库、服务器、前端、打包器、数据获取/突变、缓存和基础设施。编排这些组件具有挑战性，并且通常需要跨应用程序堆栈的大量共享状态和冗余逻辑。进入 SolidStart：一个元框架，它提供了一个平台，可以将所有这些部分放在一个位置。

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

Carniato 说：“其中最重要的一点是，我们现在使用 Nitro，而不是编写我们自己的所有部署适配器，它也为 Nuxt 框架提供支持，这使您可以部署到所有不同的平台。

另一个例子是任何 Solid 路由器都可以在 SolidStart 中工作。

“这意味着对路由器的底层部分进行大量更新，以便它们可以协同工作，但我非常满意的最终结果是，我们的志愿者团队需要维护的代码要少得多，并且它为开发人员提供了很大的灵活性和控制力，”他说。“他们不会被迫采用单一的解决方案，这对我来说非常重要，因为每个人都有自己的需求。正如我所说，如果你构建正确的部分并弄清楚这些构建块是什么，人们可以做更多的事情。

他说，最终结果是一个具有“可交换”部分的元框架，不会太固执己见。Solid 团队一直在思考在越来越多的元框架决定开发人员使用什么的世界中，正确的原语部分的影响。

“对我来说，它一直是关于基元的构建块，这是一个非常工程重点，我认为这是它与众不同的部分原因，”他说。“我一直喜欢给出选择，我认为如果你有正确的基元，正确的类似部件，你就可以构建出正确的解决方案。”

他说，Solid 2.0 应该在 2024 年中后期的某个时候发布。他说，现在，他们正在对如何处理异步系统进行原型设计。

“Solid 2.0 也将是一个非常重要的版本，因为我们正在重新审视反应式系统，并研究如何解决异步信号或异步系统，”Carniato 说。

他补充说，Solid试图在控制与性能之间取得平衡。

“我们的社区里有很多非常热情的人，非常有技术头脑的人，他们关心绩效，关心控制，”他说。“我们确实吸引了很多真正想要控制他们所建造的每一个部分的人。