Go back
2 min read

TanStack drops RSC: when the solution became more complicated than the problem

Why TanStack dropped RSC after replacing heavy dependencies, and what it changed for complexity, navigation and traffic.

TanStack drops RSC: when the solution became more complicated than the problem

What happened:

  1. Why did they introduce RSC? The site suffered from monstrous Markdown parsing libraries and Shiki syntax highlighting. All that beauty bloated the client-side JS bundle. RSC let them move the heavy rendering to the server and shed unnecessary weight from the browser.
  2. What was the problem? RSC didn’t fix the problematic dependencies. It simply hid them behind the server boundary. The price was a huge mental burden: Flight data serialization, constant debugging of client/server boundaries and a tangled bundler.
  3. How did they finally solve it? They wrote their own microlibraries for parsing (TanStack Markdown and TanStack Highlight), weighing around 27 KB combined. Once the heavy dependency disappeared, the overhead of maintaining RSC stopped making any sense at all.

As a bonus, Tanner worked out the navigation math: with RSC, the browser fetches a serialized Flight data tree on every click. With ordinary SSR, the page is downloaded once (+18 KB), but for the next 5–6 pages the user downloads only the raw data (saving up to 5.6 KB per click). The classic approach won on both performance and traffic.

I’m skeptical of the enthusiasm for RSC. To me, RSC increasingly looks like an attempt to treat the symptoms of shitty architecture, instead of curing the disease itself.

When a project hits a wall because of dependency-bloated bundles or lousy data management, bringing in RSC is just sweeping the mess under the rug. In return, you get hellish mental complexity, subtle bugs at runtime boundaries and blurred lines of responsibility.

Classic SSR is 100 times easier to understand: you have a direct, linear data flow. The server assembles it, sends the markup, and the client takes over. Everything is logical, transparent and predictable. If you have a heavy client, you need to make it lightweight, not build layers of abstractions just to run a heavy npm package on the server.

Read the original breakdown

What do you think of TanStack’s rollback? Have you already been burned by RSC in production, or do you still consider it the holy grail?

Copied