Server rendered React components have always been in, and server rendering was the primary precursor to React in the first place. Still full circle, without coming or going anywhere.

This is a blog post from 2020 that introduced React Server Components and talks about it being in the R&D phase.

https://react.dev/blog/2020/12/21/data-fetching-with-react-s...

React v1.0 was out in 2014. It was already being used in production before that.

React Hooks were released in 2019. Hooks has also spent years as part of React with Server Components not being part of it.

Server Components is an extremely new addition to React, and a significant shift in React’s direction.

RSC is not the introduction of rendering React components server side. React Server Components are concerned with new server-specific functionality for sure, but they’re also concerned with changes to bundling and wire format, mostly addressing client-specific concerns that arise from those.

But don’t take it from me, I’m just regurgitating information I learned from actual React team members (at least at the time) like Dan Abromov.

`react-dom` has a `renderToString` function since day 1 and people has been rendering server side since day 1 of React. There are also approaches such as pre-rendering with Chromium.

Hilariously so. But really what it means is that javascript eats the whole world (FE&BE) which, personally, I do not enjoy myself.

I don’t think any shop starting nowadays really wants to use nodejs on the backend.

I think most everyone is on go or python for BE work.

Just really frontend focused apps or heavy react shops are doing js on the backend.

EDIT: I think “use server” is a nextjs thing FWIW

No, it's baked in to React.

https://react.dev/reference/rsc/server-actions

Oh yep, I was thinking of “use client”

https://nextjs.org/docs/app/building-your-application/render...

That's also baked into React: https://react.dev/reference/rsc/use-client

PHP is what you should be using for server code.

You _should_ the best tool for the job.

Personally,I don’t think php or js are the right tools to build a backend for a business.

Neither are particularly friendly towards growing teams for many reasons, but the lack of strong typing is a big one.

You want your backend to have minimal complexity, that’s why go has been so popular lately

PHP has static and strong types these days and it (and its dialects) are in use by some of the largest teams on the planet

Granted I don’t know much about typing in php, but from my quick google search, it seems like they support type hints and type declarations, but the language isn’t strongly typed.

Also, to your second point, some of the largest, most critical, and most at-risk businesses on the planet (namely banks) run on COBOL, but I wouldn’t exactly describe cobol as a language that lends itself well to large orgs, it’s just entrenched. same as php and dozens of other technologies.

I admit I’ve only ever used Hack, not vanilla PHP, but that one is a pleasure to use. I’m sure the vast majority of my colleagues will agree with that too

there's also pre-rendering and then making fetches for data at runtime.