The crowd goes mild.
I've yet to see HN get truly excited about anything JS-related, particularly React. Personally I'm excited but I wouldn't bother elaborating my excitement here because I know I'll just attract the usual crowd making unfound assumptions about my experience or complaining about hooks not following best practices (like, I don't know, JSX?).
There are trade offs and it's interesting to discuss those and to criticise them. But a kneejerk reaction can't go that far.
I've been building websites since the 1990s and web applications since the mid-2000s. I've used a wide range of web technologies and despite being "self-taught" went out of my way to broaden my horizon beyond the imminently useful.
My initial reaction to JSX was dismissive ridicule: "XML in JS? Yeah, because that worked out so well when we did that in ActionScript. And building your own component tree as a template language was already a bad idea when I rolled my own implementation in PHP fifteen years ago".
My initial reaction to hooks was confusion: "The sequence is important? Why wouldn't you just name things instead? Why does everything start with "use"? What the heck is even going on?"
Both times I looked into it and realised I was wrong and my intuition was just rejection of the unfamiliar and a profound misunderstanding of how the technology I was dismissing actually works.
I'm not a "React fanboy". I can't say what framework I'll be using five or ten years from now. It doesn't look like there's anything around that I would choose to replace it (though I have to admit Vue is a contender if only because it seems more beginner-friendly) but I've gone through enough technologies all over the stack not to make the foolish assumption that the things I use today will be the things I use in the future.
I was confused by hooks, so I paid close attention to the demos and explanations. I learned how they work and why they have the limitations they explicitly tell you to be aware of. That's when I got truly excited. Not because I was dazzled but because I saw the potential and understood how they compared to what I am already using.
Stoic sarcasm went out of style in the 90s. Maybe you should give empathy a try. Maybe, just maybe, some of the people who are truly enthusiastic about hooks aren't simply naive, maybe some are enthusiastic because they do understand how hooks work and what implications they have.
In the exact same way that some of the people who are not enthusiastic aren't people who haven't looked at Hooks and don't understand them. Maybe they aren't enthusiastic even though they do understand them.
That is exactly the point. Not your experience since the 1990s or my sarcasm, but not assuming that if someone does not agree with your view must be because they don't understand.
Negativity is the cultural norm on HN so much that many people look at HN ("the orange website") the way HN looks at Reddit.
I'm not talking about constructive criticism, heck even non-constructive criticism would be a welcome addition if at least it attacked something more foundational than e.g. "relying on call order is a footgun" (which btw is true but ignores the many footguns involved in the APIs hooks are replacing).
You haven't given a single argument why "hooks are bad if you understand them". That makes you indistinguishable from the usual drive-by negativity. If you want to appear like you have something to say, maybe you should actually say that instead of just insisting your opinion is based on something substantial.
For the record here are the top level responses to the original comment I responded to:
* omeid2 says hooks are change for the sake of change and they only help saving a few keystrokes
* geezerjay says hooks bring nothing new (then pivots to "no new features" when pushed on it)
And then there's my comment where I say HN is jaded.
The first response by omeid2 is demonstrably false: hooks allow collocating all code related to aspects of your components that previously resided in lifecycle methods. They also get rid of the leaky abstraction of `this.state` and `this.setState`, make it easier (read: less error-prone) to respond to prop changes and eliminate the indirection required to consume contexts.
The second response by geezerjay is true in a trivial way and false when taken at face value but further downthread he doesn't elaborate and instead just insists he's not being understood.
Meanwhile your entire contribution so far can be summarised as "no you" at worst or "some people don't like hooks even though they understand them" without going into any tangible specifics at best.
React changed the way developers reason about UI/DOM from imperative to declarative, the holy grail here is that a declarative API allows you to move up your state and have a "single source of truth" and so makes it easy to reason about your application's state at the cost of having more plumbing, for example consider incriminating the value of an input with jQuery (imperative) vs React (generally with Redux).
What Hooks does is move the component's state management from components root a level deeper into hook functions and advocates for reusable state management functions that manages various fragments of your component's state, this I believe is a step backwards in terms of simplifying how you reason about state management in terms of complexity --not lines of code.
I am just not sure if this abstraction is worth it in practice and a good step for React.
You've missed the point entirely. Hooks offer nothing new because their functionality was already implemented in React class components.
They literally add no functionality to React. The docs actually state quite clearly that developers are discouraged from replacing class components with function components.
React doesn't offer new functionality to do UI. It offer new ways to think about the problem.
Hooks doesn't offer any new functionality over `this.state` and component life cycle, it offser new way to think about the problem.
Again, you've missed the point.
Could you link to where it says this? My understanding is that hooks are intended to be the new best practice, and ideally all code would use hooks (which the React team believes are overall better than class components), but the React team doesn't want to force migration pain on everyone. So as I understand it, it's not that a class -> hook refactor is "discouraged", it's more "don't let this be too much of a distraction, and don't feel obligated to rewrite old code".
You're also misrepresenting what the docs say about replacing class components. They're saying that you don't need to replace class components just for the sake of using 'the new thing'. However if there was some concern you wanted to extract from a class component that you could not previously, you absolutely could adapt it to use hooks, and then extract and reuse that concern in another component.