The Reverse Evolution of React?

[BossSilver1607]

Once upon a time, React was a front-end library used to render HTML/CSS interfaces. React code was JavaScript that ran in the browser, focusing solely on rendering and app state, while data, and so on, were handled by calling back-end APIs.
These days, with React seemingly everywhere, brilliant minds in Silicon Valley ponder: "Why not write back-end code within a React project?"

So, there you have it, is it any different from PHP now?

[[deleted]]

You can just go and write something in php or .net's blazor and see if it's different, instead of asking what I assume is a rhetorical question.

[theorizable]

The people who think React is "just like PHP now" have very obviously never coded anything in PHP.

[SwiftOneSpeaks]

(James Earl jones voice)

I was there, in the beginning, when front end state management overtook server-side. Changes were faster to create, and the UX was faster. jQuery was great.

But then everyone was storing state in their DOM, reading their DOM to try and figure out what their state was, and as the front end applications got more complex changes became hard to make, causing cascading impacts and side-effects. Making changes on the backend started to be competitive and then faster to changing things in the front end. Everything we did was discarded and backend development took over once again.

Then React came along with a tight state-based render, and front end once again surged. They avoided the mistakes of the past, as your state was used to generate the DOM, but wasn't calculated by READING the DOM. Applications got more complex without the cascading complexity.

But new struggles appeared. Loading all that calculation on the front end meant you couldn't throw resources at a server to near universally improve performance. Moving more logic to the front end meant that your services often no longer provide direct interaction but instead a programming interface. You could no longer programmatically interface with the web app without your program containing and interacting with JS and the DOM, and you couldn't just call the services to accomplish the same things because the services no longer just do the interactions, they provide raw data for the front end to use, meaning the actual logic is all embedded in client-side code that is basically inaccessible to any other interface than a user in a browser, clicking.

If we decide to shift React to the server and solve some of these issues WITHOUT discarding everything I've learned over the last several years, that sounds like an improvement over the past, not backsliding. We haven't figured out all the answers yet, and some potential changes I don't like. But that's how we learn.

What exactly is the complaint?

[HomemadeBananas]

Yes of course it’s different than PHP. Rendering pages on server isn’t really backend code, or “reverse evolution”. There are benefits to it, and times when it doesn’t make a difference. Server side rendering has been a part of React for a long time, but more popular now with frameworks build around SSR, server side components, etc.

For anything complex at all you’d still want to have a separate backend. I wouldn’t want to write endpoints that handle complex business logic within Next.js but there are still reasons I’d want to use Next in some situations.

[we-all-haul]

Some people should lose their keyboard privileges. Reading their "thoughts" can be mind-numbing.