Hacker News Reader

Comment by MuffinFlavored | Hacker News Reader

I feel like there are 2 Reacts (at least 2 that I know of, if not more).

I learned jQuery long ago, then how to get most of what I wanted done via document.querySelector/etc instead since it was more "lightweight", then I learned React "class components" with render() and componentWillMount() and it was a big leap forward.

The "major breaking changes" (semantic versioning wise) to move components to functions (instead of implying it's just a class with render()) and then hooks on top, it almost invalidates most of what I learned about React initially. Which is fine. The community reserves the right to grow however they want. I was just surprised when I recently revisited it. The only common concept was basically JSX and "view/render state/props + actions on events".

I don't think many would agree to this but I'd argue the changes are so radical that they almost should've called this new React something entirely different. It would help. Saying "I know React/I have React experience" is basically in need of nuance like "I have React in 2018 experience, and 0 React in 2023 experience, therefore I don't actively/actually know current React best practices or how to even do a small TODO hello world list example".

View on HN

I sometimes feel like there are three. The class components way, the hooks way that everyone has been doing it up until a few months ago, and the hooks way that the beta docs say you should do it. Maybe those last two aren't different enough, but the clashing philosophies around useEffect are enough to require massive refactors.

EDIT: I'm referring to how the proper use of useEffects is to almost never use them. They're for side effects, and they're not a tool to just "re-render when these dependencies change". But to do this right, it requires a re-wiring of the mental model of how to do React, at least for many people I've come across.

This isn't a recent development. People misusing useEffect just to update state has been a thing in React since they were introduced, even though a close reading of the original hooks docs should have conveyed that that's not what they're for. I think the new docs certainly make it clearer what the correct usage is, so now lots of people are finding out that their mental model isn't quite right.

Some of this predates the introduction of hooks, as much of the useEffect misuse is identical to the way people misused componentDidMount/componentDidUpdate/componentWillUnmount.

I don't think you're right to say that you should almost never use them. You should use them for doing the things which they're designed for, like attaching event listeners or dealing with timers (neither of which are that unusual in my experience). But like I said, they've never been a tool for dealing with rerenders, and the React team has been trying to explain this to people for ages. The original docs did explain this, but it was less clear than the new ones.

Exactly, this is the same as saying Redux has two methodologies, the "setter system" and the "event system"; since it wasn't that well documented initially doesn't mean that the setter way was ever recommended (it's not). In fact if you watched the Flux youtube talk, something highly recommended to learn the philosophy behind Redux, it was pretty clear.

Edit: here's the video (from 10:20) https://www.youtube.com/watch?v=nYkdrAPrdcw

As a misuser on hobby projects, what is the best way to do an initial API call once the main component has mounted?

I was using useEffect, with the deps being the things sent to the query.

It seems mostly expected to have a framework or library in place that takes care of data fetching for the root component.

The new docs emphasize this, I guess mostly to make users think twice about building their own hook and to make it easy to move initial data fetching to the server.

Frameworks include next.js, remix or vite-plugin-ssr (the last one is maybe an outlier, as it deems itself a library).

Often fetching is tied to routing, which makes sense.

If routing is not needed, AFAIK the go-to solutions right now are react-query or SWR.

https://swr.vercel.app/

react-query has a nice comparison table for data fetching libraries:

https://tanstack.com/query/v4/docs/react/comparison

If routing only takes place on the client, react-router also includes data fetching features:

https://reactrouter.com/en/main/guides/data-libs

I don't know how well react-router fits with SSR.

If none of that fits and the requirements are either very simple or very custom, it should still be possible to manually pass props to the root component.

Looking this up in the docs, the big caveat of this unconventional approach is that props would not be reactive, the root component would have to be manually re-rendered:

https://react.dev/reference/react-dom/client/createRoot#upda...

For what it's worth, "the deps being the things sent to the query" is fundamentally correct. What were you doing wrong before and what are you doing now? There are alternatives to making queries with useEffect which can result in a better user experience. Were you alluding to those?

One of the sources of confusion I see the most around effects is that people still think of them in terms of components mounting and unmounting. However, effects only care about running, cleaning up, and maybe needing to run again. I can't think of a case when they'd need to know about the component's mount/unmount behavior.

For effects, the main things to consider are:

• Can this effect be fired unconditionally, and if not, what could change in the system to make its result inconsistent/outdated with the new state of the system?

• What cleanup does this effect need?

I think the "new way" was always the intent. If the past norm is different, it was probably a communication issue (which the beta docs are trying to address)

It’s very clear useEffect was created with a certain purpose and then the React folks realized that was a terrible use of it and changed the purpose of useEffect.

And this would have been fine if they had been upfront about how they were wrong about useEffect and how now this is the correct way to do it. But instead, they’ve at best kept silent about this transition, and a lot of people strongly attached to React have decided to gaslight everyone else about useEffect (I’m a huge React fan… it’s my default UI library but that doesn’t mean I’m ok with gaslighting over transparency).

And the easiest way to prove this is to compare the docs.

Original: https://legacy.reactjs.org/docs/hooks-effect.html

> The Effect Hook lets you perform side effects in function components:

New:

https://react.dev/reference/react/useEffect

> useEffect is a React Hook that lets you synchronize a component with an external system.

Synchronizing with an external system is completely different behavior from performing side effects. And we know the original intention was to perform side effects and not sync with external systems because the name of the hook is useEffect and not useSyncExternal.

Unless the React team always had the new intention but deliberately decided to mislead everyone through the original documentation and by misnaming the hook, but I don’t think even the biggest React hater thinks so poorly of them, and I’m a fan.

I mean, I would argue "synchronizing with an external system" is almost synonymous with "causing side-effects [on render/state change]". Maybe "synchronizing" is a narrower subset of "effects", but I think that's less of a change of the intent and more of a refinement

And I do think the team has been refining this conceptual territory as they go. React is a pretty unique programming paradigm at this point, there's lots of uncharted territory. Following Dan Abramov on Twitter, he works through concepts out loud, having new realizations about how the primitives they've created fit together, what their implications are, metaphors for thinking about them, in real-time. I think they've got a very clear direction at this point, but they haven't turned over every stone along the way yet.

> It’s very clear useEffect was created with a certain purpose and then the React folks realized that was a terrible use of it and changed the purpose of useEffect.

I've compared the docs, and I don't think that's clear at all. They definitely refined their messaging, but the legacy docs show the same sorts of examples that are either shown in the new docs or described[1], such as subscribing to an event system or updating a bit of non-React UI. Could you give some sort of example usage that they encouraged before but don't now?

[1] https://react.dev/learn/synchronizing-with-effects

> Synchronizing with an external system is completely different behavior from performing side effects.

No, synchronizing with an external system is exactly performing side effects. It is a change in document focus from a description that focuses on what it does to one that focuses on the purpose for which it does it, but all synchronization with an external system is side effects and the vast majority of side effects that aren’t incidental to imperative program structure (which functional components avoid) is syncronizing with an external system.

I'd agree.

I haven't tried asking GPT4 a bunch of react questions yet. I wonder if its advice is generally in accordance with the "new way", given the training data cutoff date.

What's the new way as of a few months ago? The docs way?

They may be referring to React 18 + Strict Mode meaning all useEffects can be called as many times as React wants. People before were writing code where useEffect on [] worked like onMount and was only called once.

The entire hooks "thing" felt like a case of the library authors being too clever.

Having components with lifecycle methods called at known times by the framework is a perfectly straightforward mental model. It's worked just fine since the beginning of time. iOS still uses it.

I remember investing hours (and days and weeks) migrating old code to the "new way" or trying to get some simple thing "working with hooks." Other than being able to share in the authors' feeling of smugness over the unnecessarily-convoluted mental model when we finally got it all working, I genuinely can't recall any value we got out of the whole investment.

I agree. Hooks felt to me like an attempt to go all-in on functional programming when components are perhaps easier for many people to think about as classes due to the unavoidable need to have state in the component. It seemed like an attempt at purism that, instead of making things simpler, made them, at least cognitively, a bit more complicated due to the irreducible complexity of state.

My experience has been the opposite. With hooks, it's now possible to decompose a concern and modularize it in full. Having logic for dealing with a concern spread over willMount/didMount/shouldUpdate/willUnmount was a total mess. It's bad enough with one concern, but if a component has 3 or 4 concerns that span across the lifecycle, it quickly became unwieldy. And for all the complains about people using `useEffect` wrong, I saw just as many people using setState calls in lifecycle methods and crazy things happening in mapStateToProps of class components.

In the end, hooks have greatly simplified things for me.

It turns out much of s/w development is a cult (many cults) with no basis for their teachings.

> Having components with lifecycle methods called at known times by the framework is a perfectly straightforward mental model. It's worked just fine since the beginning of time. iOS still uses it.

Android, too.

What's so infuriating about that is the documentation basically told people, hey instead of doing this, use useEffect the way you were using these methods.

So are the users wrong, or did you screw up?

> So are the users wrong, or did you screw up?

When you have to rewrite the documentation to basically tell the world "you're holding it wrong" then it says a lot about the thought that has (not) gone into designing the feature.

And that's why I think I'm done with React for now. It just does not spark joy.

If you're ignoring dependencies that should be on a call to `useEffect`, you're just making room for bugs.

If you're not properly tearing down what you're doing in an effect, you're just making room for bugs.

These have always been true of useEffect.

Then how do I emulate onMount now?

You have to use a useRef then inside your useEffect of [] you check if it is false and it it is you set it to true then run your code.

If anyone reads this and I am wrong please comment, but from what I can see that's the only solution.

What are the clashing philosophies?

I'm not sure about the clashing philosophies, but useEffect is certainly a "nexus of difficulties" about learning and using React (with hooks), in terms of the mental model it requires, knowledge of not-so-obvious JS concepts like closures, etc..

I think it’s more a matter of how the JS community has grown in general. The whole “class” thing is something a lot of us brought into it when we came from other OOP languages, but in 2023 it is very rare that it is “better” to build a “class” than to simply build the functions you need.

As far as I know you can still trundle on with some of the old react, but at the same time, things change. It’s not like you’re coding C# similar to how you were 10 years ago either. I know that having been away from it, it was interesting to see everyone using “var” instead of types as an example.

I dunno... when you're building a hierarchical tree of nameable components and several, ahem, instances of each nameable component might exist, and these need to respond to signals, that seems like a case when it's non-crazy to use classes.

But that’s not ever what you had in React even when using JavaScript class components.

I believe OOP is generally overused (no, you don’t need a zero-member class to provide related functions; static class members are a code smell; etc.), but I don’t follow what you’re saying. From my perspective as someone who is just learning React recently but has a decade’s experience in C, C++, and Rust, the programming model doesn’t make any sense to me. The functional paradigm used by React has the same fatal flaw as OOP does: rather than making state management simpler, it attempts to hide it (OOP hides by “private” variables, React chooses to hide it in “hooks”). Both seem absurdly complicated to me. There’s no need for classes with trivial setX() methods, and there’s no need for hooks either, to perform what is essentially a variable assignment. They make the code more complicated to read and write, and increase cognitive load, IMO.

A component that has some state associated with it, such that manipulating that state causes certain side effects, seems almost custom-fit for OOP. The functional style does not seem to fit the domain.

Classes and types and methods exist for a reason. They're not "old" you don't "grow beyond them" anymore than you "grow beyond" functions, constants, threads, or files.

Try stepping outside of JavaScript for a while, broaden your experience.

I think we may be talking a little bit in two different directions, because when you write this:

> Classes and types and methods exist for a reason.

What that reads like to me is actually the exact explanation as to why the JS community has fallen out of love with things like classes. Because JS doesn't have static types, and without those, well... Classes don't actually exist. At least not in the way they do in other languages like C++. You can pretend you're working in a regular OOP language, and use the prototype object like you would a C# or Java class but since you don't have static dispatch at compile time, you're frankly playing this part of JS as a weakness instead of a strength.

Which is why the JS community has been "growing beyond" classes.

If working with classes in JS is more comfortable for you, then I think you should do so, but ultimately a JS class is just a function. Once you grow comfortable with working with modules and functions, you're very rarely going to be writing classes when working with JavaScript. You're still going to do so from time to time, when it makes sense, but often its both unnecessary, less efficient and harder to maintain something that is build like a C++ class rather than than a JavaScript function. While working with JavaScript, being a key part of it. This is not an attack on OOP in general, just an explanation as to why the JS community has "moved beyond" pretending JS is an OOP language the same way Java is an OOP language.

> Try stepping outside of JavaScript for a while, broaden your experience.

I do so regularly.

Uhh yes, classes in JS is just function, but it forces you to make a strict definition on how the set of functions will behave, in opposite of defining functions and tied them up individually.

If a thing need properties and methods to operate, defining it as class won't make it harder to maintain than cleverly do it with functions and object.

> but it forces you to make a strict definition on how the set of functions will behave

This would be true if JavaScript had static dispatch, but since it doesn't, everything you do with your class is mutable all the way up the prototype object chain. One of the reasons this is harder to maintain, is because the "strictness" you think you build into your code isn't actually there unless everyone who works on your code after you follows the same rules you did. I'm sure we'd like to live in that world, but I doubt we will.

It's slightly more now with private members, but still prototype based inheritance and definitely not the same. Composition will still usually perform better all said.

If you want something more, better to use TypeScript or step to something like Rust+Wasm.

A JavaScript class is syntactic sugar for prototypes, not functions.

JavaScript is a prototype-oriented language.

> A JavaScript class is syntactic sugar for prototypes, not functions.

Again you're basically speaking into exactly what I'm trying to say. Because what are JavaScript functions? It is also a prototype. I'll try to put it a different way. The JS community has "moved beyond" classes because they are functions. Both classes and functions are prototypes, but functions are often easier to work with, more maintainable and more efficient.

I'm not trying to say that you should never write another JavaScript class in your life. I write them myself when it's prudent to build things in a structure that resembles classical OOP. The reason I don't personally use that sort of coding style, if I can avoid it, is because it's an act. It looks like classical OOP, but everything is mutable at any time which means it's very easy for consumers of the code to break it by accident. This is less of a problem when you build things as isolated modules, based on individual functions, because there simply isn't any complexity to "misuse".

This is sort of similar to why the virtual DOM became so popular in frontend JavaScript. Because it's harder to work directly with the DOM itself. It's not necessarily better to use functions, it's just "safer", because they come with less risk of someone doing something bad by accident down the line.

…no a function is a function and a prototype is a prototype.

So you're just gonna ignore that whole "the JS community" bit then, ok.

Is this what $200/hour consultancy looks like?

Try writing some code in not just JavaScript but also C, C++, Java, and others. Classes aren't some relic. You use prototypes in JavaScript every single day.

You're still just blowing past "the JS community".

To fill you in on the context of the thread you inserted yourself into, classes have fallen out of favour _in JS_. It's pointless to say "but they're still used in other languages!" because we're not talking about other languages, we're talking about JS.

I, too, am talking about JavaScript. Everything in JavaScript is prototype-oriented whether you ignore it or not.

You can choose to write functions for everything, but you're still always using object prototypes.

There are several large popular libraries in JavaScript which do not orient themselves around functional object orientation, too. So you might work in one corner of JavaScript where all you experience is functions, but that's not the case everywhere.

They haven't "fallen out of favor," whatever that means.

Yeah. Functional components are right sized. You can still decompose & hack off pieces nicely, into helpers or hooks.

Just because CS has heavier weight classical structures we can apply doesn't mean they're better. And underneath a lot of those ideas were more lambda-calculus ideas that correspond somewhat with functional components.

OOP was invented to capture patterns already widely used in assembler and C and other old languages.

> I was just surprised when I recently revisited it.

You can STILL write React like you used to (with class components). There haven’t been any major breaking changes. The transition was very slow. It was only recently that they even changed the docs.

You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was.

Sure, React still supports that, for some reason. But good luck getting a job offer or even a PR approved if you're using `this.setState()` in 2023.

Shame. Simple class-based React-components are joy to work with. Flat code layout, simple life-cycle, no new semantics to learn ("rules of hook"), no crufty mem-allocation.

I firmly believe that FP-seepage into web programming is one of the reasons why so many web apps are so slow and feel sluggish, jittery.

The great downfall of hooks, IMO, is that they allow you to create components that look clean and legible, but act unpredictably because all of your state updates are triggered by variable reference changes. The idea is that this makes your state updates happen automagically so you don't have to think about them, but this is a classic example of an abstraction that works until it doesn't.

Redux mainstreamed the concept of reference changes triggering updates, but I think this is a horrible pattern - we don't even have an operator in JS for explicitly passing by reference, so you end up destructuring large objects constantly in order to change one property and create a new object reference, which is a totally inefficient alternative to calling a render method. Plus javascript developers don't generally think about the concept of passing by reference vs value anyway, in large part because the language gives us so few tools for making those choices.

As a result, there is a class of bugs where the only solution is to change the list of dependency variables for a given hook. It doesn't take a huge amount of complexity for the implications of those dependency trees to bend the mind, and the "clean" syntax of hooks comes crashing down.

Thanks for laying out train of thought. I have a heard time putting it into words why exactly hooks don't deliver on their promise.

> there is a class of bugs where the only solution is to change the list of dependency variables for a given hook

++ it does seem to cascade from there.

I can't speak in general, but there is one thing I vaguely remember being on the React roadmap as part of the class->function switch that AFAIK never happened (at least it hadn't last time I did a lot of React, which was years into the switch): Because they were pure functions based on props, React-the-framework would have the class-based shouldComponentUpdate built into it and using function-based components everywhere would get a free performance boost.

Instead nowadays people who started with the function form don't know shouldComponentUpdate ever existed and all their React components constantly rerender.

> You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was.

Wouldn't you expect jQuery to keep using the same fundamental methodology a couple of years later?

I mean, Java was the stereotype of boring enterprise language, and has certainly changed a lot in the last ten years in terms of its shift towards functional-friendly programming.

How is this even comparable?

Not only React changed completely almost overnight, but the changes in the methodology were fundamental.

This is just blatantly untrue. The changes were definitely not overnight. Not even close. You’re still free to write React in the old way. The docs were there for half a decade.

If they had just made a different project, we’d still be talking about the same thing. You would still be complaining that things changed and you didn’t feel like bothering to learn a new thing.

So are the Java 8 changes? Java lambda functions, streams and futures look nothing at all like traditional Java methods and threads, yet you're still free to write them, but nearly every Java Stack Overflow question has a dedicated Java 8+ answer because it is so different.

Note that Java futures are from 2004. By the time Java 8 rolled around they definitely were "traditional".

But lambdas and everything coming in project amber, yeah, there will increasingly be many styles of Java out there.

> By the time Java 8 rolled around they definitely were "traditional".

Based on my experience only once CompletableFuture was added to Java did the Future interface really start getting used in mass. Before that, there were other libs that implemented Future like things (Rx, Guava, Netty, etc) but they were not adopted across the board.

The transition to Java 8 was night and day! Roughly on par with the React Hooks transition.

I fully disagree. It's the exact same internal mechanisms lending themselves identically to rerender semantics and so on. They were exposed with new names and access methods, but enabled you to perform virtually the same component update logics, except with a few antipatterns made more difficult. HOWEVER it is also fully backwards compatible, you can run these old versions.

So, what stayed the same?

* Could still use classes

* Still had the same props & state semantics

* Components still could own state and receive props

* Some renamed code paths were used, a couple of the "componentShouldRender" style ones were dropped to prevent programmers making fatal errors

* Still wrote the same markup

* Still could use the same libraries

I never really understand this complaint; React achieved gold standard backwards compat. Either that or my 2016 era tools building in 2023 on the newest React with old ass libraries would've caused a lot more pain points!

React Server Components (RSC) feels like the third React.

https://nextjs.org/docs/getting-started/react-essentials

I'm not sure I agree with this. It's "different" in that you don't need to learn the intricacies of some new data loading and state management library (we've seen _so many_ of these over the years!). But the concepts themselves are much closer to "just plain React".

True, not as radical as the transition to hooks.

There are no breaking changes. Class components are still supported and used at Facebook

Class components are deprecated. They only appear in the legacy section of the reference.

https://react.dev/reference/react/legacy

Minor correction -- It seems like the page you link to has two sections: Legacy APIs and Deprecated APIs. Class components are not deprecated; instead, they are in the legacy section. The only thing that is listed as deprecated in the page you link to is "createFactory -- lets you create a function that produces React elements of a certain type."

Oh also certain concepts and strategies are only written about in the legacy documentation. Good luck new devs!

Reminds me of a React V11 codebase at work. It is bad enough that I always include it as a heads up during our scoping, as in: "double your estimates because the version of React is so old"

happens to lots of stuff and is not react specific

Care to source/link them? You obviously think they're important so you should do some good and share!

New docs don't tell you how to get a minimal start anymore. You MUST fully commit to a create-react-app flow or similar, or they vaguely point you in the direction of Babel without explicit direction.

The formal way of using React and JSX without a full SPA framework is only listed here: https://legacy.reactjs.org/docs/add-react-to-a-website.html

Ah, I guess you're referring to how they're pushing frameworks over bundlers?

> If you want to build a new app or a new website fully with React, we recommend picking one of the React-powered frameworks popular in the community. Frameworks provide features that most apps and sites eventually need, including routing, data fetching, and generating HTML.

> Grab react and react-dom from npm, set up your custom build process with a bundler like Vite or Parcel, and add other tools as you need them for routing, static generation or server-side rendering, and more.

https://react.dev/learn/start-a-new-react-project#can-i-use-...

Getting started with parcel is pretty damned straight forward.

https://parceljs.org/recipes/react/

> These APIs are exported from the react package

You can still write React the old way.

Sure. But search anything about React, and you'll see examples in hooks.

I don't even understand the reason why class-based is "legacy". Why are hooks inherently better? Code-reuse is a factoring concern, not a paradigm concern. And component-life-cycle bugs are now replaced with nearly impossible to understand callback stacktraces.

That doesn't mean classes are deprecated, it means people prefer hooks, and I understand why, as someone that codes in both.

It's like saying "All Javascript things I search are only in ES2020." It doesn't mean javascript is deprecating features.

> I don't think many would agree to this but I'd argue the changes are so radical that they almost should've called this new React something entirely different.

Absolutely and I've been saying the same thing for years.

IMO it was an extremely irresponsible thing to do considering React is critical infrastructure at this point. And by completely changing the methodology they made obsolete A LOT of educational content (books, tutorials, videos, etc) in an instant. I'm sure people making money of React education were very happy with this.

Don't get me wrong, I'm not against evolution. But if you're going to make such a drastic change just create a new project. Plus I wonder what other improvements/changes they could have made if they had started from scratch.

Nobody is forcing you to use it.

The react devs made a bunch of code migration tools, used semantic versioning, slowly deprecated old APIs over multiple versions, maintained vids and documentation. Honestly compared with some projects they handled the changes and evolution of the API extremely responsibly.

People are forcing you to use it. It's called employment.

God forbid you're a principal running into some junior engineers and they don't understand that you've forgotten more than they know, and the migration to functional components is just another part of your extended career timeline.

If you’re a principal, just ask your juniors to explain their useEffect()-based mess. When they can’t, mandate class components.

I upvoted because yes.

in practice, pick your battles.

Also then in practice, you'll get people shrugging off their hooks get called 10 times iso 1. then maybe add useMemo everywhere just to be sure. Hmm.. still kind of weird. Maybe sprinkle in some more if-thens, that will fix it! Deep breaths..

This is the true legacy of React, and it's awful. It's not just a case of "you're doing it wrong", because even cutting edge codebases (developed in the last 1 or so) are struggling with this.

"useMemo is the solution" many will tell you. Compared to the way things are handled in Vue, useCallback and useMemo are near enough code smells for something rotting in the center of the React codebase.

Then you get a security audit that you are not using the latest whatever and c-suites panic

If you're a principal, you should be able to keep up with modern tools. Making sure the engineers around you are as productive as possible with their current tools and processes is literally your job!

If as a principal, you are no longer able to keep up with tooling / patterns that everyone else at your company wants to use, its time to take a smaller scope or time to retire.

The job, including mandates (if any are needed) is to empower the people you work with, not to stifle them.

Does anyone seriously expect nothing to change and improve for 30 years, or however long their career is? Not just in software, but any profession. Long gone are the days when the same plow is used for 10 generations.

From my experience its not learning something new thats a problem, but getting the organisational support to push a major change through

> Nobody is forcing you to use it.

Nobody is talking about that. Instead is about how these changes could be done without creating so much confusion in the community. In fact people embrace evolution of these frameworks but with clear changes in methodology, labeled as such and so on.

> Nobody is forcing you to use it.

This argument goes out the door if you need to adopt a library that has already adopting them.

Even reagent, an extremely conservative React wrapper, had to provide support for functional components, hooks and effects eventually.

Yeah maybe, so? That's really not what I'm arguing about.

In the words of succession. This is not a serious product.

Akin to JS replacing callbacks with async/await:

1. You can use both styles, even interchangeably.

2. The latter is superior.

Async/await allows you to write asynchronous code in a synchronous style.

Hooks allow you to write stateful code in a stateless style.

Is it really that much of a crisis to have the "0 React in 2023 experience ... don't even know the modern hello world" when one can just spend some time on their (excellent) documentation site and get back up to speed?

This is such a common problem these days. I have almost 15 years of experience with another framework, but the latest iteration is almost a complete re-write and most of what I knew in the past isn't that helpful. To say I have "x" years of experience doesn't really acknowledge my current level of understanding.

the core concepts are the same. the implementation details have changed, but I think it's a stretch to call it a radical change. you could probably learn how to convert a component from class -> functional in a few hours.

This is a kind of career violence intentional radical constant change such that experience doesn't matter maybe those of us pushed out of industry over react should hit meta with a lawsuit.

I can't tell - is this satire? Good faithing it - this could only be (partially) valid if the old ways didn't work, which they still do. If you've been pushed out, you haven't been pushed out of the industry because of the change.

Reply on news.ycombinator.com