Why React/Redux is an Inferior Paradigm

react
1

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

3 Likes
2

I’m on my phone right now but want to chime in that it’s worth considering react and redux separately, and possibly avoiding the functional kool-aid. I think React is a groundbreaking technology for frontend rendering, will follow up when I’m back in front of a real keyboard.

5 Likes
3

I’m not anti-Blaze, very fond of it actually. My first few largish apps were built with it. I did a small blog in React mostly to teach myself and found it a bit confusing as I was going. The most recent project I started has been in React out of choice - it just makes sense to me now as an approach. I’d try Redux but I still can’t figure out why I’d need it with Meteor so not sure it’s really helpful to frame the choice as Blaze vs React/Redux.

I honestly don’t know if I’d have adopted Meteor or taken to it so readily if I had to learn React at the same time. It’s not that React is difficult in itself, it’s just so foreign to everything I had done before. Blaze is comfortable coming from a HTML background or framework like Django.

1 Like
4

I really liked this article. The title might be a bit click-baity but the author mentions at the end that it’s because it is a reaction to people on Twitter claiming that React/Redux is the winner and that we can stop evolving.

I think it’s pretty clear that React/Redux has won over a lot of people, and will probably stay that way for a decent amount of time. Nevertheless, it would be naive to think that a couple years down the road we won’t be even further along with something else.

Springing functional programming onto the masses has to happen gradually, you can’t just drop people into the deep end of the pool. Otherwise, people will see functional programming proponents as religious zealots. I’ve been on both sides, so I understand why people react the way they do (pun intended).

It’s true that React doesn’t go all the way, but it’s a damn good step in the right direction. I hear Dan Abramov is writing Redux 2. Perhaps that’ll take us closer to a better programming paradigm.

Articles like these may rub some people the wrong way, but they are still extremely valuable because it allows us to explore ideas we may want in tomorrow’s mainstream framework.

1 Like
5

if you dont like react you don’t have to use it

1 Like
6

The founder of Cycle.js is comparing his language to someone else’s.

1 Like
7

He states that much and it doesn’t take anything away from a good article. This fact kinda makes him more credible actually.

2 Likes
8

One of the talking points I aways here in the forums is that React in and of itself is so very functional and “pure”, I’m surprised you call this aspect of React kool-aid.

But then again, the driver behind MDG’s decision to adopting React is its popularity correct?

So out of the following reasons to adopt a Front-end technology, React wins on Community size, and for MDG this is enough to get you into the Meteor front end club. Are there other criteria that will get a Front-end technology in the door with Meteor?

  • Learning cost
  • Paradigm ergonomy
  • Community size
  • Feature coverage

I understand MDG will not be completely integrating with one UI tech like they did with Blaze and one will be free to use any of the “approved” Front-end choices, having said this:

In terms of Learning cost, Feature coverage, and Paradigm ergonomy is the React framework really the best choice for MDG to put in the extra effort for a smooth experience on? Is React really the right tech to recommend to new Meteor users? Why not consider at something like Cycle.js for example?

9

holy… :laughing:

In all seriousness, Elm is nothing short of stunning for a front-end language. I’m actively working to learn it, and would advice anyone who’s interested in functional programming to try it out. There’s a bit of a learning curve (it’s functional, it’s a new language, etc.) but it’s incredibly intuitive and concise. I really hope to see Elm ported into the server side aswell, and I believe Evan Czaplicki has mentioned he wants this as well… Here to hoping!

4 Likes