6 ms·

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.