JavaScript 框架 - 迈向 2025 年

我承认，我不确定今年会不会写这篇文章。写一些让人们对新技术的潜力感到兴奋的文章很容易。但2024年是接受现实的一年。

过去几年，我们一直在探索未知。我们满怀兴奋地迈入新的一年。这些进步终于到了需要进一步完善的时候了。它们确实做到了。但有一点非常明确：

对简单性的追求并没有使 Web 开发变得更简单。

显然，有些事情变得更容易做了，但整体情况并没有简化。我们早就知道这一点。但2024年发生了一些变化，部分原因是全球经济紧缩预算的压力，迫使解决方案走安全之路。我认为，人们终于认识到，没有灵丹妙药。难题本身就很难解决。

不仅仅是工具复杂，问题也复杂。在回归基础的过程中，我们遇到了各种障碍，最终只能重新发明轮子，才能回到那个根本的地方。

这个想法令人警醒，但它也给了我希望，让我们在2025年花些时间重新评估。而这始于对2024年的反思。

服务器的承诺

过去五年来，“服务器优先”一直是前端的主流理念。这并不是什么新概念，Web 诞生于服务器，但在经历了十年以客户端为中心的单页应用之后，很明显，这种模式已经走得太远了。尤其对于那些页面加载敏感的网站来说，提升交互性并没有给它们带来太多好处。

疫情加剧了这一趋势，一方面是因为网购习惯的兴起，另一方面是因为低利率驱动的资本涌入。结果，我们涌现出一系列新的服务器优先元框架，例如 SvelteKit、Astro、Remix、SolidStart、Qwik、Fresh 和 Analog，同时对 Next 和 Nuxt 等现有框架也进行了重大升级。

过去几年，受 SPA 影响的同构方法（相同代码在客户端/服务器端运行不同）与受 MPA 影响的拆分执行方法（岛/服务器组件）相互较量，力图找到一个通用的解决方案。这如同两个对立面试图在中间妥协。这促成了路由领域的惊人发展，例如 Next App Router 和 View Transitions Routing，以及乱序流、服务器函数、乐观更新、服务器岛和单次突变等技术的发展。即便如此，两者之间的差距仍然比任何人想象的都要大。

当你把所有这些特性组合在一起时，事情就不再那么简单了。我们是否解决了最初设定的问题，这一点也值得商榷：

衡量成功极其困难。我们见过一些基准测试失败的例子：

我们看到，人们把业绩的提高归功于新技术，但根本原因却在别处：

由于不想费力地处理这些乱七八糟的事情，讨论又回到了更传统的服务器端方法。那些存在于“SSR”之外的方法。那些你不需要在服务器上运行客户端 JavaScript 框架的方法。对于那些有意义的项目来说，这一直是一个不错的选择。但它也没什么意思。

如果不需要改进之前的方法，我们就不会取得今天的成就。而这可能需要大量的反复尝试。最简单的工具才是正确答案，但当问题不再简单时，你就会想要能够随心所欲扩展的选项。

如果说 2021/22 是重置到一个更简单的基础，回到我们在服务器上的起点，那么 2024 年则提醒我们，简单并不总是可行的。

汇编来拯救

编译是 JavaScript 开发中始终存在的一个环节。每当我们遇到障碍时，无论是浏览器功能支持、语法繁琐，还是语言缺陷的解决能力不足，我们都会构建一个编译器来解决这个问题。

它如今已无处不在，标准委员会正在考虑朝这个方向引入新功能。编译和通过扩展打包是现代 JavaScript 应用程序创建的核心。它也是 JavaScript 工具中最复杂的根源。

它的好处数不胜数。类型、Lint、Treeshaking、代码拆分、代码压缩、同构、宏、DSL、单体开发/分布式部署等等。过去15年里，该领域的每一项进步都建立在这个基础之上。相比之下，没有任何替代方案能够与之匹敌。你可以说它不幸，也可以说它是JavaScript语言的局限性，也可以说它必然带来的复杂性。但否认这一点是徒劳的。

然而，如果我们想要理解复杂性，至少要了解它的来源。2024 年最有趣的发展，很大程度上要归功于 React Compiler 和 Svelte 5 Runes 的发布，那就是讨论变得多么混乱。

一方面，我们有 React Compiler，一个自动优化的编译器，它以一种无需人工干预的方式转换代码，从而减少不必要的重复执行。其原理与 2019 年发布的 Svelte 3 编译器非常相似。另一方面，我们有 Svelte 5 Runes，它为细粒度的 Signals 渲染器添加了语法糖，类似于 SolidJS 在 2018 年发布的版本。

这两个主要的编译器项目截然不同，令人质疑它们的根本性质。React 承认重新渲染确实很重要，值得优化。Svelte 放弃了其极简语法，转而采用一种更具表达力、功能更强大、性能更佳的语言。讽刺的是，这两种立场都与它们最初的卖点截然相反。

有趣的是，与现有方法相比，这两种选择都是以增加工具复杂性为代价的。

这些举措最终是否会对这些项目有益，目前尚无定论。共同点在于，随着我们尝试创建简化开发的解决方案，我们所依赖的基础也变得越来越复杂。

人工智能和开发工具

如果说编译和打包是基础，那么现在显然它们也是为 AI 提供未来创建高度动态解决方案所需工具的基础部分。虽然我们每年都看到这些工具在改善本地开发者体验方面发挥着越来越大的作用，但 AI 对 JavaScript 框架本身的影响仍然微乎其微。

今年年初，我们看到 Devin 因开发一些简单的应用程序而登上头条新闻。但这也引发了人们对这项技术的期待。它只是功能性强就够了吗？还是必须足够好用？

从这个意义上来说，像 Vercel 的 v0 这样的技术在创建原型方面基本上是成功的。或许，这才是目前最大的优势所在。

MillionJS 开发人员 Aiden Bai 再次引起了我们的注意，其 React Scan 可以扫描您的应用程序以查找性能问题。

虽然有人可能会认为重新渲染并不一定意味着存在问题，或者在 React 中寻找重新渲染就像瓮中捉鳖，但它确实让我看到了即将到来的开发工具的潜力。

如果任务复杂，核心工具也更加复杂，那么支持工具的出现就显得理所当然。这不仅仅是开发流程的左移。这种需求是在整个开发过程中完全集成的。虽然 Biome（以及之前的 Rome）设定了这一目标，但像 VoidZero（由 Vue/Vite 创始人尤雨溪创建）这样的新玩家表明，这一基础对于未来的发展至关重要。

期待

服务器秒

随着 Sveltekit、SolidStart 和 Remix 中 SPA 模式的出现，我们已经开始看到钟摆在 2024 年中期回摆的迹象。Remix 将其非服务器功能移植回了 React Router。SolidStart 对服务器函数和单次飞行突变的附加方法最终为 Tanstack Start（一个基于相同原则构建的 React 框架）奠定了基础。

我们还看到了本地优先/同步引擎技术的蓬勃发展。这种趋势将如何体现还有待观察，但我预计这种趋势将持续到2025年。

稳扎稳打才能赢得比赛

今年 JavaScript 调查结果让我印象深刻的一点是，尽管人们对我们工具的不满情绪日益高涨，但有些人的积极性却有所提升。这与留存率（满意度）略有不同，后者侧重于工具的现有用户，面向规模较小的用户（SolidJS 和 Svelte 多年来一直位居榜首）。

它们并非我经常谈论的工具，但当经济紧张且维护成为问题时，它们往往会大放异彩。Vue 和 Angular 都是我明年会关注的框架。这并不是因为我期待被这些创新惊艳到，而是因为这些工具在提升开发者满意度方面付出了额外的努力。有时候，最好的工具并非“最好”的工具。

信号成长的烦恼

现在几乎所有非 React 框架都运行着 Signals，这已不是什么秘密。但随着时间的推移，开发者们开始理解其中的利弊权衡。虽然笔者个人认为这些都是小问题，但我确实希望大家能够重新认识 React。他们或许早就应该拥有这种认识，但这并不能成为 React 任何缺陷的借口。但一切都是一系列的权衡，只有理解了两者的利弊，你才能真正珍惜自己做出的选择。

话虽如此，信号仍在不断发展。过去几年，该领域的集体经验已大幅增长。我预计，明年这些小型创新的集体成果将以我们从未见过的方式展现这种方法的独特价值前景。

Web 组件

...只是在开玩笑。

结论

与往年不同，我并不预测未来12个月会出现什么重大的技术飞跃。我不知道整个社区是否会接受这一点。我看到讨论的焦点从可恢复性与部分水合是否合理，再次转移到谁拥有最佳的模板语法。这是周期的一部分，它有助于反思和创新。但不是今天。没关系。

我们需要应对诸多复杂性。我们需要做出许多艰难的抉择，决定哪些技术值得我们投入和投入。下一代解决方案的原始功能现已具备，但我不确定我们是否已经看到了可供消费的正确组件组合。但至少我们开始意识到，在追求简化的过程中，我们走上了一条以新方式重新增加复杂性的道路。

单一的解决方案尚未显现。HTMX​​ 不会统治世界，但它是一个不错的选择。React 的实现并不一定比其他解决方案更复杂。异步和客户端/服务器交互本身就很复杂。编译器无法解决所有问题，但它们可以做很多事情：

我们生活在一个充满复杂性的世界，而且这种情况短期内似乎不会改变。所以，2025年似乎是个安心埋头苦干的好时机。

对于那些正在寻找下一个伟大事物的人来说，环顾四周吧。有很多有趣的问题有待解决。说实话，这正是我蓬勃发展的环境。