11–20 of 79 posts
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.
> How does this compare to Next.js App Router?
> Next.js App Router is server-first: your component tree lives on the server by default, and you opt into client interactivity with 'use client'.
> TanStack Start is isomorphic-first: your tree lives wherever makes sense. At the base level, RSC output can be fetched, cached, and rendered where it makes sense instead of owning the whole tree. When you want to go further, Composite Components let the client assemble the final tree instead of just accepting a server-owned one.
The sudden server-first change on Next.js App Router definitely trips some people, especially since React started as client-only library.
How does this work with Suspense (without Query) and the 'use' hook from React?
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.
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".
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…
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 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…
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 tarnished the whole idea.
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.
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…
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. So that means that the db queries and stuff are not even initiated until the client has the bundle and runs it, vs with RSC that stuff is all launched the moment the first request comes in from the user.
Also SSR, even in React, existed well before RSCs did, and that seems to be really what you are talking about.
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…
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 part in a complex system that can break. Also because I have to pay for the box.
5. Fast networks are becoming more and more ubiquitous
6. The performance gains are for a static site, which won't necessarily be representative of typical saas. How do you measure the risk and cost of my site breaking because my date rendering server got overloaded?