Re:Making Sense of React Server Components
by Exuma on Wednesday September 06, 2023 @08:28PM
(#37413276)
I still think one way data flow is profound for complex frontend UIs. The idea of making something as complex as Facebook ad manager without it sounds true nightmare level
I personally love vue and single page templates (I hate jsx)
SSR is stil a good option i think for complex apps
Re:Making Sense of React Server Components
by nwienert on Wednesday September 06, 2023 @08:23PM
(#37413242)
I don’t think you could be more off, honestly. React revolutionized frontend development and made it dramatically better. Server side rendering for React has existed since very early in its lifetime.
The rest of the snark looks silly in context of the above two points.
Re:Making Sense of React Server Components
by paulddraper on Wednesday September 06, 2023 @09:15PM
(#37413567)
But haruff harruf everything is stupid and I don't see any difference in what I can do with the web now vs 15 years ago haruff haruff
Re:Making Sense of React Server Components
by pjmlp on Thursday September 07, 2023 @09:53AM
(#37418942)
Doing Web related stuff since 1998, the only revolution is cargo cult from FB stuff, while refusing to support Web components like all other frameworks.
Re:Making Sense of React Server Components
by technion on Wednesday September 06, 2023 @09:09PM
(#37413528)
Don't forget "functions that do totally normal things now need to be rewritten as a hook".
Re:Making Sense of React Server Components
by paulddraper on Wednesday September 06, 2023 @09:13PM
(#37413558)
If you are writing functions that do totally normally things as hooks, you are indeed doing it wrong.
Hooks are for stateful code.
Re:Making Sense of React Server Components
by shortcake27 on Thursday September 07, 2023 @02:25AM
(#37415403)
Yeah I think that’s their point. People rewriting stateless functions as hooks because “hooks are cool” before they actually understand what they do.
Easiest way I put it to my team was that in order to qualify as a hook, it must consume a hook.
Re:Making Sense of React Server Components
by DanielHB on Thursday September 07, 2023 @03:33AM
(#37415805)
this is the single biggest problem with React hooks, people overusing useEffect:
const [sortedValues, setSortedValues] = useState([])
useEffect(() => {
setSortedValues(values.sort())
}, [values])
To be honest I much prefer hooks than old class-based state manipulation, but it does require deeper understanding of the React, JS and state to get right.
Re:Making Sense of React Server Components
by carbotaniuman on Thursday September 07, 2023 @04:10PM
(#37424903)
What's the actual solution for that? I've only used Vue and Solid where "computeds" functions fall out of how signals or reactivity work, not sure how it works in React-land. Do you just leave it as a plain function and rely on React calling on your component?
Re:Making Sense of React Server Components
by 5Qn8mNbc2FNCiVV on Friday September 08, 2023 @05:40AM
(#37431542)
Ignoring that sort mutates the initial array which is a bug in that example, you would just sort it in the function body. If the sort takes a lot of time or the array is big and you don't want to create garbage, you memoize it with useMemo.
Re:Making Sense of React Server Components
by silenthoughts on Wednesday September 06, 2023 @11:35PM
(#37414460)
I do agree with most of this. I work with React on a daily basis and, while it has made things much easier than using something like jQuery or writing vanilla Javascript, I do think they're adding features that is making it more complicated to use. I still can't wrap my head around NextJS and some of the things it is doing. I prefer not to use the new features at this point.
Re:Making Sense of React Server Components
by DanielHB on Thursday September 07, 2023 @03:27AM
(#37415779)
People were doing SPAs way before react came around (and it took a few years for it become popular), I myself had a jQuery-based SPA a few years before React was released and when I saw React I was like: "this solves all of the problems my codebase has"
React was more of a replacement for jQuery/BackboneJS/MooTools/Angular/etc than a replacement for PHP/JSP/ASP/etc
– A bunch of smart Facebook engineers with unlimited funding decided to mess around and see just how much they could upend all the existing web paradigms, before finally concluding that conventional wisdom and the traditional server-side rendering model exist for a reason and make sense.
– The entire software industry decided that every new experiment by this above group was worth ripping out and rewriting their entire codebase over, whether it made sense for their needs or not and whether it actually made their product better or not.
I have not been too deep into the weeds of it myself but have been interacting with FE teams at my company enough to see what a charade it all is.
"This React thing is cool, and everyone is talking about it. Let's move some of our existing JS components over to it and see how things turns out."
"We need to do a top-down rewrite of the entire app in React."
"We're going to need the infra team to set up a GraphQL API layer for us. It can't be that hard, right?"
"Hmm, initial page loads are too slow. Hey infra team, can you set up a render farm of Node.js servers so we can do SSR?"
"Whoa, functional components are cool! We need to do another top-down rewrite and get rid of all the silly classes."
"We have a small team dedicated to investigating server components, and if the prototype looks good then we'll switch over to Next.js and rewrite our FE + API stack."
I'm sure my company wasn't the only one that caught this virus. I shudder to think just how much money and productivity has been wasted industry-wide over the obsession with this framework.