Live data from Hacker News

TanStack Start Now Support React Server Components

tanstack.com

51–60 of 79 posts

Re: TanStack Start Now Support React Server Components

#51
post #20

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…

1. Rendered content, if there is enough of it, will be more content to send across wire than a cached bundle. 2. Cached bundles are cached. Network doesnt matter when its cached 3. Even bottom of the barrel motorolas are not wimpy nowadays 4. The obvious reasons why I dont want my aws box to do rendering is because it will need to everyone's rendering, and how big "everyone" is in not constant. It's another moving pa…

Is serialising a model and building JSON that much more expensive than rendering HTML?

Re: TanStack Start Now Support React Server Components

#52

> We intentionally do not support 'use server' actions, both because of existing attack vectors and because they can create highly implicit network boundaries Mmm. Very nice. Explicitly avoiding turning react into “webforms” and focusing on the actual point of RSC seems like the path RSC should have had from the beginning. Magical RPC so you could “use server” and not bother to write an API properly was never the poi…

Though I don't see it nearly as much as I did then, there were quite a few "you'll never have to write an api again" takes that haven't aged too well.

When RSC's were framed as a different way to write BFF's, it finally clicked for me.

Re: TanStack Start Now Support React Server Components

#53
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…

One example is that I have a fancy visualization in my app that is rendered in the server via RSC and just some interactive tidbits get sent to the client. If I packaged the whole visualization library it would have bloated my bundle size but instead I ship barely any JS and still get a nice interactive vector data viz experience. And the code just looks like normal react component nesting more or less.

Re: TanStack Start Now Support React Server Components

#54
post #46

Earlier quoted context omitted.

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-...

Seems like using a low tier android gives you a nice reality check.

Re: TanStack Start Now Support React Server Components

#55
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…

[deleted]

Re: TanStack Start Now Support React Server Components

#56
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…

[deleted]

Re: TanStack Start Now Support React Server Components

#57
post #22

I've been a big fan of TanStack start and have a few small apps ( The DX is smooth, the defaults are sane, and things generally makes sense if that makes sense. There are plenty of skills available so Claude Code and Codex know how to work with it too. If you're maybe finding Next a bit bloated these days, I'd recommend giving this a try. Plus Tanner, the creator, responds to almost every mention on Twitter so it's e…

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

The react framework de jour. I wonder what would be the reason to rewrite react apps in 2027.

Re: TanStack Start Now Support React Server Components

#59
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…

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…

[deleted]

Re: TanStack Start Now Support React Server Components

#60

Earlier quoted context omitted.

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.

Complexity mostly rose out of necessity, but the problem is it keeps being applied where it isn’t needed. Most projects don’t need Kafka, or Elastic, or Redis, or GraphQL, etc.

My main complaint is that by and large, the people who are applying these technologies heavy-handedly are doing so because they either think it’s needed, or because they don’t understand that simpler tools exist that could solve their problem.

Post reply on HN