React is holding me hostage

I missed it in the article. How do signals fix react's shortcomings? With signals you still have the same exact state management problem of having these crazy stateful functions. Sure you don't need to deal with the additional complexity brought about by use effect and rerenders but that's only a small part of the problem in my opinion.

I've gotten to the point where I think frontend code should just be modeled as state machines from the start. I like XState but you can use reducers too if you like.

mobx looks the most reagent like state model in vanilla react.

my forever setup is here:

https://github.com/nathants/aws-gocljs

I've been feeling the same sentiment as the author.

Having worked on 3 sizable React projects now (all started before I arrived), I can only conclude that beyond a toy phase -- once you have many hands working on React and *particularly* once you start managing sizable state -- there is only pain.

The most recent case resulted in spending quite a bit of time explaining to a peer why we were experiencing an unexpected side effect and redraw and explaining how `useMemo` and `useCallback` actually need to be used [0] and made me think of Stephen King's Langoliers.

It occurred to me that "React is the new IBM" [1] It has become so dominant in the market that no one can get away from it. But that also means that it can no longer innovate. Andrew Clark's twitter post *acknowledging* that signals and fine-grained reactivity would be better for performance but that the React team doesn't care pushed me over the edge of frustration.

I think that React finds itself not too far off from where IBM was at the micro-computing revolution. IBM had become too beholden to its market and too arrogant in their own success to see their own downfall.

The traffic and feedback on the second article is an indication that there are a lot of folks out there who are really, really dissatisfied with the state of React.

[0] https://chrlschn.medium.com/8eb7bb72c87

[1] https://chrlschn.medium.com/react-is-the-new-ibm-6af2f4b04e5...

I've been working on a React side project for a few months now and looking at my company's apps plus posts like this I think people just miss the point. Stuff like this:

>Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds.

This is just doing it wrong. State should change in response to user inputs. Ultimately, React is f(newState) => UI. If that function isn't pure you're gonna have a bad time. It's hard to blame anyone though. The docs suck and most of the tutorials you find get it wrong one way or another.

That said, there's kind of a reason why functional programming isn't more popular. It can be hard to grok and there can be a significant performance overhead. There's also a reason why this sort of implicit programming isn't as popular as imperative style. It's hard to predict what the implicit behavior is and footguns abound.

Have you seen the debugging tools for goop?

I mean, they're absolutely necessary because the goop is full of insects. But so elegant!