React Server Components: コミュニティの意見対立まとめ

Posted at 2025-02-07

React Server Components 入門

以前、ユーザーがReactアプリケーションにアクセスすると、サーバーは1つ以上のJavaScriptファイルを含む空のHTMLファイルを返しました。ブラウザーはHTMLを解析し、次にJavaScriptファイルをダウンロードし、クライアント側でウェブページをレンダリングしました。

React Server Components（RSC）の登場により、Reactの範囲が拡大しました。名前が示す通り、React Server ComponentsはReactのサーバー側のコンポーネントです。これらはサーバー上でのみ実行され、サーバー側のメソッドを呼び出し、データベースにアクセスするなどができます。各プレレンダリングの後、RSCはHTMLをクライアントに送信し、その後、ハイドレーションを行い、正式にレンダリングします。このアプローチの利点は、元々クライアント側のJavaScriptファイルにパッケージ化されていたコードの一部を現在サーバー上で実行できるようになったことで、クライアント側の負担が軽減され、アプリケーションの全体的なパフォーマンスと応答速度が向上することです。

「サーバーリソースを最大限に活用する」ことが、RSCがリリースされた最大の動機です。言い換えると、インタラクションを必要としないすべての処理はサーバー側に置かれるべきです。React公式は非常に典型的な例として、マークダウンコンテンツのレンダリングを提供しました。

クライアント側コンポーネントのレンダリング

import marked from'marked'; // 35.9K (11.2K gzipped)
import sanitizeHtml from'sanitize-html'; // 206K (63.3K gzipped)

function NoteWithMarkdown({text}) {
  const html = sanitizeHtml(marked(text));
  return (/* rendering */);
}

この例では、クライアント側コンポーネントでレンダリングする場合、クライアントはコンテンツをレンダリングするために少なくとも200k以上のファイルをダウンロードする必要があります。ただし、ここのマークダウンコンテンツは実際にはインタラクションを必要とせず、ユーザー操作により情報更新のニーズを生じることもありません。これはRSCを使用するコンセプトに非常に適っています。RSCを使用する場合：

サーバー側コンポーネントのレンダリング

import marked from'marked'; // zero packaging size
import sanitizeHtml from'sanitize-html'; // zero packaging size

function NoteWithMarkdown({text}) {
  // the same as before
}

依存パッケージはサーバーに配置され、サーバーはユーザーが見る必要のあるコンテンツのみを返します。クライアント側のパッケージは急激に200k以上削減されます。

ここまで、コミュニティの主流の見解は肯定的でしたが、Next.jsがRSCの特性に基づいて積極的に進出した後、意見の相違が生じました。

コミュニティ内の意見の相違

意見の相違の最も根本的な理由は、Reactがサーバー側の概念を導入したことです。サーバー側コンポーネントとクライアント側コンポーネントには明らかな違いがあります：

サーバー側コンポーネントはuseStateやuseEffectのようなReactフックを使用できません。一方、クライアント側コンポーネントは使用できます。
サーバー側コンポーネントはブラウザーAPIにアクセスできません。クライアント側コンポーネントは完全なブラウザーAPIのアクセス権を持っています。
サーバー側はサーバー側のプログラムとAPIに直接アクセスする権利があります。一方、クライアント側コンポーネントはリクエストを通じて一部のプログラムにのみアクセスできます。

Next.js v13とv14のリリースに伴い、ReactでまだカナリーバージョンにあるRSCがNext.jsによって本番環境に移行されました。「use client」と「use server」がますます多くの人に議論されるようになりました。開発者たちは現在「2つのReact」が存在すると言い、コミュニティではReactがここ数年で進歩したのか、後退したのかについて議論が始まりました。

コミュニティ内の反対的な声

著名なソフトウェアエンジニアCassidy Williams

彼女は過去2年間のReactの開発問題を指摘しました：

「2つのReact」によってもたらされる新しい概念は、多くの人にとって明確で分かりやすい知識ではありません。この分断は、追加の混乱と学習障壁を引き起こす可能性があります。
2022年6月以降、Reactは新しいリリースがないだけでなく、開発者に上位層のフレームワークの使用を奨励しています。これらの上位層のフレームワークは、RSCが安定版にアップグレードされるのを待たずに（ほぼNext.jsを指名して）RSCに基づいた機能をリリースしました。
近年、Reactの一部のメンバーが他の上位層のフレームワークのチームに加わりました。彼らはバージョンの更新を怠るだけでなく、ドキュメントの更新も怠っています。

React Queryの開発者Tanner Linsley

彼もReactの開発について懸念と不満を表明しました：

Reactがフックとsuspense APIを導入して以来、Reactはいくつかの概念に過度に焦点を当ててきました。これらの新しい概念は技術的にはシングルスレッドUI APIの限界を押し広げていますが、ユーザーに価値を提供する彼の日常的な作業にはほとんど影響を与えません。
RSCのリリースを見る限り、Reactチームはもはやクライアント側のパフォーマンスにそれほど強い追求を持っていないようです。

地図技術とビジュアライゼーション技術の専門家Tom MacWright

彼はReactエコシステムの断片化を批判しました：

現在、Reactの更新は遅く、代わりに2つの上位層のフレームワーク、Remix（Shopifyによって出資されている）とNext.js（Vercelによって出資されている）が激しい競争を繰り広げています。
ReactチームとNext.jsチームの重なりが大きすぎ、Vercelに先行する有利な立場を与えています。VercelとFacebookのエコシステムに属さない他のフレームワーク、例えばRemixは、修正されているがリリースされていないReactのバグの影響を受けます。

コミュニティ内の肯定的な態度

コミュニティ内で増え続ける反対的な声に直面して、Reactの主要な貢献者であるDan Abramovも何度か彼の見解を表明しました。彼は技術的な変化に対してオープンな姿勢を持っています：

Next.jsのApp Routerは大きな野望を持っていますが、まだ開発の初期段階にあり、将来的にはさらに優れたものに反復改良されるでしょう。
クライアント側コンポーネントの仕事はUI = f(state)であり、サーバー側コンポーネントの仕事はUI = f(data)です。Reactは両者の利点を組み合わせて、UI = f(data, state)を実現したいと考えています。彼はコミュニティにこの目標の実現を共同で推進するよう呼びかけました。
Next.jsがRSCを本番バージョンにリリースしたことに関して、Danは「本番環境に適している」というのは主観的な判断であると考えています。RSCはまだカナリーバージョンですが、Facebookはすでに広く使用しています。彼は、実践での検証が技術をより迅速に改善し、最終的に成熟と安定を達成できると考えています。
新技術の開発は段階的なプロセスであり、継続的なテスト、フィードバック、反復を伴います。コミュニティの力は非常に重要です。

全体として、Danは皆が偏見を取り除き、実践の中でReactの次段階の変革を共同で探求することを望んでいます。

結論

RSCは、現代のウェブアプリケーション開発の強化に明確な積極的な意義を持っています。最も明らかな利点は、大規模なアプリケーションのパフォーマンスを向上させ、クライアント側の負荷を軽減し、データ取得プロセスを最適化するなどです。これらのタスクをRSCを通じて完了することは、以前のSSRソリューションよりも便利です。

Node v20のリリースとRSCの適用により、フロントエンドとサーバー側の距離はさらに縮まります。我々はフロントエンド作業の「バックエンド化」を目撃する機会があります。つまり、フロントエンドエンジニアがデータクエリの最適化、サーバーリソースの管理など、従来はバックエンドに属する作業をより多く扱うようになるでしょう。これは実際にフロントエンドエンジニアに1つの扉を開き、ウェブ全体を包括的に習得する機会を与えています。