[tleb_]

Another way to describe what has been done: implement a pure function and avoid storing additional state. It sounds way less dumb that way. It is not really a pure function but the spirit is here.

I've done the same during a refactoring of a side-project recently. It handles the input/output to a MIDI controller with many buttons, knobs and matching LEDs. Instead of computing what LED should change at regular interval, I am switching to recomputing the whole state each time. No more complex logic, no more mutable data. Only a pure function that outputs the desired LED state based on software internal state. Then a diff is computed and only changes lead to MIDI messages. Code is less efficient (for 100-ish LEDs) but much more straight forward.

[pavlov]

This is how React works, or at least the illusion it presents to the developer.

Where it goes awry and gets complicated is that web developers want to modify the input state directly within the same functions that produce the output state, and they also want to trigger side effects after the output state has been completed, requiring another pass.

I’ve built a React variant for video compositing. Since it renders at a steady frame rate, there’s no reason to ever trigger re-renders. The useState() and useEffect() hooks are practically useless. To my personal taste it’s a sweet spot for React, and I wonder if some kinds of web apps might benefit from similar simplification to the state approach.

[recursive]

I've also struggled with React's insistence on immutability. What if mutability was the only way to update state? I implemented a JSX-powered react-alike that explored the concept[1]. To my lack of surprise, I found the resulting environment easier to get stuff done in. I'm not subjecting my employer to this, but I would totally use this on a solo project that I had to support.

[1] https://github.com/tomtheisen/mutraction

[_heimdall]

IMO react made way more sense when it was used only as the view layer. What react really needed was a separate paradigm for business logic. Having a state machine tied into react is really interesting to me though I haven't seen many try it, and I personally don't use react often enough to give it a go.

React's render loop, and even JSX itself, makes plenty of sense when the data is just fed in and rendered. It falls apart really quickly when data is being changed from inside a component rather than must firing events, leaving us with a decade worth of duct tape trying to find a solution that works long term.

[1-more]

This is roughly The Elm Architecture https://en.wikipedia.org/wiki/Elm_(programming_language)#The...

[rasz]

While this sounds elegant, its also computationally more expensive.

[tleb_]

In my MIDI controller case, the "compute state and send update" code takes about 8µs, up to a spike of 15µs. The worst case of the code in article is a sort on each frame on a 100ish array, it sounds safe to ignore. Profile before optimizing.