[shaunpersad]

IMO React started going off the rails when they introduced hooks. The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away. On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion. RSC seems to be history repeating itself.

[athesyn]

Hooks solved a real problem and I have not heard a single experienced React developer say a negative thing about them.

[calderwoodra]

Totally agree. I've been developing with React for a couple years and before that I was an Android developer for about a decade. React is such a breeze to use compared to the complexity that goes into developing with other frontend frameworks.

[eyelidlessness]

Okay, I’ll volunteer. Hooks solve a real problem in a really unidiomatic way that makes real code hard to understand. They put invisible function boundaries around return values and create state machines inside the body of functions which don’t correspond to the actual function body.

I could say the same thing about Solid and its reactivity, and I have. But at least with Solid you know where the magic begins: an opening JSX tag. With hooks, it’s everwhere and you can’t know where magic and non-magic share a space because it’s externalized to linters which have limited capabilities to cross module boundaries.

I don’t like any of this magic but I’ll take “it happens predictably at an angle bracket with a well defined next character” any day.

[kaba0]

The magic used by react is very limited, one just really has to look a certain way for a few function calls, as if they were declarations and not abuse it. It’s also not particularly hard to grok what’s behind the “magic” if someone is that inclined - there are frameworks with orders of magnitude more of that.

Sure, solid is better in that respect, but react couldn’t have done any other way if it wants to work without a compile-phase.

[eyelidlessness]

Both of them have the same magic, just different variations of it. They both create artificial thunks around something, with special memoizations you haven’t defined right outside of them. React does it at the outside of a component, regardless of how the component is defined. Solid does it at the outside of the outermost angle braces of the returned JSX expression. Both are “spooky action” as the saying goes. Both are “at a distance”, but Solid can much more easily be reasoned about.

And I have no idea why people (including React team members) keep saying React doesn’t have a compiler. That’s literally the only thing that makes it not plain JS.

Edit: and the compiler isn’t as specialized as Solid’s dom-expressions, but it’s definitely not just a DSL over an otherwise equivalent function call. There are special cases for specific props, and they have similar special case rules with Solid. And that special casing has only been more true over time, some people used to write React.createElement directly, but I think approximately no one writes the new jsx(…) directly because it’s specifically intended to be a compile target.

[diob]

Yeah, I jumped ship from Marionette / Backbone when hooks came around, they finally got me to go "wow, that's way way better".

[seandoe]

I've used react daily since the early days. I like hooks but I don't really know what the _real_ problem was that they solved. Getting rid of class components?

[shipscode]

I agree. Hooks was the Angularification of React in the sense that it introduced many library-specific concepts and caused a deviation away from barebones JS.

[imbnwa]

I think hooks made sense, as they gave React the last inch of control over the user call stack to make better, more uniform scheduling decisions; Solid.js demonstrates the idea more clearly in much more idiomatic JavaScript. However, their messaging and documentation were not at all clear for me at launch, to the point that I refused to interact with them for years.

The rest though, yeah, I dunno

[jauntywundrkind]

> The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away.

Oh sure, there's new things to learn. But hooks encapsulate & contain the complexity much better than they used to.

I can only laugh to myself at the idea at class-based React or HoC was some halcyon "intuitive" React era. What we have now can be basically read top-to-bottom, with much less needing to deeply know lifecycle implications & complections & puzzle out implications each time we go to understand how a thing is behaving.

> On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion.

Can we use them poorly? Sure. Did we rush to play with the new tech? Absolutely! My though, it's sad to see this portrayed as a negative, as a strike against: this is how we learn! Open-source is strengthened by diversity, by learning in the wide. Initial adoption will be chaotic, but that vast experience leads more quickly to a healthier better normalized set of end behaviors!

The historical precedent for software framework development is having controlled, restrained ecosystem growth largely by a software giant or elite team, who is responsible for making perfect choices that everyone is going to have to live with either forever or until everyone's sick of all the old mistakes & makes a brand new library (like the long long long sequence of Microsoft frameworks for native & web). React by contrast as kept being successful because it keeps distilling out small core central ideas, and letting the ecosystem explore and innovate at the frontier with those ideas. Cathedral vs Bazaar models.

There's a lot of people whose idea of control and order is to believe in top-down systems, to believe in only guided careful controlled evolution. But this isn't the open source way, and, in my view, that way always leads to fragility and weaknesses. Including too many batteries in your solution leads to ossification & stagnation. Robust, long-term, good answers emerge only over time, only with lots of practice. And we're in such a beautiful age, where peership matters, where we have taste & sensibility to discern out of the many examples put before us what looks right & what looks good. These are the strengths of our era, our ability to iterate forward.

And with React Hooks, I think we're quite decently into the adoption curve. It's 4 years down the road from their introduction (16.8, in February 2019). I have a hard time imagining having to stick with the old ways. The old code that our small org refactors & cleans up is awful by comparison, is much less clear to read, has complex HoC concerns that rebuffed & scared most people. Meanwhile I think the ecosystem has really grown a very sophisticated smart sense of how hooks can & should be built, and is doing really stellar works with incredibly advanced hooks, that span front & back end both, which I doubt would have been a feasible wide-scale target previously.

Where we are is better. With great possibility & progress comes upheaval, yes, but it'd be a shame to dread it. Our designs are imperfect, our architectures ever apt for iterations; that we can adapt forward with grace & on so many frontiers - while still ending up speaking the same core language - all at once is truly a modern marvel. I can't imagine any better paths that what we've done.