If the layoffs could retroactively slow or halt non-bugfix development on it starting back in 2018 or so, that'd actually be great.

I have come to prefer hooks, but I have never felt they're necessary. Class based React allowed for massive simplification of some setup/tear-down actions.

For someone to arrived late to the party, what’s better / simpler when using classes?

Depends on your use case; some things are easier as classes others as hooks.

i'm a react noob too, but my impression is mostly that hooks are nicer for smaller components with simpler states, and classes reduce some boilerplate if you have a lot of different state variables within one component.

Hook-using functions basically are classes, just with utterly bizarre method and property declaration syntax and some strange and unhelpful behaviors.

I mean, they ultimately associate lists of properties and functions (methods, if you like) with a component object instance (yes, object) down in the React internals. Sure, access to them is FIFO rather than a lookup table, but that still looks a whole lot like very-weird classes/objects being reimplemented in a language that already has decent-enough ones.

Now, the trouble was certain optimizations and features were probably going to be hard to impossible to achieve while supporting both functional- and class-based components more-or-less equally, and the easy path forward was to let class components become more powerful and functional components slip to second-class (haha), but instead they put object/class-like features in their functions so they could have functions (but very much stateful/side-effecty, so WTF is the point?) lead the way, for whatever reason.

Everything in hooks is explicit. Which is a blessing and a curse.

Classes were really easy to compose and automatically easily bring everything you needed into the class. This did lead to some situations where you could over-engineer and get yourself into a bind. You can technically do the same/similar thing with hooks, it just requires a bit more code. Lack of setup/tear down with hooks also means you need to rely on nonces more often.

In general, hooks have a bunch of small, reactive-programming tricks that you learn with experience.

I stopped using React around the time hooks were introduced, and never figured out what problem they were supposed to solve.

I have something that has a lifecycle and I don't want to initialize and destroy the state every time. I encapsulate that into a function, call it a hook, and go about my day knowing that I don't have to care about redoing the lifecycle every single time.

It's basically a class that has pre-written lifecycle functions.

Would be good to know if their 'hooks' experiment comes to some calamitous end.

> 'If React isn't good enough for you to use after 9 years, it'll never be good enough'

I'd argue the opposite - it has been good enough, but now the whole FB platform is old and stale and so is React. 10 years is a long lifetime in the tech world. It will be around for another decade but I'd argue is over the hill in most of its variants. Big next gen opportunities

Can you expand on why? I’m pretty satisfied with React in that it

1. doesn’t try to be a full framework 2. Is easy to explain (without hooks) 3. Has good inner-loop tooling with hot reload 4. Doesn’t have any insane transpiration requirements

What should I try?

Is that all still true with modern react? By the time you explain the rules of hooks, concurrent mode and its hooks, and RSC I think the only one that's true is (3).

@guhidalg there is nothing 'wrong' with React at all, it's mature and debugged. The issue is the platforms it serves are old and something newer is sure to replace it

"Doesn’t have any insane transpiration requirements"

Configuring webpack is insane in itself

That's easy: 'npm create vite@latest' done