I found an interesting article by Andé Staltz and want to share.
I found these quotes interesting, and counter to some of the anti-Blaze arguments we’ve read on this forum:
React’s community claims that React uses functional techniques heavily, however that is not true in practice. OOP, classes, callbacks, and this are commonplace, as well as imperative method calls such as dispatch, setState, etc. This also means there is no clear interface/gate for I/O and effects.
I keep hearing how React is easy to reason about on these forums, this seems to contradict that somewhat:
In React/Redux … you can spread effects anywhere, which makes the “model easy to reason about” claim crumble.
As Dan Abramov pointed out just today, there is no de-facto standard for I/O, effects, and async in the React/Redux community. The existing solutions are interesting and elegant in themselves, but the problem of I/O is systemic since React does not specify a clear interface/gate for effects coming in or going out.
Spaghetti and React/Redux in the same paragraph, this was one of the first arguments from the anti-Blaze camp:
In Cycle and Elm, even virtual DOM rendering needs to pass through the explicit I/O gate. All of this adds to a “spaghetti effect” in React/Redux: some effects are well separated, others are mixed elsewhere.
I wonder what this means? I keep hearing from the anti-Blaze camp that React/Redux separated the “right” concerns, whereas Blaze didn’t separate concerns but technologies:
As a paradigm to reason about and get features done, React/Redux adds verbosity and does not provide structures for separating concerns (I am not talking about separation of technologies such as HTML/CSS).
I like how he broke out the aspects to consider when picking a Front-end technology:
- Learning cost
- Paradigm ergonomy
- Community size
- Feature coverage
He states at the end that:
This post is just to clarify how React/Redux is not the best in the “Paradigm ergonomy” aspect.
Cheers