5 ms·

Yeah, I have no desire to go back, regardless of "performance" gains. React keeps me sane and it's fairly simple to keep it performant.

by diob 3y ago

synergy20 3y ago
second this, plus its mature ecosystem, which is very valuable for the long term. though, the SSR madness movement including React concerns me, everyone tries to mix CSR and SSR into one now, which makes things way more complex than it needs.
- softfalcon 3y ago
  I could not agree more. There is a huge push to make both side of the rendering “the same”. Next.js is pushing it really hard for their edge level rehydration. I get it, it gives you flexibility to hydrate the view as close to the user, as late as possible. That sounds cool, but I wonder how many folks really use it and how much you pay for not clearly defining where and when each bit is happening.
  - satvikpendem 3y ago
    As someone who tries to limit their client-side JS usage through uBlock/uMatrix, websites that aren't just blank <div id="root"></div> with JS disabled would be nice to see, which is why I like React Server Components. Of course, if it's a useful enough web app, I'll enable JS, but if someone's writing a blog, ecommerce site, or really any site that may not require a full blown SPA. Sending minimal unneeded JS to the client is best, as it saves bandwidth and battery, as well as feeling faster due to loading faster, in my opinion.
    - pcthrowaway 3y ago
      You can also achieve this with Astro, which will render your React islands statically and also enable client-side JS for interactivity / progressive enhancement when the client has JS enabled
      - satvikpendem 3y ago
        True, however it's wrapped up in a nice DX in NextJS. In Astro, if I have multiple components that need React interactivity, are they all separate React apps basically? Or are they the same but with different roots? In NextJS, they're the same and Next can intelligently figure out which to render server side and which to render client side.
        pcthrowaway 3y ago
        If I understand correctly, the React runtime is shared between islands (and you can share state between them if necessary), but they're also pre-rendered for their initial state at build-time. So you can't do as much in Astro as you can in Next.js, but it will definitely scratch the itch of compile-time rendering.
    - softfalcon 3y ago
      I agree with you. It seems wasteful to spending a whole "wait around period" for that <div id="root"/> to eventually load once the js gets around to it. I also agree that server components make a lot of sense to solve this problem. It's the obvious optimization (and in some ways, a good re-learning from past wins with PHP, Ruby, etc). I also still feel we have a long way to go before it becomes elegant and obvious how all this is working. It hasn't become standard in the way that everyone easily groks the concept of how it all works and expects it everywhere on every web stack. Still waiting to see if we go down another rabbit hole of complexity, or see more cautious and careful improvements towards an easier, more maintainable environment.
- brigadier132 3y ago
  The "ecosystem" is taking vanilla js libraries that work without modification in other frameworks and making them work with react via a wrapper. The react ecosystem is nothing.
  - mattwoodnyc 3y ago
    React Three Fiber is a good “wrapper” library that proves the ecosystem is far from “nothing” https://docs.pmnd.rs/react-three-fiber/getting-started/examples https://docs.pmnd.rs/react-three-fiber/getting-started/examp...
    - brigadier132 3y ago
      I know what react three fiber is and I find the idea of using xml for 3d rendering to be terrible.
  - RussianCow 3y ago
    I disagree—I regularly find (and use) libraries that are built specifically for React and don't have a vanilla JS analog. As someone who uses Svelte on personal projects, I actually find this really frustrating and wish most of these libraries were just wrappers over some core functionality built without React.
willio58 3y ago
I have a similar feeling. I keep up to date on changes to these other frameworks but in my work we've never run into React performance issues that couldn't be fixed by approaching things with good principals. Signals are brought up in convo every now and then as an approach to fix an issue, but stepping back we always seem to find a better solution but just re-writing bad React code. I'm sure if you're on a certain scale of users or extremely custom UI you could run into circumstances where signals would help you, but for our system that serves hundreds of thousands a day, we don't need them yet.
recursive 3y ago
I've worked on react codebases, and non-react codebases. Maybe it's a coincidence, but I find the react ones in general to be harder to debug. And not great for my sanity either.
- diob 3y ago
  My experience is it tends to depend on the folks who made the application. Regardless of what framework you chose, they can't save you from yourself in a lot of cases.

Yeah, I have no desire to go back, regardless of "performance" gains. React keeps me sane and it's fairly simple to keep it performant.

by diob 3y ago

Yeah, I have no desire to go back, regardless of "performance" gains. React keeps me sane and it's fairly simple to keep it performant.

synergy20 3y ago

second this, plus its mature ecosystem, which is very valuable for the long term. though, the SSR madness movement including React concerns me, everyone tries to mix CSR and SSR into one now, which makes things way more complex than it needs.

softfalcon 3y ago
I could not agree more. There is a huge push to make both side of the rendering “the same”. Next.js is pushing it really hard for their edge level rehydration. I get it, it gives you flexibility to hydrate the view as close to the user, as late as possible. That sounds cool, but I wonder how many folks really use it and how much you pay for not clearly defining where and when each bit is happening.
- satvikpendem 3y ago
  As someone who tries to limit their client-side JS usage through uBlock/uMatrix, websites that aren't just blank <div id="root"></div> with JS disabled would be nice to see, which is why I like React Server Components. Of course, if it's a useful enough web app, I'll enable JS, but if someone's writing a blog, ecommerce site, or really any site that may not require a full blown SPA. Sending minimal unneeded JS to the client is best, as it saves bandwidth and battery, as well as feeling faster due to loading faster, in my opinion.
  - pcthrowaway 3y ago
    You can also achieve this with Astro, which will render your React islands statically and also enable client-side JS for interactivity / progressive enhancement when the client has JS enabled
    - satvikpendem 3y ago
      True, however it's wrapped up in a nice DX in NextJS. In Astro, if I have multiple components that need React interactivity, are they all separate React apps basically? Or are they the same but with different roots? In NextJS, they're the same and Next can intelligently figure out which to render server side and which to render client side.
      - pcthrowaway 3y ago
        If I understand correctly, the React runtime is shared between islands (and you can share state between them if necessary), but they're also pre-rendered for their initial state at build-time. So you can't do as much in Astro as you can in Next.js, but it will definitely scratch the itch of compile-time rendering.
  - softfalcon 3y ago
    I agree with you. It seems wasteful to spending a whole "wait around period" for that <div id="root"/> to eventually load once the js gets around to it. I also agree that server components make a lot of sense to solve this problem. It's the obvious optimization (and in some ways, a good re-learning from past wins with PHP, Ruby, etc). I also still feel we have a long way to go before it becomes elegant and obvious how all this is working. It hasn't become standard in the way that everyone easily groks the concept of how it all works and expects it everywhere on every web stack. Still waiting to see if we go down another rabbit hole of complexity, or see more cautious and careful improvements towards an easier, more maintainable environment.
brigadier132 3y ago
The "ecosystem" is taking vanilla js libraries that work without modification in other frameworks and making them work with react via a wrapper. The react ecosystem is nothing.
- mattwoodnyc 3y ago
  React Three Fiber is a good “wrapper” library that proves the ecosystem is far from “nothing” https://docs.pmnd.rs/react-three-fiber/getting-started/examples https://docs.pmnd.rs/react-three-fiber/getting-started/examp...
  - brigadier132 3y ago
    I know what react three fiber is and I find the idea of using xml for 3d rendering to be terrible.
- RussianCow 3y ago
  I disagree—I regularly find (and use) libraries that are built specifically for React and don't have a vanilla JS analog. As someone who uses Svelte on personal projects, I actually find this really frustrating and wish most of these libraries were just wrappers over some core functionality built without React.

willio58 3y ago

I have a similar feeling. I keep up to date on changes to these other frameworks but in my work we've never run into React performance issues that couldn't be fixed by approaching things with good principals. Signals are brought up in convo every now and then as an approach to fix an issue, but stepping back we always seem to find a better solution but just re-writing bad React code. I'm sure if you're on a certain scale of users or extremely custom UI you could run into circumstances where signals would help you, but for our system that serves hundreds of thousands a day, we don't need them yet.

recursive 3y ago

I've worked on react codebases, and non-react codebases. Maybe it's a coincidence, but I find the react ones in general to be harder to debug. And not great for my sanity either.

diob 3y ago
My experience is it tends to depend on the folks who made the application. Regardless of what framework you chose, they can't save you from yourself in a lot of cases.