Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My take on the current React and Server Components controversy

phryneas.de

Post reply on HN
Print view View original

41–50 of 78 posts

Re: My take on the current React and Server Components controversy

#41

Post by shipscode »

shaunpersad wrote: post #15

IMO React started going off the rails when they introduced hooks. The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away. On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion. RSC seems to be history repeating itself.

I agree. Hooks was the Angularification of React in the sense that it introduced many library-specific concepts and caused a deviation away from barebones JS.

Re: My take on the current React and Server Components controversy

#42

Post by andrewstuart »

shipscode wrote: post #37

With the amount of bs I had to go through when they dropped Hooks, I'll never use shiny new tech from the React Team again. I'm sure there are thousands of devs who feel the same. I think the React Team will soon be faced with an Angular 2.0 style situation where they are forced to break class components, hooks, etc to get people to use new patterns. The number of people who will do it out of goodwill has had to have…

>> when they dropped Hooks

What? Gotta link?

Re: My take on the current React and Server Components controversy

#43

Post by postalrat »

shipscode wrote: post #37

With the amount of bs I had to go through when they dropped Hooks, I'll never use shiny new tech from the React Team again. I'm sure there are thousands of devs who feel the same. I think the React Team will soon be faced with an Angular 2.0 style situation where they are forced to break class components, hooks, etc to get people to use new patterns. The number of people who will do it out of goodwill has had to have…

Were you forced to use hooks? Or did other people prefer it?

Re: My take on the current React and Server Components controversy

#44

Post by recursive »

athesyn wrote: post #24
mmmeff wrote: post #4

I had a junior on my team propose we switch our year old project to Next’s app router. After telling him no, I became concerned that I was becoming all the lead developers I’ve worked with in the past that shut me down and, at the time, seemed to be holding back innovation on our team. I get it now. I totally get it.

>I had a junior on my team propose we switch our year old project to Next’s app router. that doesn't sound like a big change.

Is that supposed to be an argument for or against doing it?

Re: My take on the current React and Server Components controversy

#45

Post by z3t4 »

bob1029 wrote: post #23

How many of us are working on web applications that legitimately cannot be served as basic, server-side web forms with JS only as necessary for dynamic client-side UI (e.g. disabling buttons upon form submit)? How are things like SPA improving the end user's experience and/or adding value to the product? If you are struggling and want a no-bullshit stack, why not PHP or string interpolation in your favorite language?…

You don't even have to write document.getElementById as all html ID`s are global variables.

Re: My take on the current React and Server Components controversy

#46

Post by jemmyw »

I really don't like the server side frontend rendering solutions. It's an added complexity especially if the app is served from a non JS backend - now you also have to run nodejs to prerender. Mainly it just seems like a lot of folk rush to implement this kind of optimization because it's cool rather than because it makes sense for your product and users.

Re: My take on the current React and Server Components controversy

#47

Post by leerob »

(I'm on the Next.js team) I appreciate Lenz's feedback and writing all of this down. I can empathize with how they and other library maintainers are feeling. There's more we can do on the Next.js side to help ease the transition (and this feedback will help us there, so thank you).

One point of confusion in the community has been around client components. If server components are new and exciting, does that mean client components are bad and we shouldn't use them anymore? No, it's okay to continue using them, but definitely want to acknowledge that can be draining for library maintainers to have to deliver that message. The client/server evolution of React is still in the early innings, so maybe this will be less of an education issue going forward. Client components = able to use the existing React ecosystem.

There's also some confusion about the React canary releases (https://react.dev/blog/2023/05/03/react-canaries). These features are ready for frameworks to adopt. The normal semver rules still apply for frameworks when they add experimental features (ideally behind flags). There is a separate experimental channel for React, that uses experimental features (like Server Actions). The infinite loop issue mentioned (marking a client component as `async`) now causes an ESLint error in Next.js.

Appreciate all of the suggestions in the post. A good conversation to have!

Re: My take on the current React and Server Components controversy

#48

Post by z3t4 »

esskay wrote: post #12

[flagged]

The JS community is like two million developers. When thousands of developers are using butter as an hammer it will feel like a lot. but they are just a small fraction. the js community consist of both small and big warlords pushing their own agenda.

Re: My take on the current React and Server Components controversy

#49

Post by leerob »

shipscode wrote: post #37

With the amount of bs I had to go through when they dropped Hooks, I'll never use shiny new tech from the React Team again. I'm sure there are thousands of devs who feel the same. I think the React Team will soon be faced with an Angular 2.0 style situation where they are forced to break class components, hooks, etc to get people to use new patterns. The number of people who will do it out of goodwill has had to have…

Class components still work in React, right?

Re: My take on the current React and Server Components controversy

#50

Post by datavirtue »

shipscode wrote: post #32
lucidone wrote: post #22

Front end development doesn't have to be awful, particularly with how much JavaScript the language has improved alongside browser APIs. React made sense at one point because the abstractions it employed were common in other contexts: lifecycle events (intentionally avoiding the "hook" word here) are present pretty much everywhere in programming abstractions (on initialization, on deinitialization, on update, and so f…

I'm in the same boat. Redux + Pre-Hook React was very legible & straightforward... Post hooks React is strong on theory but weak on substance, and I've gone to just jQuery and Python for my latest project. I did migrate my last project the barebones JS MVP -> React and regretted it immensely. It took about a month and didn't provide enough value to make it worth it.

I tried to learn React during the transition. Thankfully I had the authority to nope-out after trying to build a few apps with it and running into nothing but tons of arguing online when trying to search for help on what I thought would be an easy five minute task: to find out the best way to track state in my app.
Post reply on HN