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）的想法也開始變得陳舊，因為包不斷地為一個小規模的項目添加一堆堆不必要的包大小。

但是，無論情況如何，每個框架的受歡迎程度不言而喻。 總體而言，開發人員樂於使用元框架，這可能與它還簡化了全棧開發這一事實有關。 這主要消除了從頭開始重新學習新的喜愛框架的需要。