News for hackers. Stuff that matters.
Re:Making Sense of React Server Components by paulddraper on Wednesday September 06, 2023 @02:31PM (#37409131)
HN is a funny place.

A useful feature that an insane majority of React devs have come to prefer is "downhill."

Kids these days.

Re:Making Sense of React Server Components by keb_ on Wednesday September 06, 2023 @02:34PM (#37409170)
Many folks were criticizing hooks when they were introduced.

Of course React devs will "prefer" it; they are the idiomatic way to adding state/triggering effects in React.

Re:Making Sense of React Server Components by paulddraper on Wednesday September 06, 2023 @04:01PM (#37410505)
There is zero functionality that has been removed from class-based components.

Devs use hooks primarily because hooks are better.

Re:Making Sense of React Server Components by keb_ on Wednesday September 06, 2023 @04:32PM (#37410890)
> There is zero functionality that has been removed from class-based components.

No, but the React ecosystem has almost collectively migrated away from class-based components or deprecated support for them.

> Devs use hooks primarily because hooks are better.

You avoid much of the dependency array issues by using class components. But you have to deal with `this` and it's significantly more keystrokes. It's more of a tradeoff in my opinion.

Re:Making Sense of React Server Components by paulddraper on Wednesday September 06, 2023 @09:16PM (#37413587)
Well yes that's exactly what I said: it had been very very widely adopted
Re:Making Sense of React Server Components by keb_ on Wednesday September 06, 2023 @11:55PM (#37414576)
I don't see where you said that. It sounded to me like you were insinuating that hooks are inherently better than class components, and that zero functionality has been removed from class components, they are still viable (but they have largely been left in the dust by most popular libraries).

Also, devs don't use hooks primarily because they are better. They use them because they are idiomatic React in 2023.

Re:Making Sense of React Server Components by paulddraper on Thursday September 07, 2023 @09:29AM (#37418631)
That's akin to saying people don't like Taylor Swift's music because it is good, they like it because it is popular.

:hmm:

Re:Making Sense of React Server Components by keb_ on Thursday September 07, 2023 @11:13AM (#37420134)
It is not akin to saying that. Please argue in good faith [1]. Writing idiomatic React code makes a lot of practical sense (easier-to-find examples e.g. in the docs, wider library support, onboarding newbies). You can choose to use hooks while acknowledging the tradeoffs from class components.

[1] https://news.ycombinator.com/newsguidelines.html

Re:Making Sense of React Server Components by uryga on Friday September 08, 2023 @12:53PM (#37436133)
> zero functionality has been removed from class components

yes, exactly!

> They use them because they are idiomatic React

right, and do you think it'd be easy for a feature to become idiomatic if it wasn't an improvement over the previous patterns?

Re:Making Sense of React Server Components by ng12 on Wednesday September 06, 2023 @04:15PM (#37410685)
As someone who used to use React and now has to grapple with an in-house web framework: hooks are right on the money and offer tools backing some of the best devex in web right now.
Re:Making Sense of React Server Components by Jcampuzano2 on Wednesday September 06, 2023 @04:33PM (#37410896)
I've been using React and writing it professionally since early days before they even supported using ES6 classes. I have also answered questions for years on one of Reacts largest discord communities.

Hooks were nice when they came out, but woefully under-documented. The fact that decent docs for hooks first development came out literally just this year when hooks have been out for years is kind of a shame.

As opposed to useEffect, most other hooks are fairly straightforward, but the fact it years of articles upon articles of mistakes and documentation to explain useEffect to both experienced and non-experienced devs alike shows that it really wasn't that great of an API for end users.

In fact the most common topic nowadays is how much you need to avoid useEffect, especially if you're not a library developer. None of this was documented/mentioned when it first came out.

Yes it does enable powerful workflows, but plenty of other frameworks/libraries handle the same thing in a nice way with much less drawbacks than react. (ex: automatic dependency tracking, etc)

The number of times I have to tell people to stop putting things in effects at all, or that the reason something isn't working is a stale callback due to missing dependencies in my opinion shows that its not really a good API for the average dev to be using.

Re:Making Sense of React Server Components by dead_alchemy on Wednesday September 06, 2023 @09:44PM (#37413722)
Your last paragraph rang so true. Webpack will tell you that you are missing a dependency and ask you to include it or remove it. I feel useEffect is a fine api. It’s not the apis fault if I shot myself in the foot with it.
Re:Making Sense of React Server Components by danielvaughn on Wednesday September 06, 2023 @02:46PM (#37409327)
I find it's mostly the kids who like hooks, and the older devs who've been around since jQuery or further back, who dislike them.
Re:Making Sense of React Server Components by tshaddox on Wednesday September 06, 2023 @02:55PM (#37409464)
For what it's worth, that's not at all my experience on the teams I've worked with. I was around when hooks were released and it was an immediate and significant improvement to our team at the time.
Re:Making Sense of React Server Components by Scarblac on Wednesday September 06, 2023 @03:57PM (#37410426)
I'm 49 and started with the Commodore 64, and function based components with hooks are so much cleaner than the old class based components, it's unbelievable.

The classes had closely related functionality spread out over several different methods making them hard to understand at a glance, function based components are very concise.

I think people who dislike hooks tend to overuse useEffect (it's rarely needed) and to do too much inside components rather than inside custom hooks.

Re:Making Sense of React Server Components by ng12 on Wednesday September 06, 2023 @04:18PM (#37410716)
My experiences with jQuery are literally the exact reason why I like React.

I strongly suspect most HNers who are overly critical of React (and/or general web framework complexity) have never had to write and then maintain a large web application in jQuery.

Re:Making Sense of React Server Components by holoduke on Wednesday September 06, 2023 @05:48PM (#37411853)
JQuery is just a hammer. Its not a framework. It does provide utilities like selectors, events, triggers, dom manipulation etc. React is a component based framework. It contains pages, routes, state management, caching etc. You cannot compare those two. In a way jQuery is low level just above vanilla. Wheras react has a minimum of 500 execution layers. Thats why its slow and painful in many cases.
Re:Making Sense of React Server Components by keb_ on Thursday September 07, 2023 @12:00AM (#37414606)
To be pedantic, React is a library, and doesn't provide page abstractions, routes, or state management outside useState and useReducer. It also doesn't have very strong opinions about how you structure your application (what a framework does). That's what Next.js is for.

I agree with your overall sentiment though.

Re:Making Sense of React Server Components by paulddraper on Thursday September 07, 2023 @09:35AM (#37418714)
> It contains pages, routes, state management, caching etc.

React does not have routes or caching. It has about as much management as jQuery.

Re:Making Sense of React Server Components by danielvaughn on Wednesday September 06, 2023 @06:23PM (#37412223)
Not talking about React, I’m talking about effects. Two very different things. I love React, I don’t love hooks or effects.

I don’t think application state belongs inside the rendering machine.

Re:Making Sense of React Server Components by bgirard on Wednesday September 06, 2023 @03:24PM (#37409925)
I think this is an artifact of HN's voting system. Most readers probably don't have enough karma to even downvote. For the ones that do, guideline discourage downvoting for comments that you disagree with.

And I can see why the majority of HN readers would upvote the top level comment. Particularly since it's a popular re-hashed opinion.

Top comments aren't a good survey of the opinions of a specific community for that reason.

Re:Making Sense of React Server Components by meiraleal on Wednesday September 06, 2023 @05:54PM (#37411907)
> HN is a funny place.

Full of (ex?) React devs. There are way better things out there now if you are starting a project from zero.

Re:Making Sense of React Server Components by mitemte on Wednesday September 06, 2023 @07:35PM (#37412853)
In my experience, a lot of people don’t actually know how to use hooks correctly and find them frustrating as a result. It depends on what you’re used to, but I find that class based components leave too much room for scattered logic. Let’s not also forget those who abused `shouldComponentUpdate`.
Re:Making Sense of React Server Components by dead_alchemy on Wednesday September 06, 2023 @09:36PM (#37413689)
Wait until they find componentDidUpdate and the cascade of if statements to handle what useEffect does very elegantly.