Next.js を超えて: 代替 React Server コンポーネント フレームワークの探索

React Server Components (RSC) との現在の契約は何ですか?

2020 年後半に React チームが「ゼロバンドルサイズの React サーバー コンポーネント」という概念を導入したとき、多くの人がこれまで、そして今でもそれを理解するのに苦労しています。既存のフレームワークはいずれも新しい概念をサポートしておらず、プロトタイプは現実世界のアプリケーションを構築するための使用可能なベースを提供しませんでした。

4 年以上経った現在、react の必要なバージョンはまだベータ版で実稼働環境にリリースされておらず、それをサポートする唯一の大きくて有名なフレームワークには元 React チームのメンバーがスタッフを配置しています。これは、RSC に基づく代替フレームワークを提供しようとしていた少数の開発者にとって、非常に悲しい状況です。

なぜ RSC が必要なのでしょうか?

通常の React は、ブラウザーでアプリケーションを構築するための高速な宣言型ソリューションを提供することだけに重点を置いたライブラリです。ブラウザ内のアプリケーションには、状態を取得して保存するためのサーバーが常に必要です。この事実に基づいて、膨大な数のソリューションが開発され、React Client エコシステムに存在しています。 Typescript を使用してバックエンドを作成する人が増え始めると、次のトレンドは、バックグラウンドで API エンドポイントを作成する型付きインターフェイスを備えた RPC の復活です。

これらの要件を備えた RSC を見ると、以下の内容が規定されているため、これらすべてが RSC の範囲内であることがすぐにわかります。

• 型付きの値と Promise を返すことができる型付きサーバー アクション
• サーバー上のデータを変更し、クライアント側の UI を更新する単一のサーバー リクエスト
• サーバー上でコンポーネントをレンダリングし、順序外のレンダリングをサポートするシリアル化されたレンダー ツリーのみをクライアントにストリーミングします

これにより、アプリケーション開発者は、クライアントまたはサーバーでレンダリングされるものとは関係なく、react を使用してすべてのコンポーネントを定義できるようになります。この統合環境により、最新のアプリの複雑さが軽減され、バックエンドとフロントエンドで重複するビジネス ロジックの冗長性が排除されます。

RSC をサポートするフレームワークは何ですか?

反応ライブラリは公式のまだベータ版であるため、どれも本番環境に対応したものとみなされるべきではありません:

• Next.js v15
• ワク
• 反応サーバー
• RedwoodJS v9 - まだ開発中

現在、本番環境である程度使用できるのは Next.js のみです。バージョン 15 は、2021 年末にバージョン 12 で開始された RSC の 4 回目の反復です。

リストされたフレームワーク以外にも、RSC フレームワークの構築に関するブループリントを含むリポジトリがいくつかあります。内部の詳細を知りたい場合は、これらを使用してください。

• ヴィンシ
• 2倍
• コテカン
• r19

他のフレームワークを知っている場合は、コメントにリンクを提供してください。

RSC をフレームワークに実装することが難しいのはなぜですか?

React クライアント アプリの優れた既存のバンドラーに基づいた転記とバンドルは簡単です。これを行うには複数のオプションがありますが、最もよく使用されるオプションの 1 つは、ViteJs を開発サーバーおよびバンドラーとして使用することです。 JavaScript フロントエンドとバックエンド スタックを提供するフレームワークは、開発時および実稼動時にタイプスクリプトとバンドルを処理するための独自のソリューションを提供する必要がありました。

RSC を使用する場合、バンドラーは少なくとも 3 つの転写およびバンドル パイプラインを処理する必要があります。

1. ブラウザクライアント
2. SSRサーバー
3. RSC コンポーネント レンダラと滅菌 API
4. オプションのミドルウェア

Vite バージョン 6 がリリースされるまでは、実用的なソリューションを提供するには多くの特別なコードが必要でした。 Next.js はバージョン 15 で Turbopack に切り替え、複雑さと、この種の問題を処理するために構築されていない Webpack の使用に基づいて生じた遅延を修正するだけです。
Vite 6 の新機能は多くのターゲット フレームワーク作成者によって提供されており、新しい環境 API を使用して優れたソリューションを提供します。

コンポーネントがまったく異なる環境でレンダリングされるようになったという事実に基づいて、代替コンテンツを提供することで、これらの各環境の制限に対処するように各反応ライブラリを構築する必要があります。現在、ほとんどのライブラリはサーバー上でのレンダリングを処理して SSR コンテンツを作成できますが、多くのブラウザー固有の API が欠落しています。 RSC コンポーネントをレンダリングすると、別の反応サーバー ライブラリで追加の制限が生じます。たとえば、すべての子コンポーネントにテーマを提供するために必要な反応コンテキストとステートおよびブレーク ライブラリがサポートされていません。また、ライブラリには、ライブラリと関連するすべてのサブ ライブラリに対して、packages.json と ESM-Modules で適切なエクスポート オプションが必要です。

RSC の反応ライブラリによって提供されない 2 番目の部分はルーターです。クライアントとサーバーのルーティングを処理するルーターがないと、React サーバー コンポーネントはサーバー上でどの状態をレンダリングするかを認識できません。これが、各フレームワークに独自のルーター実装が付属しており、その API が標準化されるまで、あるフレームワーク用に開発されたサーバーおよびクライアント コンポーネントを別のフレームワークで動作するように変更する必要がある理由です。

真の RSC フレームワークのすべての要件

• React サーバー コンポーネント
  • サーバーのないサーバー コンポーネント
  • サーバーを備えたサーバーコンポーネント
  • サーバーコンポーネントと非同期コンポーネント
• サーバーアクション
  • サーバーコンポーネントからサーバーアクションを作成する
  • クライアントコンポーネントからサーバーアクションをインポートする
  • アクションを使用したサーバー アクションの構成
  • サーバーアクションを使用したフォームアクション
  • useActionState を使用したサーバー アクション
  • useActionState によるプログレッシブ機能強化
  • 応答内の UI の更新データを含むサーバーへの単一リクエスト
• ディレクティブ
  • 「クライアントを使用」を使用すると、クライアントで実行されるコードをマークできます。
  • 「サーバーを使用」は、クライアント側コードから呼び出すことができるサーバー側関数をマークします。
• DEV および PROD の 3 つのターゲットすべてのバンドル
• クライアントサイドルーティング API
• サーバーサイドルーティング API

React サーバー コンポーネントの詳細については、React の公式ドキュメントを参照してください。

メタフレームワークのオプション要件:

• サーバーサイド レンダリング (SSR)
• 静的サイト生成 (SSG)
• ネストされたレイアウト
• ストリーミング
• ファイルシステムルーター
• React API エンドポイントなし
• ミドルウェア
• 複数の展開ターゲット
• エッジ ランタイムのサポート (AWS Lambda@Edge、Cloudflare)

Next.js - なぜ代替オプションを探すのでしょうか?

Next.js 15 が最もメジャーな RSC フレームワークであるという事実に基づいて、なぜ代替フレームワークを検討する必要があるのでしょうか?

これを行う理由は常に達成すべき目標に基づいていますが、他のオプションを検討することが合理的である理由をいくつか挙げてみたいと思います。

1. Next.js は、特定のプロジェクトには関連しない可能性がある多くの異なるユースケースをカバーしようとする複雑なフレームワークです
2. 提供されるすべての機能の複雑さと使用状況に基づいて、Vercel 以外の他のクラウド環境への展開は正式にはサポートされておらず、各マイナー バージョンとメジャー バージョンでこのホスティング要件に発生する変更と同期を保つには多大な労力が必要です。
3. バンドラーが Turbopack に変更されるバージョン 15 まで、開発エクスペリエンスは遅くて鈍かったです

この記事では RSC を提供する代替案のみに焦点を当てていますが、RSC とほぼ同様の機能を提供するフレームワークは他にも数多くあり、この記事に記載されている RSC フレームワークよりもはるかに優れた代替案になる可能性があることに注意してください。

Waku - 最小限の React フレームワーク

加藤大士氏による開発:

ワク (wah-ku) またはワクは日本語で「フレームワーク」を意味します。最小限の React フレームワークとして、小規模から中規模の React プロジェクトを構築するスタートアップや代理店の開発者の作業を加速するように設計されています。これらには、マーケティング Web サイト、簡易 e コマース、Web アプリケーションが含まれます。

重い e コマース アプリケーションやエンタープライズ アプリケーションには、他のフレームワークをお勧めします。 Waku は、サーバー コンポーネントの時代に楽しい開発者エクスペリエンスをもたらす軽量の代替手段です。はい、React 開発をまた楽しくしましょう!

Waku で新しいプロジェクトを開始するのは簡単で、tailwind でセットアップされたスターター テンプレートを取得します。
npm create waku@latest

変更サーバー アクションを使用する場合、単一のリクエストでクライアント側コンポーネントに更新を返すことを除くすべての基本要件がカバーされています。現在、サーバーの変更には、クライアント コンポーネントの router.reload() を使用してクライアント ルーターを更新する必要があり、これにより、更新されたデータを RSC ストリームとしてロードするサーバーへの 2 番目のリクエストが発生します。

次のオプションの要件はまだ開発中です:

• ネストされたファイルシステムルート
• React API エンドポイントなし

多くのデプロイメントターゲットをサポート: Vercel、Netlify、Cloudflare、PartyKit、Deno、AWS Lambda、NodeJS

バンドルの複雑さに基づいて、多くのサードパーティ ライブラリで問題が発生することに備えてください。
https://github.com/dai-shi/waku/issues/423

@lazarv/react-server - サーバーサイドレンダリングを使用して React アプリを構築する最も簡単な方法

Viktor Lázár によって開発されました:

Vite ❤️ を使用して React サーバー コンポーネントとサーバー アクションを使用したかったので、@lazarv/react-server を作成しました。ほとんどの小規模アプリにとって、Next.js は多すぎて、重すぎ、遅すぎました。私は、node.js を使用して単純な JavaScript ファイルを実行するのと同じエクスペリエンスを体験したかったのです。このフレームワークは、できる限り意見が入らないように努めています。あなたはおそらくあなたが望むものは何でも達成することができます。唯一の制限は、独自の React バージョンを使用することです。プロジェクトに React をインストールする必要さえありません。それはすべてフレームワークに含まれています。私がこのフレームワークを作成し、このドキュメントの作成に使用して楽しんだのと同じように、皆さんにもこのフレームワークの使用を楽しんでいただけることを願っています。 - ラザーブ

このフレームワークを使用すると、React サーバー コンポーネントを簡単に学習できます。必要なのは、有効な React サーバー コンポーネントを含む 1 つのファイルとコマンドの実行だけです:

./App.jsx

export default function App() {
  return <h1>Hello, World!</h1>
}

npx @lazarv/react-server ./App.jsx

チュートリアルセクションには、開始方法に関する優れたドキュメントといくつかのサンプルプロジェクトがあります。

変更サーバー アクションを使用する場合、単一のリクエストでクライアント側コンポーネントに更新を返すを除き、すべての基本要件がカバーされています。

ランタイムは NodeJS API に依存するため、他のランタイム (例: (AWS Lambda@Edge、Cloudflare) は現在サポートされていません。

さらに次の機能が存在します:

• サーバーコンポーネントとアクションの HTTP コンテキストにアクセスします
• 主要な ord タグに基づく再検証によるサーバー データとサーバー応答のキャッシュ
• エラー処理
• 部分的な事前レンダリング - JSX ページの一部を静的シェルとして定義します
• NodeJS クラスターモード
• マイクロフロントエンド - アプリケーションをより小さく、より管理しやすい部分に分割します。 RemoteComponent コンポーネントを使用して、リモート URL からマイクロフロントエンドをロードし、サーバー側レンダリングを使用してアプリケーションでレンダリングします

デプロイメントターゲット: NodeJS、Vercel - 開発中のアダプター: Netlify、Cloudflare、sst

そのままの状態で Tailwind CSS、TanStack Query、Mantine UI、マテリアル UI をサポートします。

RedwoodJS - 機能する単一開発フレームワーク

Tom Preston-Werner 提供:

Redwood は、フルスタックの JavaScript アプリケーション フレームワークです。
バッテリー、バックエンド、React、規約、意見が含まれます。

まだ開発中、Node v20 と Yarn 4 でのみ動作します:

export default function App() {
  return <h1>Hello, World!</h1>
}

次に、いくつかの実験的な機能を有効にする必要があります:

npx @lazarv/react-server ./App.jsx

最後に、ビルドして提供します:

npx -y create-redwood-app@canary -y ~/rsc_app
cd ~/rsc_app

setup-rsc コマンドの一部として、ベアボーン RSC アプリが作成され、サーバー コンポーネント内でクライアント コンポーネントがレンダリングされる様子が示されます

デプロイメントターゲット: Vercel、Netlify、Render、Coherence 経由の GCP または AWS、Flightcontrol 経由の AWS、NodeJS

比較: Next.js と代替案

	Next.js	WAKU	React-server	RedwoodJS
DEV-Environment / Bundling	Turbopack	Vite 5	Vite 6	Vite
Rendering	SSR, ISR, SSG, CSR	SSR, SSG, CSR	SSR, SSG, CSR, Micro-Frontends	SSR, SSG, CSR
Caching Layers	Yes	No	Yes	??
Deployment Target	Vercel, NodeJS	Vercel, Netlify, Cloudflare, Deno, AWS Lambda, PartyKit, NodeJS	Vercel, NodeJS, sst (AWS Lambda)	Vercel, Netlify, AWS, NodeJS
Community	Very Big	Tiny	Just Starting	Small
Open Source Financing	Vercel	Donations	Donations	Privately Funded by a Rich Guy

結論

重要なポイントの要約:

• RSC は、最新の Web 開発に強力なパラダイムを提供します。
• Next.js は優れていますが、唯一の選択肢ではありません。
• 代替案は、さまざまなニーズに対応する多様な機能を提供しますが、単一リクエストのミューテーション UI の更新が欠けています。
• React エコシステムのライブラリはまだ RSC を受け入れる準備ができていません

フレームワークを試して、プロジェクトに最適なものを見つけてください。

以上がNext.js を超えて: 代替 React Server コンポーネント フレームワークの探索の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。