2022 年に最も人気のある Node.js フレームワーク

Express.js は Node.js と同じくらい古いものであり、Express は依然として驚異的なバックエンド フレームワークですが、新しい種類のツールとキットがその足跡を残しつつあります。

最も顕著なのは、トレンドがメタフレームワークに移行したことです。そこでは、React のような一般的なフレームワークが、フルスタック開発をサポートするために転用されています。 このアプローチの利点は、特定のフレームワークで専門知識を維持しながら、同時にバックエンドに取り組むことができることです。 つまり、フルスタック開発を行います。

このデータはどのように入手されましたか?

すべてのデータは、State of JavaScript、Stack Overflow Developer Survey、およびさまざまなプロジェクトでの個人的な経験などの調査に基づいています。 これは、GitHub の星が最も多い Node.js フレームワークに基づくレビューではありません。

代わりに、過去 1 年間に獲得した星の数を比較しました。 これは、特定のプロジェクトがどれだけ活発で、開発者がそれにどれだけ反応しているかを示す確かな指標です。

 これらのフレームワークのいずれかをリアルタイム環境で試してみたい場合は、開発者向けのホスティング プラットフォームに関する記事をご覧ください。 各プラットフォームには無料プランがあり、ほとんどすべてのプラットフォームで GitHub リポジトリをインポートして直接ホストできます。 

たとえば、任意のレポを取得して、数分でライブにすることができます。

現在のNode.jsのトレンド

この投稿全体を通して、この記事で言及されているフレームワークの多くがフロントエンド フレームワークに基づいていることに気付くでしょう。 これは、メタフレームワークとも呼ばれます。 では、これにはどのような問題があり、なぜこのアプローチを採用したのでしょうか?

React のようなものを見ると、ページをレンダリングする方法は CSR (クライアント側レンダリング) によって行われます。 要求が行われると、ブラウザには実際のページ コンテンツのないベアボーン HTML ファイルが与えられます。 そのため、ブラウザはページ コンテンツを含む JavaScript ドキュメントを取得するために 2 回目の往復を行い、それを配信して実際のページをレンダリングします。

これは、ユーザーがページを操作するたびに発生し続けます。 HTML はそのままですが、ルート リクエストが異なるため、ブラウザはユーザーが必要とするコンテンツをレンダリングするために何度も行き来しなければなりません。

これは、SPA またはシングル ページ アプリケーションとも呼ばれます。

この CSR アプローチの欠点は次のとおりです。

• キャッシング– すべてのページ コンテンツは JavaScript を介してレンダリングされるため、ページ上にキャッシュできる実際の HTML コンテンツはありません。
• SEO – クローラーは「よりスマート」になっていますが、JavaScript のみに依存するコンテンツのインデックスを作成するロボットには決定的な問題があります。
• レンダリング– すべての JavaScript の読み込みが完了するまで、最初のレンダリングは遅く、応答しません。

したがって、このコンテキストでは、Next や Nuxt などのフレームワークの背後にあるアイデアは、フロントエンド フレームワークを採用し、Node.js を介して SSR (サーバー サイド レンダリング) を提供することです。

SSR といえば、Nick Johnstone が「サーバー側レンダリングのばかげた複雑さ」というタイトルの興味深い要点を公開しました。 また、対応する Hacker News スレッドもあり、このトピックについてかなり多くの議論が行われています。 近い将来に大きく変わることはありませんが、これらの概念のいくつかは、一部のフレームワークの動作方法に大きな変化をもたらすと私は信じています。

#1 – Next.js

React Framework である以上 – Next.js は途方もなく速い開発ペースのおかげで人気が高まり続けています。 Next.js 10 から Next.js 12 までわずか 1 年しかかかりませんでした。

Next.js の背後にあるコア コンセプトは、React を基盤として使用することですが、サーバー側のすべてのレンダリング構造を独自の仕様で実行します。 レンダリングはサーバー側で行われるため、クライアント側でページをレンダリングする必要がなく、パフォーマンスが大幅に向上し、SEO に関しても大きなメリットがあります。

Next がこのように広く採用された理由の 1 つは、独自のバックエンドを構築する必要がないことです。 その間ずっと、アプリのパフォーマンスをすぐに最適化する有意義な方法を提供します。 ヴェルセルはそれを維持します。

#2 – 巣

NestJS は、静かにバックエンド コミュニティから大きな承認を得ることができました。 Nest の背後にある主な哲学の 1 つは、React のようなフレームワークがフロントエンド開発を加速する一方で、そのようなフレームワークの多くはアプリケーション アーキテクチャの問題を解決するのに苦労しているということです。 Nest は、アーキテクチャ ファーストのアプローチでこれを解決します。

もちろん、これはバックエンドに固有のものです。

Nest は、(Angular に触発された) 3 つのコア コンポーネント ( Controllers 、 Providers 、およびModules ) に基づいています。 モジュールの使用は、Nest が複雑なアプリケーション階層の問題を解決しようとする方法です。 各コンポーネントは、独自のコントローラー、依存関係、および特定のプロバイダーを構成する個別のモジュールに分類できます。

#3 – ストラピ

ヘッドレスは、現在のフロントエンドの物語で大流行しています。 また、Strapi は、主要なヘッドレス CMS フレームワークの 1 つとしての地位を確立するという素晴らしい仕事をしました。

では、ストラピとは何ですか？ 最も実用的な用語では、Strapi はフロントエンド アプリケーションのバックエンドです。 ある意味では、Strapi を使用すると、Express のようなフレームワークを学習する必要がなくなります。これは、API を介してほとんどの作業を実行できるためです。

これには、カスタム UI を介したコンテンツの管理、GraphQL と REST のオンザフライ エンドポイント、ユーザー管理 (ロールなど)、および構築可能な個別のプラグイン インターフェースが含まれます。 Strapi は完全にフレームワークにとらわれず、実質的にあらゆる言語、フレームワーク、またはフロントエンド ライブラリと統合します。

#4 – リミックス

Remix は、React Router を作成した人々によって構築されたフルスタック フレームワークです。

Remix は、ここ数年で最も急速に成長しているフルスタック フレームワークの 1 つでもあると思います。 それで、どうして？ 1 つには、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 はハイドレーションのプロセスを実装します。 サーバー側でレンダリングされた DOM 要素のアクティブ状態を保持する機能。

#7 – ファスティング

Fastify フレームワークはパフォーマンスがすべてであり、個々のベンチマークでは、1 秒あたり最大 60,000 のリクエストを処理できることが示されています。 フックとプラグインを使用して Fastify を (すでに優れたツールに加えて) 拡張できます。 また、TypeScript ファーストのフレームワークではありませんが、Fastify は TypeScript をサポートしています。

プラグインといえば、Fastify の開発の多くはプラグインを通じて行われます。 Fastify には、コミュニティで作成されたプラグインと Fastify チームによって作成されたプラグインの両方の公式リポジトリがあります。 プラグインの背後にある考え方は、クリーンなシステム アーキテクチャを提供し、別のフレームワークにジャンプする必要をなくすことです。 これにより、Fastify は、強力なリアルタイム パフォーマンスを備えた低オーバーヘッド API の構築に特に役立ちます。

#8 - レッドウッド

API は好きですか? ジャムスタックがお気に入りですか。 答えが「はい」の場合、RedwoodJS を気に入るはずです。 これは、多くの最新のテクノロジーを利用したフルスタックの Web アプリ フレームワークです。 これらのテクノロジーには、GraphQL、Prisma、Storybook、および Jest が含まれます。 Redwood のフロント エンドは React の上に構築されており、TypeScript も完全にサポートされています。

#9 - エクスプレス

Expressは恵みから落ちましたか？ ではない正確に。 このフレームワークは依然として非常に人気があり、愛されていますが、他の大手企業ほどではありません。 何年も Express を使用してきたチームにとって、基本的な問題がないため、別のものに切り替えることは意味がありません。 多くのフレームワークは依然として Expressに基づいて構築されています。

#10 - アドニス

Adonis は、Node.js 用に構築された TypeScript ファーストのバックエンド MVC フレームワークです。 Adonis は自身をバックエンド フレームワークと呼んでいますが、それを使用してフルスタック開発を行うことも同様に問題ないことに注意してください。

開発者が Adonis を気に入っている主な理由の 1 つは、TypeScript のネイティブ サポートです。

また、ORM (Object Relational-Mapping) のサポート、強力なセキュリティ プラクティス、わかりやすいドキュメントも備えています。

最後になりましたが、Adonis は Node.js エコシステムと基本的なレベルで統合されるため、Node 開発の経験が必須です。

#11 – キーストーン

このリストの最後の Node.js フレームワークは Keystone です。 Express と同じように、ほぼ初日から存在しています。 これにより、Keystone は成熟したフレームワークになり、具体的なツールと統合を提供して、開発者にとって使いやすいエクスペリエンスを作成します。

Keystone のいくつかの注目すべき機能 (その多くは何年にもわたって改良されてきました) には、GraphQL API による自動化された CRUD が含まれており、さらに拡張することができます。 さらに、独自の React.js コンポーネントを作成して実装することもできます。

Keystone はさまざまな開発分野で使用されており、モバイル アプリ、実用的な Web サイト、e コマース ストアフロントなどでうまく機能します。

メタ、ネイティブ、そしてヘッドレスのピンチ

このような概要を最後に書いてからかなりの時間が経ちました。 当時はもっとシンプルで、Compound と Locomotive はどこにもありませんでしたが、Keystone と Express が時の試練を乗り越えてきたのは素晴らしいことです。

また、Node.js をめぐる話題がかなりあるとも言えます。 一部の人々は不幸で、それに行き詰まりを感じていると思います。 また、パッケージ マネージャー (npm) のアイデアも古くなり始めています。これは、パッケージが不要なバンドル サイズの山を小さなプロジェクトに追加し続けるためです。

しかし、いずれにせよ、各フレームワークの人気はそれ自体が物語っています。 全体として、開発者はメタ フレームワークを喜んで使用します。これは、フルスタック開発も合理化されるという事実に関係している可能性があります。 これにより、新しいお気に入りのフレームワークを最初から再学習する必要がほとんどなくなります。