[thunderbong]

From the article (italics mine) -

> So why is Next.js so pushy about it? (React server components)

> I can't avoid feeling that the new direction taken by Next.js is not designed to help developers, but to help Vercel sell React. You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run. And a server is a product that can be sold. Perhaps I'm a conspiracy theorist, but I don't see another reason to break the React ecosystem like this.

[HelloNurse]

If I understand correctly, this server side component technology is strictly JavaScript (or maybe Typescript etc.), so how can it be marketed as a step forward compared to having the React pages interact with any kind of back end through reasonably standard web services?

Throwing away perfectly good backends and replacing them with new and relatively unproven JavaScript implies so much code churn, and novel deployment and management difficulties, that fatally bad downsides like the likelihood of crucifying the masochist hipster's application or site to specific cloud services seems a minor detail.

Is it simply a perversion that has been designed to appeal to exclusively JavaScript project of exclusively JavaScript programmers who have some hope of salvaging and porting already JavaScript business logic?

[moritzwarhier]

I don't understand your argument at all. Why would a TS backend be inferior to a PHP backend, for example?

Because for many people, that's the tradeoff.

Think of a new project.

You'll still have "OOP" PHP + some random templating language + the infamously hard to do "sprinkles" of JS.

In the end lots of people start to shoehorn their PHP or Django CMS into REST API parts anyway, reinventing the wheel over and over again, for every new requirement.

I have nothing against PHP or Django or other server technologies with corresponding templating languages.

But to churn on the "old and proven" point in 2023 seems odd to me.

It's tradeoffs all the way down.

[boringuser2]

A TS backend is inferior to a PHP backend merely due to available frameworks being night and day in favor of PHP.

[paulddraper]

A TS backend is going to have a SPA frontend, reducing the complexity of the backend significantly.

Use Koa and a database client and you're good.

[boringuser2]

PHP isn't "complex", it's nearly identical with minor variations.

[paulddraper]

My point is that the need for a backend "framework" decreases significantly if you take that burden on the frontend.

And anyone writing a JS/TS backend is likely doing that. So I would expect fewer "frameworks."

[solarkraft]

> how can it be marketed as a step forward compared to having the React pages interact with any kind of back end through reasonably standard web services?

With RSP you can implement a server function and (relatively) directly call it on the server, type-safely. Try doing that another back-end (I have and mostly failed).

[justinclift]

Sounds like a potential foot-gun for input validation by the backend getting missed. :(

[piperswe]

Isn't that the purpose of tRPC?

[dimmke]

I’ve had this thought for a while. Companies like Vercel have coined the term “composable” but it really does feel like this is what is actually driving things.

[DangitBobby]

Pretty much every app I've ever needed required an API, which meant a server, which meant Next.js would have been a viable candidate. Sure, there are use-cases that you truly don't need an API or you can just hook up to an existing one, but I don't think they're nearly as common.

[boringuser2]

I don't think any of what you're saying really makes much sense.

Merely having a server doesn't mean SSR provides business-relevant benefits.

[5Qn8mNbc2FNCiVV]

Next.js provides API routes / initial serverside loaders for your routes. Disable SSR, Next.js still benefits from being able to write CRUD code in the same codebase and most applications need that anyways

[aigoochamna]

If you think that way, you are not objectively weighing the benefits of server side rendering. It _is_ useful and shouldn't be tossed away for the benefits of a 6MB javascript blob.

[8n4vidtmkvmk]

You can do better than a 6MB blob. You can code split and cache. It's not that bad. Especially if it's an app, not an SEO site.

[aigoochamna]

A 6MB blob is identical to 2MB, 1MB and 3MB blobs.

[erhaetherth]

Not quite.

1. They can potentially be downloaded and parsed in parallel

2. They can be invalidated independently, meaning on your next visit you may only need to re-DL the 1MB blob instead of the whole thing

3. Not every page will need all 3 blobs, you might only need the 2MB blob to load the homepage which means it'll load a little bit quicker. Then you can either load the next blob on the next click, or start downloading it in the background so the next click is nearly instant

4. You can do this not just between pages, but progressively within a single page. Render part of the UI, wait for the 2nd blob, then render the components that need that bit.