5 ms·

It's been a couple of years since I was into React. What's the state of React? Where is it headead now? Are we over the SPA thing and returning to the age old R

It's been a couple of years since I was into React. What's the state of React? Where is it headead now? Are we over the SPA thing and returning to the age old RoR way?

dartos 3y ago
Server rendered react components are in rn afaik. We’ve come full circle
- flippinfloppin 3y ago
  Hilariously so. But really what it means is that javascript eats the whole world (FE&BE) which, personally, I do not enjoy myself.
  - dartos 3y ago
    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
    - DangitBobby 3y ago
      No, it's baked in to React. https://react.dev/reference/rsc/server-actions https://react.dev/reference/rsc/server-actions
      - dartos 3y ago
        Oh yep, I was thinking of “use client” https://nextjs.org/docs/app/building-your-application/rendering/client-components https://nextjs.org/docs/app/building-your-application/render...
        throwitaway1123 3y ago
        That's also baked into React: https://react.dev/reference/rsc/use-client https://react.dev/reference/rsc/use-client
    - postalrat 3y ago
      PHP is what you should be using for server code.
      - dartos 3y ago
        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
        phyrex 3y ago
        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
        dartos 3y ago
        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.
        phyrex 3y ago
        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
- rickihastings 3y ago
  [deleted]
- eyelidlessness 3y ago
  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.
  - addicted 3y ago
    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-server-components 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.
    - nsonha 3y ago
      `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.
    - eyelidlessness 3y ago
      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.
- darepublic 3y ago
  there's also pre-rendering and then making fetches for data at runtime.
k4rli 3y ago
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.
- cbeach 3y ago
  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.
DangitBobby 3y ago
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.
TheCoelacanth 3y ago
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.
ebiester 3y ago
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.
meiraleal 3y ago
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...
- nsonha 3y ago
  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.

It's been a couple of years since I was into React. What's the state of React? Where is it headead now? Are we over the SPA thing and returning to the age old RoR way?

dartos 3y ago

Server rendered react components are in rn afaik. We’ve come full circle

flippinfloppin 3y ago
Hilariously so. But really what it means is that javascript eats the whole world (FE&BE) which, personally, I do not enjoy myself.
- dartos 3y ago
  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
  - DangitBobby 3y ago
    No, it's baked in to React. https://react.dev/reference/rsc/server-actions https://react.dev/reference/rsc/server-actions
    - dartos 3y ago
      Oh yep, I was thinking of “use client” https://nextjs.org/docs/app/building-your-application/rendering/client-components https://nextjs.org/docs/app/building-your-application/render...
      - throwitaway1123 3y ago
        That's also baked into React: https://react.dev/reference/rsc/use-client https://react.dev/reference/rsc/use-client
  - postalrat 3y ago
    PHP is what you should be using for server code.
    - dartos 3y ago
      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
      - phyrex 3y ago
        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
        dartos 3y ago
        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.
        phyrex 3y ago
        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
rickihastings 3y ago
[deleted]
eyelidlessness 3y ago
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.
- addicted 3y ago
  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-server-components 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.
  - nsonha 3y ago
    `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.
  - eyelidlessness 3y ago
    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.
darepublic 3y ago
there's also pre-rendering and then making fetches for data at runtime.

k4rli 3y ago

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.

cbeach 3y ago
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.

DangitBobby 3y ago

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.

TheCoelacanth 3y ago

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.

ebiester 3y ago

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.

meiraleal 3y ago

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...

nsonha 3y ago
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.