Why React/Redux is inferior as a paradigm

To be honest, this whole thing just seems like a vague rant. It&#x27;s full of hand-wavy statements like &#x27;Once you learn Elm or Cycle, getting things done will be more productive&#x27; with only vague anecdotes to back them up, with no specific examples of worked problems.<p>The section on JSX &amp; the React.createElement API is a weird diversion, because these aspects are so unrelated to the high level code structure complaints that they belong in a different article. Putting that aside, this section seems unfair at best. Firstly the JSX syntax is disregarded due to verbosity[0]. Okay, not to everyone&#x27;s taste. However the author then goes on to making a comparison between React&#x27;s createElement&#x2F;createFactory APIs and the hyperscript-helpers npm package, which is incredibly uncharitable as the former is a performant, low level API intended for building ergonomic APIs on top of, and the latter is a high level, ergonomics-centric API.<p>Redux is a small library, which needs to be used underneath application-specific abstractions to avoid boilerplate. Not everyone will want to come up with such abstractions themselves. I can certainly see the value for an ergonomic, high-level, Rails-like project on top of React + Redux. Maybe that&#x27;s the article the author should have written.<p>[0] I would argue many developers actually find the verbosity of JSX helpful when dealing with large trees of components, as compared to nested function calls. The fact that JSX closing tags repeat the tag name is key to this.

Newsflash: Guy who created Cycle.js because he didn&#x27;t like React thinks Cycle.js is better than React. (He also thinks Elm is better than Redux, but I think he&#x27;s significantly overstating the differences between Elm and Redux&#x27;s patterns, and significantly understating some of the drawback&#x27;s inherent in the Elm language, as opposed to the Elm patterns. Developers I know who have used Elm for production projects seem to have very mixed feelings about it, and many have since abandoned it for Purescript.)<p>He&#x27;s probably right about Cycle though, for some devs, on some projects. Then again, I&#x27;ve spoken to people who went all in on Cycle and got burned, and found it inferior to React. A guide to when you might prefer Cycle to Redux would be interesting, but this isn&#x27;t it.<p>(And as others have noted, his comments about JSX versus hyperscript is quite odd. React is not tied to JSX, and you can easily use hyperscript with React if you choose. It&#x27;s just that people <i>don&#x27;t</i>, because most people don&#x27;t find hyperscript as awesome as he does. Which is sort of the article in a nutshell; &quot;X is better than Y because I like X!&quot;)

Cycle.js has the most elegant and powerful component composition mechanism of any JS framework I&#x27;ve ever used. With React you have to be extremely careful in how you design components to make them re-useable and flexible.<p>The inversion of control that happens with Cycle.js makes it really easy to compose components together. At first it feels weird to not manually specify event handlers (e.g. onClick) in DOM-generation code, but as a result there&#x27;s much less embedded opinion on how the component be should be used. Instead each component simply returns a collection of queryable observables, which is extremely flexible and adaptable.<p>It&#x27;s also cool how components have the exact same function signature as a full Cycle.js app, so you can think of your app as being composed of several mini-apps. It&#x27;s very clear Cycle.js was designed with composability in mind from the start.

Everyone has their preferences but personally I have never used a framework that got everything perfect. I&#x27;m not surprised that the author thinks cycle is superior since he wrote the library. In other news the forecast calls for more JS frameworks today with a high chance of more JS frameworks later this week continuing with intermittent churn for the rest of the JS season.

Having worked on a small&#x2F;medium React application after stepping back once the work was complete it began to dawn on me that React wasn&#x27;t the holy grail of web development. The number of packages needed in order to glue parts together, the managing of state at times is just confusing and on boarding new team members can be painful. Not to mention the constant battle with updating packages and API churn of these packages. But what React does have is an incredible community and a very large backing (Facebook). There is also some very intelligent people working on React (<a href="https:&#x2F;&#x2F;twitter.com&#x2F;dan_abramov" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;dan_abramov</a>, <a href="https:&#x2F;&#x2F;twitter.com&#x2F;schrockn" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;schrockn</a>, <a href="https:&#x2F;&#x2F;twitter.com&#x2F;soprano" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;soprano</a> to name a few)<p>The idea of Elm (<a href="http:&#x2F;&#x2F;elm-lang.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;elm-lang.org&#x2F;</a>) excites me greatly but then again what&#x27;s to say that Elm will be dead in a years time? My question, is there a framework out there that mixes the better parts of React (virtual dom, large community), the idea of functional programming and a server side aspect to build the back end in one package?

I&#x27;m currently trying to train a new developer and slowly introduce him to the world of React&#x2F;Redux and only now am I realizing how incredibly complicated it is.<p>I enjoyed learning them and am efficient using them but now I&#x27;m not so certain that it&#x27;s the best choice for a team with developers of different skill level and experience. Once you throw in React-Router even my days in Angular 1.x seemed simpler.

We can&#x27;t maintain something simple for a long time. Maybe that&#x27;s human nature (or developers nature ), but the success of a framework is the start of its demise. Excited contributors will try to &quot;improve&quot; it and that always ends up adding complexity to what was a simple and elegant solution.<p>Maybe the problem originates in the tendency to rate open source projects using metrics like number of commits. A simple and elegant project that does not have recent activity is labeled as dead and people stop using it, even if it works well.

Maybe part of the &quot;JavaScript fatigue&quot; is that, as each shiny new toy rolls in, the ensuing commentary immediately elevates it to The One Solution We&#x27;ve All Been Waiting For --- followed just as quickly by No This Is The Most Flawed Solution Ever They Got It All Wrong And Here&#x27;s Why....<p>The reality is that many species can coexist in the same habitat. You don&#x27;t have to pick just one. Cats don&#x27;t have pincers, but does that have to mean lobsters are superior? Nope.

A little bit of a meta-comment, but I find this article very hard to read. There&#x27;s no clear delineation between different arguments &#x2F; sections of the article, meaning I can&#x27;t skip to find a piece of content I might be the most interested in. Additionally, the hyper-thin content section gives the illusion of a wall-of-text. My eyes have to jump lines every few words, causing an interruption of sentence flow and structure. It&#x27;s very distracting, and the presentation (especially considering the technically-heavy content) hurts the message.

I&#x27;d like for the observable community to finally settle on a minimal common interface (like Promises&#x2F;A+ and later ES6 promises did) for observables. Maybe <a href="https:&#x2F;&#x2F;github.com&#x2F;zenparsing&#x2F;es-observable" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;zenparsing&#x2F;es-observable</a><p>Then maybe cycle.js could come with a more minimal implementation rather than having to bring in a library with a gigantic footprint and 100+ operators (<a href="https:&#x2F;&#x2F;github.com&#x2F;Reactive-Extensions&#x2F;RxJS&#x2F;blob&#x2F;master&#x2F;doc&#x2F;gettingstarted&#x2F;categories.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Reactive-Extensions&#x2F;RxJS&#x2F;blob&#x2F;master&#x2F;doc&#x2F;...</a>)

&gt; Components that expect “onlyChild”<p>&gt; Some React components have an invariant: “Invariant Violation: onlyChild must be passed a children with exactly one child”. Which means this is an error:<p>I&#x27;m surprise the author called this out as a negative of React while saying the compile time type safety is a positive of Elm.<p>If I have something that expects one child, I expect one child, not an array that has 1 element.

I disagree about the jsx, but I do agree about Redux. React is beautiful in its simplicity, but Redux kind of throws all that out the window and adds all the missing complexity back in. Granted, part of that is due to the relatively simple nature of React, but I do think there has to be (and likely eventually will be [I see your eye-rolling]) a better, more enjoyable way to handle state management.

I&#x27;ve enjoyed React immensely, so I expected to dislike this article, but there are a lot of good points in there.<p>This part confused me: &gt; I can confirm React&#x2F;Redux is an inferior paradigm...<p>But all the examples don&#x27;t show a &quot;different paradigm&quot;, let alone a superior one. To me, they show the same paradigm, done better? The conclusion seems to support that interpretation as well.

What&#x27;s wrong with vanilla React&#x2F;Flux? I&#x27;m currently working on a greenfield project and I&#x27;ve more or less settled settled on that stack. I have immense respect for Abramov but I&#x27;m finding it hard to justify Redux when Flux works well.

And what do people think of something like <a href="http:&#x2F;&#x2F;mweststrate.github.io&#x2F;mobservable&#x2F;" rel="nofollow">http:&#x2F;&#x2F;mweststrate.github.io&#x2F;mobservable&#x2F;</a> ?

It seems like the author is defining &quot;quality of paradigm&quot; to mean little more than the terseness of syntax. I agree that Redux is pretty rough aesthetically. It&#x27;s definitely verbose, and I agree that this is a problem. I just don&#x27;t agree that this is really a complaint about the <i>paradigm</i>.

I didn&#x27;t really get why he thinks Elm is better than React. Can someone shine a light here?<p>I never used Elm and a only dabbled with React a while ago but I remember having a very confusing feeling about React. When I read the introduction and basic ideas everything &quot;clicked&quot; and sounded obviously correct but when I went ahead to try to use it the library was much larger and complex than I would have expected. I suspect that the sizeable complexity might have to do with supporting stateful subcomponents that can be redrawn independently (as opposed to a system with a single tree that gets redrawn every time) or with their promise to support server-side HTML generation. Does anyone know if this is actually the case? How does Elm compare? Does it also allow stateful subcomponents?

I&#x27;ve been using Mithril lately. His criticisms of React don&#x27;t seem to apply to Mithril. Mithril seems to fit just fine in a Flux architecture. I haven&#x27;t looked at Redux specifically.

I won&#x27;t disagree. But from a business point of view, it makes a lot of sense to use React. It&#x27;s support from a huge organization like fb, and mass adoption by the community, make it a safe choice to use in the long term, from a business point of view. Not only will it continue to be supported by a well funded engineering organization, but the pool of developers with experience with it is large.<p>As for Redux, I&#x27;m more of a Alt.js kind of engineer. All that being said, Cycle and Elm are totally cool.

I just started working with Redux fairly recently, and I definitely felt that handling async effects in Redux wasn&#x27;t as elegant as most other parts of the Redux architecture. Glad to find out that Dan feels the same way, according to the tweets linked to in this article [1].<p>Has there been any efforts to make use of js-csp [2] to handle async operations in Redux, like how ClojureScript apps make use of core.async channels?<p>Cycle.js definitely looks promising, but I have a vague suspicion that its approach of handling effects strictly through the output of the main function, although elegant, might make interop with the rest of the JS ecosystem a lot more painful, since many JS libraries don&#x27;t have such clean separation of concerns. I believe JS interop is also one of the most commonly cited pain points for working with Elm as well, which uses a similar approach.<p>[1] <a href="https:&#x2F;&#x2F;twitter.com&#x2F;dan_abramov&#x2F;status&#x2F;689639582120415232" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;dan_abramov&#x2F;status&#x2F;689639582120415232</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;ubolonton&#x2F;js-csp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ubolonton&#x2F;js-csp</a>

The conclusion of this article is great because the author says &quot;we need to continue seeking improvements.&quot; This is true of anything. Nothing is ever perfect.<p>My problem was the way in which the author got to this conclusion. Addressing React as &quot;inferior&quot; made the article feel like an attack on React when I think the author was really just trying to point out there are better ways to do things.<p>Of course React can do things better. Like I said, nothing is ever perfect and we are always building on the mistakes and learnings of the past. However, there are good reasons why so many people use it and it is an awesome option compared to some of the things we have used and done in the past. Eventually something will come along and do things better, but thats just the way the world works.

When a man spends a lifetime building a skyscraper with toothpicks he will always believe that toothpick is better than the brick, such is the contradictory nature of man.<p>You will also meet people who believe the entire universe is made out of apples and oranges and that comparing the two is pointless. These people will never realize that there are things in the universe that are inherently superior to other things.<p>So which is the brick and which is the toothpick? React or cycle or elm? Or am I looking at apples and oranges? Ask the man who has built skyscrapers out of all three.<p>Will such a man please stand up?

The best way to respond to these articles is to create things on these frameworks in question and form an opinion. Not everyone wants to solve the same issues at all times, how can one single experience tell you something is not good for you? it can&#x27;t. Judge for yourself, use these tools before you decide from another person. In some cases (I&#x27;m not kidding) you&#x27;re better off just using lodash and a package bundler. I&#x27;d say stop thinking in Uni-directional flow for all problems.

&gt; In Cycle.js you can omit the props object. Since props are always an object and children are always an array, it’s obvious which parameter is what<p>Ack, I really do not like this. Detecting the meaning of each parameter based on its type is too much magic for me. If you&#x27;re using positional parameters, they should be positional parameters. Otherwise I&#x27;m always having to guess how much magic is actually supported, and what each function call actually means.

I was skeptical at first, but this is really cool:<p>&gt; In Cycle.js you can omit the props object. Since props are always an object and children are always an array, it’s obvious which parameter is what:<p><pre><code> ul([ li(&#x27;Foo&#x27;), li(&#x27;Bar&#x27;), ]) </code></pre> That&#x27;s a lot cleaner than JSX. Kudos.

I feel like I&#x27;ve been hopping from bandwagon to bandwagon. First Angular, then React (liked React more), and now I&#x27;m like, &quot;ehhhh, some of this React stuff is fairly tedious.&quot;<p>I feel like I&#x27;m still waiting for the Holy Grail of JS frameworks&#x2F;libraries.

&gt; 7 hours &gt; 5 hours<p>both of these seem like an extremely long time to do something fairly simple in the native language for minimal gains and often huge tradeoffs (performance, memory usage, lackluster apis, etc)

The distinction here seems to be whether to group all your async code into actions, or let FRP producers pepper your code?

Big shoutout to Cycle.js, it&#x27;s small, simple, and wonderful. Composing reactive streams is great.

The two biggest problems with React:<p>1. Updates are O(N), where N is the size of your virtual dom tree.<p>2. You have to manually keep track of dependencies within your code, in order to trigger updates.

I have limited React experience and none with Cycle, but I am not surprised to find that a framework that solves the problems a particular developer wanted solved works better than other frameworks for solving those problems. The real test is in scenarios that were not foreseen.<p>This is generic, of course, and the article gives no real view of the capabilities of cycle as its own thing, but I feel sufficiently experienced to be skeptical of claims of blanket inferiority.

I tried to use React.js but it felt like Java Swing all over again. While controlling state and triggering render when it changes seems like a novel idea quickly blows up in complexity.<p>I find it odd that after 5 years developing multiple products with npm, node.js, meteor.js, flask + uwsgi, angularjs &amp; react that now I&#x27;m back to just using Laravel + jQuery to build my single page application with REST api. It&#x27;s easier and cheaper to find skilled php developers and learning jQuery is not a problem.<p>It&#x27;s the 2006 formula but it works so fucking well and so much easier. Scaling is going to take work regardless even on AWS so now I prefer reduced technical debt and maturity of tested and true technologies.<p>I know this will get me crucified by mid 20 something hackathon hackers but this is just based on my own experience rather than blog articles. Something I learned very painfully through neophilism rampant in the industry.

In terms of paradigm, I still, to this day, find the Knockout.js MVVM paradigm best for most scenarios.<p>They don&#x27;t get much hype but to me it&#x27;s just a very mature and feature complete library with many &quot;plugin&quot; points to plug your own custom behaviour when you need to.<p>I did use React and I do find it unnecessarily confusing. In terms of performance gains, it doesn&#x27;t really do a whole lot (for me). You still have to put a lot of though into structuring your rendering pipeline for maximum performance, and at the end of the day whether you spit out the DOM using react&#x27;s &quot;Virtual DOM&quot; or some other custom templating engine doesn&#x27;t seem to really make much of a difference.<p>React gets negative points for creating a parallel DOM structure and taking complete control of the portion of the DOM tree where it renders its components.

I heard over 30 and you are out.