TanStack oficjalnie przestał używać React Server Components (RSC) w swoich bibliotekach, podając jako decydujące czynniki zwiększoną złożoność, mniejszą elastyczność, skromne zyski wydajnościowe oraz wolniejsze tempo rozwoju. Ta decyzja ma znaczenie dla każdego, kto buduje narzędzia oparte na React, ponieważ biblioteki TanStack są powszechnie stosowane i często wyznaczają praktyczne standardy dla całego ekosystemu.

Dlaczego RSC wydawało się atrakcyjne

React Server Components pojawiły się jako sposób na przeniesienie ciężkich zadań związanych z pobieraniem danych i renderowaniem na serwer, obiecując mniejsze paczki po stronie klienta i szybsze ładowanie stron. Zespół TanStack wypróbował to podejście, mając nadzieję na poprawę doświadczeń użytkowników korzystających z ich bibliotek do siatek danych (data-grid) oraz zapytań (query).

Co ich zniechęciło

  • Złożoność – Debugowanie kodu RSC wymuszało przyjęcie odrębnego modelu myślowego. Zespół poświęcał więcej czasu na śledzenie problemów z renderowaniem po stronie serwera, niż mógł sobie na to pozwolić.
  • Elastyczność – Wiele bibliotek zewnętrznych zakłada czyste środowisko klienckie. Wykonywanie RSC wyłącznie po stronie serwera utrudniało integrację bez konieczności przepisywania lub stosowania tzw. shimów dla tych zależności.
  • Wydajność – Odnotowane poprawy prędkości były skromne. Narzut związany z koordynowaniem granic między serwerem a klientem przewyższał marginalne zyski w większości rzeczywistych scenariuszy.
  • Tempo rozwoju – Prostsze wzorce działające wyłącznie po stronie klienta pozwoliły zespołowi na szybsze wydawanie aktualizacji. W przypadku RSC każda zmiana wymagała walidacji zarówno po stronie serwera, jak i klienta, co spowalniało cykl wydawniczy.

Szersze konsekwencje

Jeśli wiodący zestaw narzędzi, taki jak TanStack, wycofuje się z RSC, inne projekty mogą ponownie przemyśleć sens tego trendu. Decyzja ta podkreśla istotny kompromis: najnowocześniejsze funkcje mogą wprowadzać ukryte koszty, które uderzają w produktywność programistów i długoterminowe utrzymanie kodu. Firmy, które priorytetyzują szybką iterację i szeroką kompatybilność bibliotek, mogą pójść w ich ślady.

Kontrargument

Niektórzy programiści wciąż widzą wartość w RSC w specyficznych przypadkach użycia — zwłaszcza tam, gdzie przetwarzanie danych po stronie serwera może drastycznie zmniejszyć rozmiar przesyłanych danych (payload). Podejście to może ewoluować, a przyszłe narzędzia mogą rozwiązać problemy zidentyfikowane przez TanStack. Na razie opinie pozostają podzielone.

Na co warto zwrócić uwagę

  • Aktualizacje narzędzi – Poprawa wsparcia dla debugowania i integracji mogłaby obniżyć barierę złożoności.
  • Opinie społeczności – W miarę jak więcej zespołów będzie udostępniać dane dotyczące wydajności, bilans kosztów i korzyści może ulec zmianie.
  • Alternatywne wzorce – Techniki przyrostowego renderowania po stronie serwera lub podejścia hybrydowe mogą stanowić rozwiązanie pośrednie.

Podsumowanie: Wycofanie się TanStack z React Server Components przypomina nam, że nowsze nie zawsze oznacza lepsze; programiści powinni rozważyć rzeczywisty koszt dla swojego przepływu pracy w stosunku do obiecanych korzyści, zanim zaczną wdrażać nowe wzorce.

Źródło: https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com