To me it seems to be turning into php but with better developer experience. SSR is much better and fortunately React devs have also discovered that shipping 2MB+ of js at once isn't optimal.

You might ship 2MB of JS to each user once, but you then avoid shipping markup-heavy HTML on every click (like you do with SSR).

But the point is somewhat moot as modern Internet connections and devices won’t struggle with a 2MB payload in any case.

Server rendered react components are in rn afaik.

We’ve come full circle

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

There is something about the 'use server' declaration that just bothers me. I dunno.

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

[deleted]

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.

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

From my POV, React is good and only getting better. Fundamentals aren't really changing, but the biggest pain points are being addressed. Hot reloading is faster thanks to the likes of Vite and SWC. Performance of package managers like yarn and npm have improved dramatically. Libraries like react-router-dom make life even easier.

I wouldn't expect React to be replaced any time soon.

I would say it's moving more towards a hybrid of SPA and non-SPA. The new features reduce the difference between front-end and back-end code and make it very simple to move some handling from the front-end to the back-end or vice versa if you choose.

I think there are a few key differences.

The "old RoR" way assumed that all behavior is built by the server through ruby, until client side behavior was needed. Then, that was built in CoffeeScript. (or JS if you rejected omakase.)

The React way is to assume you will have client side behavior, but write it as if it is client-side and the server will compile that into a html that can be hydrated with behavior without intervention. Even with that "magic," it is easier to reason through if you already have a mental model of the browser.

It is brain dead. Vercel.js is making as much money as possible while there are still so much attention but most experts/evangelists left or are leaving for more modern frameworks like htmx, lit, solidjs, svelte...

If you actually follow the people in the React team, they've moved on to things that are not front-end framework. However lame React is these days, htmlx etc are even lamer. No one quits a well-paid job at Meta or Vercel to then go continue working on the same boring shit.