As a BE engineer when that happened, I had just started to become proficient in it, coming from Angular. I threw in the towel and went back to my backend world of peace and happiness. So he's not alone, these deprecations are insane.
I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET.
I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
More often you inherit a stack and rarely you move away from it. And even if you jump on the latest infrastructure trends, there will probably be enough enterprise customers that they will support it for a while.
The beauty of this is that these technologies all tend to be optional, backwards compatible, and interchangeable. You make your choices when architecting depending on what you want to solve. You can build Hussain Bolt or Frankenstein. On the FE, just the landing page is a mission.
Most likely because you work on apps in active development.
Wait till someone asks you to add some feature in app that was deployed a few years ago and need something new.
Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?
- they're much harder to learn and understand than the callback hooks from class components
- The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them
- The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others)
- the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm
- they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return)
- the mental model for how to put them together when you're writing custom ones is a little bit funky too.
- the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier
You still can't add features like error boundaries in React without class-based components somewhere in your app. Even if they added these features to functional components today, it would be years before they'd consider them safe to remove.
HOC still exist and builtin features like `React.memo(MyComponent)` along with the like of more functional styles means they aren't ever going away.
But they're not deprecated. Where's the forced churn?
Every place that I've been at has made the gradual shift to migrate stuff away from class components as new stuff gets built or refactored. Seems like a pretty common development habit.
Mea culpa: they’re not being deprecated. But the existence of custom hooks removes the bulk of (if not all of) their utility, and make it much easier to reason about code and make your code well-typed.
