2022 年最受欢迎的 Node.js 框架

Express.js 与 Node.js 一样古老，虽然 Express 仍然是一个了不起的后端框架，但一种新型的工具和套件正在留下它的印记。

最值得注意的是，趋势已经转向元框架，其中像 React 这样的流行框架被重新用于支持全栈开发。 这种方法的优点是您可以在特定框架中保持您的专业知识，同时处理后端工作。 换句话说，做全栈开发。

这些数据是如何获得的？

所有数据均来自 JavaScript 状态、Stack Overflow 开发人员调查等调查，以及与各种项目合作的个人经验。 这不是基于哪个 Node.js 框架拥有最多 GitHub 星数的评论。

相反，我比较了过去一年获得的星星数量。 这是某个项目的活跃程度以及开发人员对其响应程度的可靠指标。

 如果您想在实时环境中尝试这些框架中的任何一个，请查看我关于面向开发人员的托管平台的文章。 每个平台都有一个免费计划，几乎所有平台都允许您导入 GitHub 存储库并直接托管它。 

例如，您可以在几分钟内获取任何 repo 并使其生效。

当前的 Node.js 趋势

您会在这篇文章中注意到，本文中提到的许多框架都是基于前端框架的。 这也称为元框架。 那么，这是怎么回事，为什么要采用这种方法呢？

如果我们看一下 React 之类的东西，它呈现页面的方式是通过 CSR（客户端呈现）完成的。 一旦发出请求，浏览器就会得到一个没有实际页面内容的准系统 HTML 文件。 因此，浏览器进行第二次循环以获取包含页面内容的 JavaScript 文档，然后传递它并呈现实际页面。

每次用户与页面交互时，这种情况都会继续发生。 即使 HTML 保持原样，不同的路由请求意味着浏览器必须不断来回呈现用户想要的内容。

这通常也称为 SPA 或单页应用程序。

以下是这种 CSR 方法的缺点：

• 缓存- 由于所有页面内容都是通过 JavaScript 呈现的，因此页面上没有可以缓存的实际 HTML 内容。
• 搜索引擎优化——虽然爬虫变得“更聪明”，但机器人索引内容完全依赖于 JavaScript 存在明确的问题。
• 渲染——在所有 JavaScript 加载完成之前，初始渲染通常很慢且无响应。

所以，在这种情况下，像 Next 和 Nuxt 这样的框架背后的想法是采取前端框架，但通过 Node.js 给它 SSR（服务器端渲染）。

说到 SSR——Nick Johnstone 发表了一篇有趣的文章，题为“服务器端渲染的荒谬复杂性”。 还有一个相应的 Hacker News 线程，对这个话题进行了很多讨论。 虽然在不久的将来不会有太大变化，但我相信其中一些概念将推动一些框架的运作方式发生重大变化。

#1 – Next.js

不仅仅是一个 React 框架——Next.js 的流行度不断增长，这要归功于其高得离谱的开发速度。 Next.js 10 到 Next.js 12 只用了一年时间。

Next.js 背后的核心概念是它以 React 为基础，但通过自己的规范执行所有服务器端渲染结构。 因为渲染是在服务器端完成的，所以您不必在客户端渲染页面，从而提供巨大的性能优势和相关的 SEO。

Next 如此大规模采用的原因之一是它消除了构建您自己的后端的需要。 同时，提供有意义的方法来优化您的应用程序的性能，开箱即用。 Vercel 维护它。

#2 – 巢穴

NestJS 已经悄悄地吸引了后端社区的大量认可。 Nest 背后的主要理念之一是，虽然像 React 这样的框架加速了前端开发，但许多这样的框架都在努力解决应用程序架构问题。 Nest 通过架构优先的方法解决了这个问题。

当然，这是特定于后端的。

Nest 基于三个核心组件（受 Angular 启发）—— Controllers 、 Providers和Modules 。 模块的使用是 Nest 试图解决复杂应用层次结构问题的方式。 每个组件都可以分类在一个单独的模块中，您可以在其中配置自己的控制器、依赖项和特定的提供程序。

#3 – 绑带

Headless 在当前的前端叙事中风靡一时。 Strapi 在将自己定位为领先的 Headless CMS 框架之一方面做得很好。

那么，什么是 Strapi？ 在最实用的术语中，Strapi 是您前端应用程序的后端。 从某种意义上说，Strapi 消除了您学习 Express 之类的框架的需要，因为它可以通过其 API 完成大部分的跑腿工作。

这包括通过自定义 UI、GraphQL 和 REST 的动态端点、用户管理（角色等）以及您可以构建的单独插件界面来管理您的内容。 Strapi 完全与框架无关，几乎可以与任何语言、框架或前端库集成。

#4 – 混音

Remix 是由制作 React Router 的人构建的全栈框架。

我相信 Remix 也是我们近年来看到的增长最快的全栈框架之一。 那么，怎么来的？ 一方面，Remix 试图通过为常见状态代码和用户交互提供简洁的 API 来尽可能地与 Web 标准集成。

与传统框架不同，Remix 不会创建基于瀑布（组件）的结构。 相反，数据在服务器端并行加载，然后作为 HTML 页面提供。 这也意味着如果用户禁用了 JavaScript，基于 JavaScript 的功能（如表单提交）不会破坏网站。

#5 – 努克特

Nuxt 3（适用于 Vue 3）处于公开测试阶段：请留意。

Nuxt 构建在 Vue 之上，作为构建健壮应用程序的全栈框架。 它也是一个元框架，旨在极大地改善全栈 Vue 开发的体验。 Nuxt 支持 SSR、SPA 和静态生成页面。

Vue 开发人员的主要优势是 Nuxt 可以预渲染视图并将它们作为静态文件提供。 这自然对 SEO 优化有很好的效果，并显着提高了交互性。 但也有一些缺点。

Vue 有一个持久的客户端通道，而 Nuxt 没有。 因此，在 Nuxt 已经呈现页面之后与 DOM 交互可能会很困难。

#6 – SvelteKit

Svelte 在当前前端时代具有酷孩子的地位，团队正在开发 SvelteKit——一个建立在 Sapper 之上（取代它）的全栈框架。 SvelteKit 以复杂的基于文件的路由系统脱颖而出。

SvelteKit 的主要目标是通过消除一些更常见的瓶颈来加速 Web 开发。 通过实现 Snowpack、Vite 和其他外部工具——SvelteKit 可以提供功能丰富的开发体验。

最后，SvelteKit 实现了 Hydration 的过程。 为已在服务器端渲染的 DOM 元素保留活动状态的能力。

#7 – Fastify

Fastify 框架是关于性能的，单独的基准测试表明它每秒可以处理多达 60,000 个请求。 你可以通过 Hooks 和 Plugins 扩展 Fastify（在已经很棒的工具之上）。 而且，尽管不是 TypeScript 优先的框架，Fastify确实支持 TypeScript。

说到插件，很多 Fastify 开发都是通过它们进行的。 如此之多，以至于 Fastify 拥有一个官方存储库，用于存放社区制作和 Fastify 团队制作的插件。 插件背后的想法是它提供了一个干净的系统架构，并且不需要跳转到替代框架。 这使得 Fastify 在构建具有强大实时性能的低开销 API 时特别有用。

#8 – 红木

你喜欢 API 吗？ 你喜欢 JAMStack 吗？ 如果答案是肯定的，那么您会爱上 RedwoodJS。 它是一个使用大量现代技术的全栈 Web 应用程序框架。 这些技术包括 GraphQL、Prisma、Storybook 和 Jest。 Redwood 的前端是建立在 React 之上的，您还可以获得全面的 TypeScript 支持。

#9 – 快递

Express已经失宠了吗？ 不完全是。 该框架仍然非常受欢迎和喜爱，只是没有其他大玩家那么多。 对于一个使用 Express 多年的团队来说，切换到其他东西是没有意义的，因为没有任何基本问题。 许多框架仍然建立在Express 之上。

#10 – 阿多尼斯

Adonis 是为 Node.js 构建的 TypeScript-first 后端 MVC 框架。 请记住，尽管 Adonis 将自己描述为一个后端框架，但使用它进行全栈开发也同样适用。

开发人员喜欢 Adonis 的主要原因之一是它对 TypeScript 的原生支持。

而且，支持 ORM（对象关系映射）、强大的安全实践和易于理解的文档。

最后但并非最不重要的一点是，Adonis 在基础层面上与 Node.js 生态系统集成，因此拥有 Node 开发经验是必不可少的。

#11 – 基石

此列表中的最后一个 Node.js 框架是 Keystone。 就像 Express 一样，它几乎从第一天就已经存在。 这使得 Keystone 成为一个成熟的框架，提供具体的工具和集成来创建对开发人员友好的体验。

Keystone 中的一些显着特性（其中许多已经经过多年改进）包括通过 GraphQL API 实现的自动化 CRUD，您可以进一步扩展它。 此外，您可以创建和实现自己的 React.js 组件。

Keystone 用于各种开发领域，可与移动应用程序、实用网站、电子商务店面等完美配合。

元、原生和少量无头

自从我上次做这样的概述以来已经有一段时间了。 那时的事情要简单得多，虽然找不到 Compound 和 Locomotive，但很高兴看到 Keystone 和 Express 通过时间的考验。

我也可以说，围绕 Node.js 有很多讨论。 我确实相信有些人不开心，并且觉得被它困住了。 并且包管理器（npm）的想法也开始变得陈旧，因为包不断地为一个小规模的项目添加一堆堆不必要的包大小。

但是，无论情况如何，每个框架的受欢迎程度不言而喻。 总体而言，开发人员乐于使用元框架，这可能与它还简化了全栈开发这一事实有关。 这主要消除了从头开始重新学习新的喜爱框架的需要。