The article says that more than a dozen other of her ads were not taken down. So it is not like they were _all_ taken down, just a single one that carrier the logo.
You make a lot of points about Rust and mention Firefox in your conclusion, right after saying Firefox is by and large not Rust. I think your logical argument would be better served by using clear language and a single subject. After you have those two things you can think about coming up with examples.
The crowd is too fatigued to get excited anymore, there is a handful of outspoken people who will cheer any change for the sake of change or saving up a couple of key strokes at the cost of long term API size and maintenance burden. but it is getting tiresome.
Nah, HN is jaded as usual but every React dev I've talked to outside HN has been looking forward to this day with excitement ever since hooks landed in alpha.
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?).
Yes, it gets a bit tedious seeing 90% of comments on HN being from people who clearly haven't tried the thing, or even given it any thought or consideration beyond an initial "this is not familiar to me so therefore bad!" kneejerk reaction. It's not a great look for a developer and I don't know why they seem so proud of their close-minded attitude.
Yes, it gets a bit tedious seeing 90% of comments from React fanboys being from people who clearly just repeat each others arguments, or even give no argument at all beyond "I'm assuming you are stupid because people who are not clearly all love this feature". It's not a great look for a developer and I don't know why they seem so proud of their close-minded attitude.
This is basically the NPC meme but for technologies instead of politics.
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.
> 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.
Here's the thing though: people who use React and comment on React news on HN are a tiny fraction of the overall React community and due to the nature of HN a lot of people comment on topics they don't have significant interest in.
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.
I said nothing about loving, or even liking, hooks or React itself. That's not the point. It's weighing in with a completely useless opinion based on a second's thought, over and over again.
There are trade offs and it's interesting to discuss those and to criticise them. But a kneejerk reaction can't go that far.
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.
"No new functionality" and "nothing new" are two different things. Improved developer experience, decreasing the surface area of bugs, etc - all examples of definite improvements that are not technically new functionality.
How did you extract concerns from class components and reuse them previously? Easy and hygienic extraction and composability of concerns literally is something new enabled by Hooks that was not offered by class components.
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.
> The docs actually state quite clearly that developers are discouraged from replacing class components with function components.
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".
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.
I got the sarcasm, but comparing what Hooks brings to table to what React did is unfair. Hooks are moving around state management, React was a paradigm change.
Have you benchmarked cluster VS locks and threads approach?