Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TanStack Start Now Support React Server Components

tanstack.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: TanStack Start Now Support React Server Components

#61

Post by dbbk »

nfw2 wrote: 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…

Why should a low-powered Android phone be downloading and running a full Markdown parser or syntax highlighter? Stuff like that is obviously something that should be handled by the server and just returned as final HTML.

Re: TanStack Start Now Support React Server Components

#62

Post by mexicocitinluez »

sgarland wrote: post #60
mexicocitinluez wrote: post #50

Earlier quoted context omitted.

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.

> Most projects don’t need Kafka, or Elastic, or Redis, or GraphQL, etc.

I guess I just don't really see this being a problem outside of social media.

And I think another aspect that gets lost is that 20 years, your options were slim. Which means picking the right tool for the job was easier (because even if it wasn't the right tool, chances are it was as close as you were gonna get).

Things are different right now. Even something as ubiquitous as authentication is vastly different than it was back then. There's way more at play when picking tools nowadays, so it doesn't surprise me when people get it wrong.

Re: TanStack Start Now Support React Server Components

#63

Post by _heimdall »

nfw2 wrote: 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…

Just because data can be rendered to DOM on the client doesn't mean it always should be.

I'll try to render HTML wherever the data is stored. Meaning, if the data lives in a hosted database I'll render on the server. If data is only stored on the client, I'll render there.

Its less about bundle size in my opinion and more about reduced complexity and data security.

That said, I've never been a fan of RSC and don't see it solving the "reduced complexity" goal.

Re: TanStack Start Now Support React Server Components

#64

Post by satvikpendem »

jvidalv wrote: post #44
tom1337 wrote: post #36

Earlier quoted context omitted.

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 A…

Vercel's moat is DX in hosting, not NextJS. Consider, people who switch to TanStack Start still need a place to host and many would continue to choose Vercel.

Re: TanStack Start Now Support React Server Components

#65

Post by jvidalv »

satvikpendem wrote: post #64
jvidalv wrote: post #44

Earlier quoted context omitted.

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 A…

Vercel's moat is DX in hosting, not NextJS. Consider, people who switch to TanStack Start still need a place to host and many would continue to choose Vercel.

Same principle applies, hosting in Railway has slightly worse UX, but with LLM's you don't need to write a single docker line anymore, so deploying on railway is way way less cumbersome than before, and you gain more control and less costs.

Re: TanStack Start Now Support React Server Components

#67

Post by zarzavat »

troupo wrote: post #46
zarzavat wrote: post #33

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

Yes it is. Even a cheap Xiaomi is fast enough to render any application you can think of.

React is not the bottleneck. The bottleneck is all the bloat in the application code.

Webdevs act as if optimization isn't a thing and the only solution to any performance issue is to add more hardware. This explains the popularity of server-side rendering: it's a way of solving a performance issue by "adding more hardware" to the user's phone.

Yet, the user's phone was always perfectly capable of doing what they needed it to do. The problem is their application code is an unoptimized turd. They could optimize it but that would be work. Fortunately, a helpful cloud computing service has the solution: just offload your unoptimized turd to servers in the cloud!

"Sounds fantastic," the webdevs said. "Anything to avoid opening devtools."

Except, that's two bad technical decisions. The first is spending money on compute that they don't even need. The second is that compute now has to be JavaScript. What could be a highly efficient Rust or Go API server blasting out JSON at light speed is now stuck running JS and React. Somewhere, someone at Vercel looks at their quarterly earnings and smiles.

Re: TanStack Start Now Support React Server Components

#68

Post by mb2100 »

com2kid wrote: post #10
hliyan wrote: 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.

There are benefits to having the same type system throughout a code base. Also Typescript is a really nice language. The other issue is, many websites are basically apps. The HTML is a byproduct, it isn't the main event. The template based systems are fine if you have mostly plain HTML with some interactivity sprinkled in, but for people who are building complex web apps, there is typically a tiny bit of HTML and a l…

Agree that TypeScript is nice, especially for sharing templates and types between server and client. But you can still use TypeScript on the server without sending it all to the client, and without a complex and insecure protocol like RSC. I’m working on making this as simple and dependency-free as possible: https://mastrojs.github.io

Re: TanStack Start Now Support React Server Components

#69

Post by dbbk »

satvikpendem wrote: post #64
jvidalv wrote: post #44

Earlier quoted context omitted.

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 A…

Vercel's moat is DX in hosting, not NextJS. Consider, people who switch to TanStack Start still need a place to host and many would continue to choose Vercel.

This moat is rapidly disappearing though. Cloudflare is catching up, most apps (including TanStack Start) can be one-click deployed without configuration now.

Re: TanStack Start Now Support React Server Components

#70

Post by nfw2 »

troupo wrote: post #45
nfw2 wrote: post #34

Earlier quoted context omitted.

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 tha…

Ask any ux specialist, observing base reality (observe someone using x) gives a better impression of usability than any statistics will
Post reply on HN