TanStackは、複雑さの増大、柔軟性の低下、わずかなパフォーマンス向上、そして開発速度の低下を決定的な要因として挙げ、自社ライブラリにおけるReact Server Components (RSC) の使用を正式に停止しました。TanStackのライブラリは広く採用されており、エコシステムの事実上の標準となっていることが多いため、この動きはReactベースのツールを構築するすべての人にとって重要です。

なぜRSCが魅力的に見えたのか

React Server Componentsは、重いデータフェッチやレンダリング処理をサーバー側に移行することで、クライアント側のバンドルサイズを小さくし、ページロードを高速化することを目的として登場しました。TanStackチームは、自社のdata-gridやqueryライブラリのユーザーエクスペリエンスを向上させることを期待して、このアプローチを試みました。

離れることになった理由

  • 複雑さ – RSCコードのデバッグには、これまでとは異なるメンタルモデルが必要でした。チームは、許容できる範囲を超えて、サーバーサイドレンダリングの問題の追跡に時間を費やすことになりました。
  • 柔軟性 – 多くのサードパーティ製ライブラリは、純粋なクライアント環境を前提としています。RSCのサーバー専用の実行環境では、それらの依存関係を書き換えたりshimを用意したりしない限り、統合が困難でした。
  • パフォーマンス – 測定された速度の向上はわずかなものでした。サーバーとクライアントの境界を調整するためのオーバーヘッドが、ほとんどの実用的なシナリオにおいて、得られたわずかな利点を上回ってしまいました。
  • 開発速度 – よりシンプルでクライアントのみのパターンであれば、チームはより迅速にアップデートをリリースできました。RSCでは、あらゆる変更に対してサーバーとクライアントの両方で検証が必要となり、リリースサイクルが遅延しました。

より広範な影響

TanStackのような主要なツールキットがRSCから一歩退くことは、他のプロジェクトがその熱狂を再考するきっかけになるかもしれません。この決定は、最先端の機能が、開発者の生産性や長期的なメンテナンスを損なう「隠れたコスト」をもたらし得るというトレードオフを浮き彫りにしています。迅速なイテレーションと幅広いライブラリの互換性を優先する企業は、これに続く可能性があります。

別の視点

特定のユースケース、特にサーバーサイドでのデータ処理によってペイロードサイズを劇的に削減できる場合には、依然としてRSCに価値を見出す開発者もいます。このアプローチは進化する可能性があり、将来のツールがTanStackが特定した課題に対処することもあるでしょう。現時点では、意見は分かれています。

今後の注目点

  • ツールのアップデート – デバッグや統合サポートの改善により、複雑さの障壁が低くなる可能性があります。
  • コミュニティのフィードバック – より多くのチームがパフォーマンスデータを共有することで、コストとベネフィットのバランスが変わるかもしれません。
  • 代替パターン – インクリメンタルなサーバーレンダリング技術やハイブリッドなアプローチが、中間的な解決策を提供する可能性があります。

まとめ: TanStackによるReact Server Componentsからの撤退は、「新しいものが常に優れているわけではない」ということを私たちに思い出させてくれます。開発者は、新しいパターンを採用する前に、約束された利点とワークフローへの実質的なコストを天秤にかけるべきです。

出典: https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com