Nope, I'm with you. React inventing a half-baked, partial re-implementation of objects/classes (in a language that already has them!) with super-weird declaration syntax & runtime behavior, just to avoid telling their userbase "Ok you will have to use classes sometimes, for certain functionality", was when I started looking around, because they were clearly out of real problems to solve that were sufficiently good-looking-on-a-résumé, and it was just gonna go downhill from there.
* SHOW HN: UberTinyUltra.js Here's my new super light-weight 4k Javascript Library!
* How I switched to UberTinyUltra.js from PopularFramework.js and simplified my life!
* SuperCoolStartup switches to UberTinyUltra.js
* How I built my unicorn on UberTinyUltra.js
* UberTinyUltra.js 2.0 now with a compiler, classes, typesafety and a C++ like turing complete template language to take on the big enterprise jobs because we have too much time, attracted a lot of developers to the project, and ran out of obvious simple features to implement!
* I hate you UberTinyUltra.js you are too complicated.
* ShowHN: SuperTinyMega.js Here's my new super light-weight 4k Javascript Library!
Often, things don't get bloated because the developers are bored, it stems from users requesting features because they are doing it wrong.
Sort of how AWS keeps mucking with Lambdas so that thier customers can keep doing it wrong and paying too much.
Or how doctors just give patients scips if they ask about a drug and it won't incur them any liability.
Over and over I have seen the world shout the praises of a new paradigm that solves a problem...except they totally misunderstand the concept and run in an unintended direction. No one can fight that momentum. So they don't. It happens with nearly everything in tech.
I still remember the Parcel or Prettier saga. The first, the no-configuration bundler, the other, the no-configuration opinionated code formatter.
Then, for their next big major release, the big feature was adding configuration to make it even more powerful!
I haven't used them in a while so my memory might be hazy, but this is exactly the phenomenon you've described. I wonder if it's insecurity or trying to please the crowd that simple niche tools in the frontend end up being configurability behemoths. There's always a time in a JS library where someone decides to rewrite the whole thing and add plugin support, and that's the time that library goes to shit.
Over long enough time you get Webpack, with more knobs than the Linux kernel, and cycles back to a version that tries to be smart and not require any configuration anymore, like 1.0 did.
Well. Life moves in waves, but historically, over a long enough time frame (and if we manage not to kill ourselves), more lessons will be learned than lost, and life gets increasingly better.
Oh, absolutely. Pretty much every distinctive feature of prototypal OO is best classed as "please, never ever actually use this". Adding the "class" sugar and general agreement to pretend the prototypal stuff isn't there, though, made JS OO usable-enough. But yeah, it's not great.
This thread may have an OP who prefers classes, but I'm for one 100% in favor of hooks. You could struggle and suffer to solve them with classes, or you could move on to something better.
It is purely because `this.state` is hard for V8 to optimize, nothing more and nothing less. They did it for their own purposes, for better performance on low-end machines. You can almost certainly just use classes for 99% of use cases
Additionally, the React team has talked about how hooks and function components allow them to have "forks" of the component tree in various states of partial completion at a time, for use with Suspense and transition features. This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance.
One of the few reasonable comments in this thread.
Hooks are better than HOCs, no this is better than managing this, and dependency arrays are better than if (this.props.fooBarBaz !== newProps.fooBarBaz || this.props.onFooBarBazChanged !== newProps.onFooBarBazChanged || …)
> This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance.
So `this.state` is hard to optimize?
> Hooks had nothing to do with v8 optimizations or `this.state`.
Huh? That's what you just said. The spec makes it hard to optimize. The JIT compiler can't infer enough about the shape of the data.
It's not about "optimization" in the sense of "how fast can the v8 interpreter execute lookups on the class instance" or anything like that.
It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"?
> It's about "when this function executes, what data does it see, and did any of those values get changed out from under it in a way that could potentially break the logic"?
You're just describing the semantics of functions versus classes, and the consideration has existed long before hooks came around for exactly the reasons you describe. This discussion has also existed long before JavaScript, React, or hooks existed obviously. It's secondary to the discussion because function components have existed for a long time.
None of what you're saying changes the fact that replacing classes and lifecycles with hooks was done despite the fact that 99.9% of the API users would never care about the performance implications of classes, while that is precisely why the React team made the change. JavaScript is plenty composable with classes and without nested useEffect calls, which is one of the most absurd foot gun APIs that I have seen released in my entire career.
I'm legitimately curious. Can you point to a single actual source to cite "the React team made the change to hooks because of JS engine performance"? (and when you say "performance", you _are_ talking about literal instruction execution time / JIT behavior / etc, that sort of thing?)
I'm pretty deeply tied into the React ecosystem, and I honestly can't remember _ever_ seeing that mentioned as a justification.
If you can link me a reference with them saying that, I'd both be interested in reading it, but honestly surprised to see that stated at all.
Funny that this whole hooks mess could have probably been better resolved with investment in developing optimization patches for v8 rather than attempting to "fix" React
How would Facebook convince the community to dogfood their new API without some marketing buzz? It's pretty obvious that V8 has trouble optimizing changes to object properties because of the design of the spec, and they were also pretty open about it in the blogs where hooks were introduced. I think it's also clear that useEffect is harder to grok than it's lifecycle equivalents, so there might be other things at play than composability.
It's also a bit funny that certain kinds of people can just brush off these things with some non-sequitur on a message board when there are almost always bigger things at play.
I was just going off my own experience with React through the years. It was very hard to compose behavior with class based components. We had to create higher order components that had functions as children which could pass down data as arguments to the child function. It really made a mess of the component hierarchy. Now you can create reusable custom hooks that can be used from any component.
Mainly Vue. It's OK and pretty widely used, which gets you decent library support and such. If I were starting from scratch and didn't have organizational/team inertia & experience to consider, I'd probably give things like htmx a hard look.
I'd have to re-evaluate the current Android landscape because it's been a while, but I might still consider React Native only for that platform, because having RN smooth the rough edges off Android dev made it a lot more pleasant and quick, with far less time lost fighting the platform and working around/replacing bad 1st party stuff piecemeal. But maybe it's gotten better-enough in the last 4ish years that it's no longer tempting to drag in RN just to avoid native Android dev.
In general though, I just no longer default to advocating React for highly-interactive sites or "webapps", as I did for a while.
Class components were/are just fine.