Live data from Hacker News

TanStack Start Now Support React Server Components

tanstack.com

41–50 of 79 posts

Re: TanStack Start Now Support React Server Components

#41

Earlier quoted context omitted.

> Without RSC you have to wait for the user to download the application bundle before the request for content can even be sent to the server. This is an argument for not putting all your JS in one monolithic bundle and instead parallelizing data loading and JS loading. It's not an argument for RSC.

Even if you split up the bundle you will still need multiple round trips to the server to fetch the data.

Ignoring TLS we have:

1st RT: HTML and loader script (CDN)

2nd RT: data (app server) and code (CDN) in parallel

Therefore you need two. But not all roundtrips are equal. A roundtrip to a CDN is much faster than a roundtrip to an application server and database, unless you have some funky edge database setup.

If you render on the server, your first roundtrip is slow because the client has to wait for the application server and database before it can show anything at all. If you render on the client then your first roundtrip is fast but the second one is slow.

Re: TanStack Start Now Support React Server Components

#42
Having developed multiple react web apps from scratch over the last 5+ years at work, I always start with a fresh repo and add what I need myself. Nowadays, booting up a project with vite, eslint, prettier, redux (and rtk-query), tailwind etc. takes no time at all. Don't care about SSR. Am I missing something by not using tanstack? LLMs tell me many things, all of which seem irrelevant (e.g. not using react router, SSR, request-deduplication etc. which are covered by the basic few deps I added)

Re: TanStack Start Now Support React Server Components

#43

Having developed multiple react web apps from scratch over the last 5+ years at work, I always start with a fresh repo and add what I need myself. Nowadays, booting up a project with vite, eslint, prettier, redux (and rtk-query), tailwind etc. takes no time at all. Don't care about SSR. Am I missing something by not using tanstack? LLMs tell me many things, all of which seem irrelevant (e.g. not using react router, S…

React query is a lot leaner and safer than handful redux even w rtk query

Re: TanStack Start Now Support React Server Components

#44
post #36
post #22

Earlier quoted context omitted.

I have switched from the bloated mess of Nextjs to Vite+TSS and never looked back.

We are also currently inmidst a migration from NextJS to TanStack Start and it's worth for the performance and resource gains alone. NextJS' dev server takes around 3-4 GB memory after a few page click while TanStack / Vite consumes less than a GB.

This is something I noticed, originally I thought "AI" was the perfect tool for Vercel and Nextjs (current standard = future standard), but then I realized is the total opposite, their moat/stick is gone now, and Rouch that is smart I think knows this.

I switched a middle sized app to Tanstack Router + Vite while I was walking my dogs. Then 30 minuts-1 hour QA and it was done. This should have never happened before AI.

(I did switch because I was tired of the bloated network tab with 100 unnecesary RSC calls, the 5 seconds lag when clicking on an internal link, the 10 seconds "hot reload" after a change... I'm on a M4 MAX with 64GB of ram....)

Re: TanStack Start Now Support React Server Components

#45
post #34
post #25

Earlier quoted context omitted.

> Even bottom of the barrel motorolas are not wimpy nowadays They are: https://infrequently.org/2025/11/performance-inequality-gap-... That said, RSCs and the rest of the "let's render a static site but let's also send a multimegabyte bundle for 'hydration'" is still wrong

I am going to base my opinion on using the bottom of the barrel Motorola that I own rather than reading that novel

"I'd rather base my opinion on my own personal anecdote than based on stats". My "they are" was referring not to your specific Motorola, but to the "bottom barrel". Which, while improving, still doesn't even remotely justify the bundle sizes or "fat networks".

--- start quote ---

The median mobile page is now 2.6 MiB, blowing past the size of DOOM (2.48 MiB) in April [2025]. The 75th percentile site is now larger than two copies of DOOM. P90+ sites are more than 4.5x larger, and sizes at each point have doubled over the past decade.

...

Compared with early 2024's estimates, we're seeing budget growth of 600+KiB for three seconds, and a full megabyte of extra headroom at five seconds

--- end quote ---

Translation: for P75 (aka for 75% of users) to get a site load in three seconds you need to ship at most 600KB of Javascript

Re: TanStack Start Now Support React Server Components

#46

Earlier quoted context omitted.

The article lists the significant performance gains. Why render on wimpy phones over bad network when a cheap aws box can do it for you? That aside, Next.js and the recent related vulnerabilities made me weary of RSC and I struggle to see the benefit of RSCs over the previous server side rendered and hydrated model. Chances are TanStack will do a better job than Vercel and yet the bumpy ride of the last few years tar…

It's not 2010 anymore. Client compute is fast. Server compute is slow and expensive. 4G is ubiquitous and 3G is being phased out. You can send a tiny amount of JS from a CDN and render on the client. You will save money because the server is efficiently serving JSON instead of doing a gazillion calls and string interpolation per request. The user won't notice. Also, now that the server is responding with JSON it does…

> It's not 2010 anymore. Client compute is fast.

It's not: https://infrequently.org/2025/11/performance-inequality-gap-...

Re: TanStack Start Now Support React Server Components

#47
post #9

I still don't get why RSC is better. This post takes things for granted that don't seem obvious to me. Why would I want heavy rendering tasks to all be done on my wimpy aws box instead of the clients macbooks and iphones? Shipping moment for dates is a pain sure but that can be chunked and cached too? It's hard to imagine the benefit of reducing bundle by X kbs could really be worth doing a roundtrip to server whenev…

SEO is a good reason.

Re: TanStack Start Now Support React Server Components

#48
post #9

I still don't get why RSC is better. This post takes things for granted that don't seem obvious to me. Why would I want heavy rendering tasks to all be done on my wimpy aws box instead of the clients macbooks and iphones? Shipping moment for dates is a pain sure but that can be chunked and cached too? It's hard to imagine the benefit of reducing bundle by X kbs could really be worth doing a roundtrip to server whenev…

It's a really weird situation, but using public transport WiFi cured me of this thinking.

The amount of times that the initial HTML, CSS and JS came through, but then choked on fetching the page content was insane. Staring at a spinner is more insulting than the page just not loading.

That being said, I'm not a huge fan of RSCs either. Dumping the entire VDOM state into a script tag then loading the full React runtime seems like a waste of bandwidth.

Re: TanStack Start Now Support React Server Components

#49
post #6

Can we please go back to template-based server rendering (e.g. JSP, PHP, ASP, Handlebars/Mustache) and use JS for user interactivity only? Tired of seeing this cycle play out with a new framework every 5-6 years.

JSX is easily the most productive templating language out there, I fail to see your point.

Coming from years of Angular, I had convinced myself I wouldn't like JSX before even using it. Now, 4 years in, and I wouldn't trade it for anything. I spent almost 6 years writing Angular templates and I don't want to go back.

Re: TanStack Start Now Support React Server Components

#50
post #6

Can we please go back to template-based server rendering (e.g. JSP, PHP, ASP, Handlebars/Mustache) and use JS for user interactivity only? Tired of seeing this cycle play out with a new framework every 5-6 years.

I have good news: all that you mention is still available and ready for you to use! It has not been deprecated in any form and as far as I know it has not been made illegal. If, instead, you wanted to say "can everyone please use the things I like?", I'm sorry but that's not how it works. You don't get to tell people what they should do just because you're "tired".

Thank you. Every time I see a "Why can't we just go back to simpler days" comment it takes everything in me not to reply "No one is stopping you".

The idea that complexity arose out of nowhere and not because the web is doing things we couldn't have even imagined 10 years ago has always been wild to me.

Post reply on HN