Live data from Hacker News

TanStack Start Now Support React Server Components

tanstack.com

1–10 of 79 posts

Re: TanStack Start Now Support React Server Components

#7
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 easy to get eyeballs on issues that you might face. :)

Re: TanStack Start Now Support React Server Components

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

What’s stopping you from using those?

Re: TanStack Start Now Support React Server Components

#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 whenever I need format a date in the UI.

RSC seems like something only library maintainers like, although I appreciate tanstack not forcing them down my throat like next I guess.

Re: TanStack Start Now Support React Server Components

#10
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 lot of logic.

The old template based systems fall to pieces for really complicated sites.

In regards to language, if you are going to pick a JITed or interpreted language, may as well pick one that has had a lot of effort put into making it fast, and the JS runtimes are really optimized by now. Java is faster, but Typescript is a much better language (and more type safe!) than Java.

Post reply on HN