JavaScript 框架 - 迈向 2025 年-优快云博客

本文译者为 360 奇舞团前端开发工程师
原文标题：JavaScript 框架 - 迈向 2025 年
原文作者：Ryan Carniato
原文地址：https://dev.to/this-is-learning/javascript-frameworks-heading-into-2025-hkb

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

过去几年一直在探索未知，我们怀着激动的心情进入了今年。这些技术进步终于到了优化的阶段，而它们的确在不断完善，但有一件事是十分清楚的：

我们追求简单，但 Web 开发并没有因此变得更简单。

显然，有些事情变得更容易做了，但总体情况并没有简化。我们已经知道这一点。但 2024 年发生了一些变化，部分原因是全球经济收紧预算，使得技术选择更趋于稳妥。这让我觉得，人们终于开始承认，并没有银弹，困难的问题依然难以解决。

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

这是一个发人深省的想法，但它给了我希望，在 2025 年，我们可以花一些时间重新评估。这从反思 2024 年开始。

The Promise of the Server（Server-first）

图片描述

过去 5 年，前端一直强调“服务器优先”。这并不是一个新概念，Web 诞生于服务器，但经过十年以客户为中心的单页应用之后，很明显这种观点已经偏离正轨。尤其是对于页面加载敏感的网站，它们并没有从增加交互性中获益太多。

疫情只会加剧这一现象，因为在线购物习惯的兴起和低利率推动的资本涌入。结果，我们获得了大量新的服务器优先元框架，如 SvelteKit、Astro、Remix、SolidStart、Qwik、Fresh 和 Analog，以及对 Next 和 Nuxt 等现有框架的重大升级。

过去几年，受 SPA 影响的同构（相同代码可同时在客户端和服务器端运行）方法与受 MPA 影响的分层执行（Islands 架构/服务器组件）方法展开了较量，以期找到一种适用于所有情况的通用解决方案，这是一场两种对立架构试图相互靠拢的实验。导致了路由方面的惊人发展，例如 Next App Router 和 View Transitions Routing，以及无序流、服务器功能、乐观更新、服务器岛和Single-Flight Mutations（合并请求变更）等技术。但即便如此，差距仍然比任何人想象的都要大。

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

https://www.youtube.com/watch?v=nzbV0YgSBuo

衡量成功非常困难。我们已经看到过基准测试失败的情况：

图片描述 https://x.com/Rich_Harris/status/1828514851741933689?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1828514851741933689%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=

我们发现，人们把绩效归功于新技术，但根本原因却在别处：

图片描述 https://x.com/RyanCarniato/status/1818402060238565722?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1818402060238565722%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=

面对这一复杂局面，社区的讨论重新回到了更传统的服务器端架构。即那些不属于 "SSR" 的方式，也就是不在服务器上运行客户端 JavaScript 框架的方法。你可以说这是不幸的，也可以说是 JavaScript 语言的局限性，或者是必要的复杂性。但否认这一点是毫无意义的。

如果没有改进的需求，我们不会走到今天。而创新往往需要大量的试错。最简单的工具通常是最好的选择，但当问题变得复杂时，你需要的是能够随之扩展的解决方案。

如果说 2021/22 年是一次回归服务器端基础的重置，那么 2024 年则提醒我们，简单并不能解决所有问题。

通过编译（Compilation）来解决

图片描述

编译是 JavaScript 发展的常态。每当遇到障碍——无论是浏览器特性支持、冗长的语法，还是语言本身的缺陷，我们都会为其构建编译器。

如今，它已经变得无处不在，以至于标准委员会正在考虑通过编译方式引入新特性。编译和打包已经成为现代 JavaScript 应用的核心构建方式，同时也是 JavaScript 工具链复杂性的根源。

编译的好处是巨大的：类型检查、Linting、Tree Shaking、代码拆分、压缩、同构、宏（Macros）、领域特定语言（DSLs）、单体开发/分布式部署等。在过去 15 年里，这一领域的每一项进步都建立在这一基础之上。没有任何替代方案能达到相同的水平。这或许是 JavaScript 语言的局限，也或许是不可避免的复杂性，但无论如何，否认这一点是徒劳的。

然而，如果我们想理解复杂性，至少需要弄清它的来源。2024 年最有趣的发展之一，主要得益于 React Compiler 和 Svelte 5 Runes 的发布，让关于编译的讨论变得更加模糊不清。

一方面，React Compiler 是一个自动优化编译器，它能够减少不必要的重新执行，而无需手动干预。这与 2019 年发布的 Svelte 3 编译器非常相似。而另一方面，Svelte 5 Runes 通过新的语法糖，引入了一种类似于 SolidJS 早在 2018 年推出的细粒度信号（Signals）渲染模式。

这两个主要的编译项目走向了截然不同的方向，甚至挑战了它们自身的核心理念。React 终于承认，优化重新渲染是至关重要的。Svelte 放弃了其最基本的语法，转而采用一种表达能力更强、性能更好的语言。讽刺的是，这些立场都与它们最初的卖点完全相反。

图片描述 https://x.com/onlyspaceghost/status/1704497139131314638?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1704497139131314638%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=

而且，这两种选择都比各自现有的方法增加了工具链的复杂度。

最终，这些变革是否会为它们的生态系统带来正向影响，仍未有定论。但可以确定的是，尽管我们努力让开发变得更简单，我们构建的基础却越来越复杂。

AI 与开发工具

如果说编译和打包是现代 JavaScript 生态的基石，那么很明显，这些也将成为 AI 在未来构建动态解决方案的重要工具。AI 在提升本地开发体验上的影响已经越来越显著，但它对 JavaScript 框架本身的影响仍然有限。

今年早些时候，Devin 让人们看到了 AI 生成简单应用的潜力。但这也引发了一个问题：仅仅实现功能就足够了吗？还是说，应用还需要"优秀"

图片描述 https://x.com/RyanCarniato/status/1767652623640072658?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1767652623640072658%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=

在这个意义上，Vercel 的 v0 在原型构建方面取得了很大的成功，或许这才是 AI 目前最大的价值所在。

与此同时，MillionJS 开发者 Aiden Bai 推出的 React Scan 也引起了我们的关注，它能够扫描 React 应用，查找性能问题。

图片描述 https://x.com/aidenybai/status/1858543720788042121?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1858543720788042121%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=

尽管有人认为在 React 中查找重新渲染问题如同 "在鱼缸里打鱼"，但它确实让我看到了开发工具未来的潜力。

随着核心工具链变得更复杂，辅助工具的需求也在增长。未来，AI 在 JavaScript 开发中的角色，可能比我们现在想象的还要重要。

期待

Server-second

到了 2024 年年中，我们已经开始看到某种“钟摆效应”的回摆趋势，比如 SvelteKit、SolidStart 和 Remix 都在加强 SPA（单页应用）模式。Remix 甚至将其非服务器功能重新移植回 React Router。SolidStart 通过 Server Functions（服务器函数）和 Single-Flight Mutations（合并请求变更）构建了一种渐进式方法，这也为 TanStack Start 奠定了基础——这是一个基于相同原则构建的 React 框架。

图片描述 https://x.com/tannerlinsley/status/1861124006621184041?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1861124006621184041%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=

与此同时，本地优先（Local-first）和同步引擎（Sync Engine）技术的增长也值得关注。尽管它们的最终形态尚不明朗，但我预计这种趋势将持续到 2025 年。

稳扎稳打才能赢得比赛

图片描述今年在查看 JavaScript 调查结果时，有一件事让我印象深刻——在一片对工具日益增长的不满之中，一些工具的正面评价增长得比其他工具更明显。这与 Retention（满意度）指标略有不同，后者主要关注现有用户，并且更有利于小众工具（比如 SolidJS 和 Svelte 这些年一直在榜单前列）。

这些并不是我经常讨论的工具，但当经济环境紧张、维护成本成为关注点时，它们往往能脱颖而出。Vue 和 Angular 是我明年会特别关注的框架。并不是因为我期待它们带来颠覆性的创新，而是因为它们在提升开发者体验方面确实做得更进一步。有时候，最好的工具并不一定是“最强”的工具。

Signals的成长挑战

图片描述

现在几乎所有非 React 框架都基于 Signals 运行，这已经不是什么秘密了。但随着时间推移，开发者开始深入理解其中的各种权衡。尽管在我这个作者的主观看法中，这些问题都算不上什么大问题，但我确实预计，大家会对 React 产生新的认可。其实，这种认可本该一直存在，当然这并不意味着 React 没有缺陷。但所有技术选择都是一种权衡，只有当你真正理解两种方案的优缺点时，才能真正欣赏自己所做的选择。

话虽如此，Signals 仍在不断演进。过去几年，整个行业在这一领域积累了大量经验。我预计，未来一年里，众多小型创新的集合效应将展示出这种方法独特的价值主张，以前所未见的方式呈现出来。

Web Components

https://dev.to/ryansolid/web-components-are-not-the-future-48bh

结论

与往年不同，这次我并不预测在接下来的 12 个月里会有某种重大的技术飞跃。我不确定整个社区是否会对此持开放态度。我看到讨论已经从“Resumability 是否比 Partial Hydration 更合理”变成了“谁的模板语法更好”之类的话题。这是技术发展的周期之一，它让我们有机会反思，并在未来迎来创新。但至少今天不是那个时候，而这没关系。

我们需要追赶的复杂性还有很多，也需要做出很多艰难的决定，来判断哪些技术值得我们的投资和努力。下一代解决方案的基本能力已经存在，但我不确定我们是否已经找到合适的组合，使其以可消费的形式呈现。至少我们开始意识到，在追求简单性的过程中，我们其实在用新的方式重新引入复杂性。

目前还没有单一的终极解决方案。HTMX 并不会统治世界，但它是一个不错的选择。React 在完成任务时并不一定比其他方案更复杂。异步和客户端/服务器交互本身就是一件复杂的事情。编译器无法解决所有问题，但它们确实可以解决很多问题：

图片描述 https://x.com/RyanCarniato/status/1795501182024323316?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1795501182024323316%7Ctwgr%5E%7Ctwcon%5Es1_c10&ref_url=