全栈框架未来会如何发展？

不重新发明轮子

作为软件开发人员，我们都熟悉“不要重复发明轮子”这句话。然而，我听说很多人抱怨 JavaScript 世界似乎恰恰相反。😂

从积极的角度来看，几乎从底层到顶层，每个层面都总是有大量的选择： 

• 运行时：Node.js、Deno、Bun
• 包管理器：npm、pnpm、yarn
• 打包工具：Webpack、Rollup、Parcel、Vite、Turbopack
• UI框架：React、Vue、Svelte、Angular
• 全栈框架：Next.js、Remix、Nuxt、Sveltekit

不利的一面是，开发者，尤其是经验不足的开发者，可能会感到不知所措，陷入各种选择的漩涡之中。最近 Remix 和 Next.js 阵营之间的争论就很好地说明了这一点：

我为什么不使用 Next.js

我为什么使用 Next.js

尽管有不少功能齐全、设计精良的框架，例如RedwoodJS、Blitz和Create-T3-App，它们已经为你准备好了一切，但你仍然需要在它们之间做出选择，并希望它们在未来能够保持主流地位并得到良好的维护。那么我们应该如何选择呢？

在《高效能人士的七个习惯》这本书中，最让我产生共鸣的习惯是第二个：

以终为始

当我们发现自己目前缺乏清晰的愿景时，一个有效的策略是设想该框架在未来可能会发展成什么样子。

未来框架的特点

数据层的抽象

贝佐斯曾说过一句关于亚马逊成功的名言：

所以现在人们想要快速的配送。而且10年后，他们会想要更快的配送……所以这在今天和未来都至关重要。

这意味着要专注于那些不变的事物。尽管技术和方法不断变化发展，但存储、管理和检索数据的基本需求始终存在。因此，你仍然至少需要一个数据库来实现这些目标。

即使现在，愿意直接与数据库交互，处理复杂的 SQL 查询和数据库模式管理的全栈开发人员也越来越少，更不用说前端开发人员了。因此，ORM 已经成为现有框架的标准工具包。例如，上面提到的三个框架都采用了Prisma ORM。

此外，在考虑应用程序扩展时，人们通常会想到代码的复杂性。然而，实际上，底层数据层往往才是扩展问题的根源。如果数据层与应用程序代码紧密耦合，随着应用程序的增长，数据实体之间的关系会变得越来越复杂，难以管理。在前端和后端紧密耦合的全栈环境中，这一挑战尤为突出。因此，ORM提供的抽象层能够确保应用程序不同层之间的一致性，并促进前端和后端之间的高效通信。

减少代码编写并利用代码生成

编写更少的代码不仅可以节省开发人员的时间和精力，还可以使应用程序更易于扩展和维护：

一百行代码比一千行代码更容易扩展。

这正是框架的作用所在，它可以处理以前由我们自己实现的更多事情，例如路由、数据获取、渲染错误处理等等。

“减少样板代码”几乎成了所有框架的口号。它们通常会提供 scaffold CLI 来为你生成各种东西，包括以前被认为是必不可少的 API。

由于 ORM 已经定义了数据模型（包括数据类型、关系和约束），它可以自动生成有意义的 API。这使得开发人员能够腾出更多精力专注于业务逻辑，而不是耗费在手动实现 API 上。

例如，RedwoodJS 使用 Prisma 生成的类型来生成 GraphQL API。如果您使用的是基于 Prisma 构建的ZenStack ，它可以生成 RESTful 风格和 RPC 风格的 API，并带有 Swagger 文档或 tRPC 路由。

人工智能领域更具声明式编程

奥地利经济学家 约瑟夫·熊彼特最著名的贡献在于提出了“创造性破坏”这一概念，它描述了随着时间推移，新的创新取代旧创新、导致旧技术过时的过程。我们可以这样类比：

无论对旅行车进行多少改进，它永远也成不了轿车。

既然我们正在讨论下一代框架，我们希望看到一些能够显著提高生产力的创新，就像从马车到汽车的飞跃一样。

究竟是什么强大的力量促成了这一切？看看YC W24新一批学员的名单，你就会找到答案😄

YC创业公司名录 | Y Combinator

是的，绝对是人工智能。我认为框架越是声明式，人工智能就越能理解应用程序，并尽可能地辅助其操作。原因在于，声明式方法是一种通过描述你想做什么而不是如何做来编写代码的范式。这正是我们每天与 ChatGPT 交流的方式。

您可以在声明式框架Wasp中找到一个概念验证示例：

MAGE GPT Web 应用生成器 ✨ MageGPT

当然，这些只是我认为比较重要的几个方面。我很想听听你们的想法或不同的观点。欢迎留言或在推特上联系我！