
Why React/Redux is inferior as a paradigm - scottcorgan
http://staltz.com/why-react-redux-is-an-inferior-paradigm.html
======
mambodog
To be honest, this whole thing just seems like a vague rant. It's full of
hand-wavy statements like 'Once you learn Elm or Cycle, getting things done
will be more productive' with only vague anecdotes to back them up, with no
specific examples of worked problems.

The section on JSX & 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's taste. However the author then goes on
to making a comparison between React's createElement/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.

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's the article the author should have written.

[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.

~~~
vcarl
Agreed, opting not to use JSX and then complaining about a lack of ergonomics
seems pretty contrived. Yeah, the raw function calls aren't particularly
friendly, that's why JSX exists. If more people opted not to use JSX, I'm sure
there would be better options for friendly createElement/createFactory.

He also doesn't mention the learning curve, and I'd argue that function calls
for DOM is less beginner friendly. It's pretty easy to mentally map a render
function to its output because they're so syntactically similar.

~~~
Ronsenshi
Not sure how much relevant it is, but author's stance on JSX reminds me of a
meme known as "Baton Roue" which depicts person throwing a stick into the
wheel of the bicycle he's riding. In other words - sure you don't have to use
JSX, but if you really decided to work with React you are highly advised to go
with JSX because that's what makes work with it much easier: you get familiar
syntax which is easily parseable when somebody else is reading a code.
However, if you decided against JSX then you're doing yourself a disservice,
because sticking to raw JS does not improve development process at all,
probably even opposite.

------
Lazare
Newsflash: Guy who created Cycle.js because he didn't like React thinks
Cycle.js is better than React. (He also thinks Elm is better than Redux, but I
think he's significantly overstating the differences between Elm and Redux's
patterns, and significantly understating some of the drawback'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.)

He's probably right about Cycle though, for some devs, on some projects. Then
again, I'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't it.

(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's just that people _don 't_, because most people don't find
hyperscript as awesome as he does. Which is sort of the article in a nutshell;
"X is better than Y because I like X!")

~~~
knite
Can you share why and how these Cycle.js users were burned by the framework?
I've been considering it for a project and would love to hear about how it's
gone wrong for others.

~~~
Lazare
Unfortunately, I can't; it was some idle chatter after a meetup, and I may
have had a couple of drinks at the time. :)

From memory, it was based around the way the redux patterns is very top down
with a single state atom, smart reducers, and dumb components, but the cycle
pattern is very bottom up with smart components and no centralization. So as
your app gets complicated with cycle, you can start to lose track of all the
different streams and start to struggle with figuring out what your app is
doing in total.

Mind you, they may have just been doing cycle wrong, and you have to take
people complaining about their tools with a grain of salt. But the impression
I got is that cycle is not a magic bullet that makes large, complicated apps
with difficult state management problems easy to code, any more than redux is.
Cycle is great when you start looking at redux and go "oh shit, I do NOT want
to start coding these reducers, can I just break it down into tiny parts and
solve each one on its own", but redux is great when you start looking at cycle
and go "oh man, I do NOT want to try and figure out how all these bits work
together, can I just put all this crazy logic in one place?"

(Disclaimer: Have never used cycle; just talked to some people who have.)

------
fuzionmonkey
Cycle.js has the most elegant and powerful component composition mechanism of
any JS framework I've ever used. With React you have to be extremely careful
in how you design components to make them re-useable and flexible.

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'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.

It'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's very clear Cycle.js was designed with composability in mind from
the start.

~~~
dustingetz
I really would like to see an article about this, can you point me in the
right direction. Natural component composition(nesting) where "component"
includes markup, state and events, and how cyclejs makes this better. This is
the article Andre should have written btw, i think vanilla react doesn't
handle this all that well and redux makes the composition story worse
(composition is a non-goal of redux though) - but it is very much still a
research problem

~~~
leeoniya
Take a look at domvm [1], disclaimer: mine. It was written expressly to allow
for imperative AND declarative sub-view composition using a concise, js
syntax. I used Mithril for a while before needing granular redraw and
concluding that MVC wasn't the way to go.

~8k min. No build tools, no dependencies. Extremely fast [2], composable,
isomporphic. JSONML [3] superset template syntax. it's plain js all the way
down.

[1] [https://github.com/leeoniya/domvm](https://github.com/leeoniya/domvm)

[2]
[http://leeoniya.github.io/domvm/test/bench/dbmonster/](http://leeoniya.github.io/domvm/test/bench/dbmonster/)

[3] [http://www.jsonml.org/](http://www.jsonml.org/)

~~~
dustingetz
I dont think this is the type of composition I am talking about. This composes
pure views, like react, but it doesn't compose their state, same as react.

~~~
leeoniya
continued in
[https://github.com/leeoniya/domvm/issues/8](https://github.com/leeoniya/domvm/issues/8)

------
n0us
Everyone has their preferences but personally I have never used a framework
that got everything perfect. I'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.

~~~
pekk
As someone who is mostly a spectator lagging months behind the JS framework du
jour, it would be helpful if these discussions were a little less personal and
a little more objective, even if cooperation isn't in the cards. I really
don't have the time or patience to sort through all the WWE-style back and
forth, and it is really painful to make a new project using every new thing
just to see if it is any good.

~~~
n0us
For me the solution has been to pick a relatively popular library, work around
the quirks, then just DONT UPGRADE the package. EVER. (Unless there is some
real benefit to the end user or a security issue or something)

As a solo developer trying to bootstrap a startup I started out 8 months ago
with React, I have had a reasonably good experience with React itself. For a
pre 1.0 project it's surprisingly stable and once you figure out what you're
doing I've been able to move relatively quickly.

The big holdup has been the supporting libraries. Some have been an absolute
mess but the solution to that is that once I got it working, just don't touch
it and don't buy into the promises that it's always going to be the next
version that solves the issues. I didn't opt for Redux and went with Fluxxor
instead which has worked reasonably well but I kept getting errors and ended
up forking it to fix the problem. I'm not going to go back and use Redux for
everything because someone told me it's better.

I am now on my 3rd build tool over this timeline. I am now on Webpack because
people kept promising that the next one would be better. I struggled to
finally get React-Hotloader to work and occasionally it works but most of the
time I just get Invariant Violation errors and have to do a full reload. I had
to jump through hoops to get this to work and enable CORS etc for virtually no
benefit. It will almost certainly be my last build tool for a while.

The pattern with JS from my viewpoint has been to overhaul entire libraries
because it's not _quite_ right. It seems that what these developers don't
realize is that when you solve one problem you often introduce another. Once
you have a working solution there isn't really much incentive to change
things. This guy laments that there is not a good way to do pure JS instead of
JSX but you know what? JSX is fine. I already need a build tool to use ES6,
and as long as you are consistent you shouldn't run into too many issues using
the pure JS solution that comes with React if that's what you really want to
do. JSX might be ugly but I would rather just deal with the ugliness and
settle for good enough then keep creating extra work for myself in search of
perfect.

My goal is to build an app. I don't have the time or inclination to try out
libraries like cycle or elm every time someone brags about how perfect they
are just because they might provide me with a little benefit in terms of ease
of development. I am perfectly fine with sitting back and reaping the benefit
of other peoples' WWE-style back and forth even if I have to wait a year or
more for things to stabilize.

~~~
EvanPlaice
I hate to break it to you but WebPack is also riding the peak of a hype cycle
right now.

It doesn't natively support the future ES6-module standard.

Once browsers start providing native module loading support, devs will likely
migrate en masse to JSPM. JSPM is the (previously missing) package manager for
front-end libraries. It supports transpiling (babel, traceur, typescript) out
of the box and also handles bundling.

~~~
Akkuma
WebPack 2.0 does support ES6 module import statements. In fact, it does tree
shaking now too, but only if you use import {x} from foo.

~~~
EvanPlaice
Oh, cool. I didn't realize webpack 2 was released with ES6 module support.

Import {x} from 'foo'

Looks like it's going to be the spec for ES6 modules anyway so it's probably a
good thing that you have to it for tree shaking.

------
joshuahornby
Having worked on a small/medium React application after stepping back once the
work was complete it began to dawn on me that React wasn'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
([https://twitter.com/dan_abramov](https://twitter.com/dan_abramov),
[https://twitter.com/schrockn](https://twitter.com/schrockn),
[https://twitter.com/soprano](https://twitter.com/soprano) to name a few)

The idea of Elm ([http://elm-lang.org/](http://elm-lang.org/)) excites me
greatly but then again what'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?

~~~
ssmoot
If you're doing Scala/Play development, then I kinda feel like you should just
use Scala.js. So you get a familiar language, providing the same sort of
benefits as Elm, that almost definitely will be around for years to come.
There are concerns with the size of the generated code, but on balance it
doesn't appear significantly worse than most of the JS frameworks available.

I realize that's a suggestion that will only apply to a relatively small niche
in comparison to many of the frameworks discussed, but since I'm a part of
that niche... :)

But yeah, you probably should be using something better than ES5. So is it
Typescript? Elm? Clojurescript? etc? I think Elm is out. And while the others
are probably good, long-term solutions, why learn a new language if you can
get more or less the same feature set with something that already integrates
with your build-tool/stack? Seems like a no-brainer to me.

And then once you have that, do you really want a client-side "framework"? For
some problems maybe... but I feel like if you solve the basic problem of
language, that question becomes a lot less relevant.

Just seemed like an appropriate place to vent my own thoughts on the subject
lately. I get there are plenty of people that don't care for or aren't excited
about Scala for one reason or another, so I'm not attempting to persuade
anyone it's the right choice for them.

~~~
joshuahornby
Bear in mind I am asking this question as someone who has no experience in
Scala/Play but is looking to learn some new languages/frameworks:

How do the Play framework and Scala.js work with each other? Can I easily
write an application is Scala and then sprinkle Scala.js around to perform
AJAX data fetching for example?

~~~
ssmoot
For someone who knows Scala the tutorial at [http://www.scala-
js.org/tutorial/basic/](http://www.scala-js.org/tutorial/basic/) seems pretty
thorough.

But the short answer is yes.

There's also this: [https://github.com/vmunier/play-with-scalajs-
example](https://github.com/vmunier/play-with-scalajs-example)

And then if you want something interactive but with low commitment, you can
give the examples in Typesafe Activator a spin:

    
    
      $ brew install typesafe-activator
      $ activator ui
    

That'll open a browser window. Form there you can open tutorials, step through
them while a code panel gets highlighted as you go, edit code in-browser,
execute tests and run. All from a single app running in your browser with a 30
second install. It's gotta be the lowest friction intro/development
environment ever conceived. Highly recommended if you've never seen it.

------
watty
I'm currently trying to train a new developer and slowly introduce him to the
world of React/Redux and only now am I realizing how incredibly complicated it
is.

I enjoyed learning them and am efficient using them but now I'm not so certain
that it'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.

~~~
chrisco255
Well, that's sort of the difference between composing libraries to build
applications and using a framework like Angular. Angular abstracts away a lot
of things. This is good and bad. It's easier to get into Angular and get
started sooner. But ask an Angular dev to explain the digest cycle to you, or
transclusion or when and why to do one-way or two-way binding, and the
relative merits of calling $parent or using controllerAs syntax. It's a really
confusing mess. And folks use it without understanding how it works.

With react, I can explain, quite simply, that it's simply a function: (state,
props) => HTML . That is elegant as fuck. There no dirty checking, no two way
binding or unintended side effects by cross-referenced observables.

React-Router is only necessary if you want to build a SPA. Then you learn how
it works, or you use some other router (like Redux-Router). It's great. You
actually understand how your code works.

It's a steeper learning curve up front, but you learn and you become a better
developer as a result.

~~~
EvanPlaice
I could explain how Angular2 works in great detail. It mimics the hell out of
OOP.

The component tree is a directed acyclic graph of single-inheritance
relationships. Services are singletons that can be injected into any component
to share state. Dirty checking follows the tree (ie the DAG) of inputs/outputs
specified in the component metadata so there's at most O(log n) comparisons
per update. To make dirty checking efficient favor immutability because it's
quicker to superficially compare references than it is to deep check an entire
data structure.

Anything that's inherently asynchronous is handled via Rxjs observables using
either a one-to-one or one-to-many publisher/subscriber model.

As for Angularjs. Who the hell knows? Dirty checking, crawls the graph of
relationships until the dirty checker gets tired. Services are kind of like
singletons, I think. Factories try to mimic the borg/prototype pattern
(because, reasons...) to provide singletons that share a reference to a common
closure. Who the hell knows what providers do, maybe provide an instance that
acts like a static helper class? Directives are magic, really complicated and
painful to use magic that preprocess the HTML, who the hell knows when.

------
hugozap
We can't maintain something simple for a long time. Maybe that's human nature
(or developers nature ), but the success of a framework is the start of its
demise. Excited contributors will try to "improve" it and that always ends up
adding complexity to what was a simple and elegant solution.

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.

~~~
trowawee
I think the problem originates in people using the system to solve their
actual problems. Most problems aren't simple, and therefore demand non-simple
answers. (Tangent: this is also why todo list examples for frameworks are so
damn silly.)

------
matthewtoast
Maybe part of the "JavaScript fatigue" is that, as each shiny new toy rolls
in, the ensuing commentary immediately elevates it to The One Solution We'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's Why....

The reality is that many species can coexist in the same habitat. You don't
have to pick just one. Cats don't have pincers, but does that have to mean
lobsters are superior? Nope.

~~~
hugozap
It's funny how we identify with our tools and some consider them even more
important than the actual products being built. Maybe it's a manifestation of
the "The grass is always greener on the other side of the fence" that makes
teams jump from a solid and time tested toolchain to a new "cool" framework.
The problem with this frequent loop is that a lot of time is wasted learning
conventions/syntax/tooling and the lifetime of that knowledge is small.

------
keithwhor
A little bit of a meta-comment, but I find this article very hard to read.
There's no clear delineation between different arguments / sections of the
article, meaning I can'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's very distracting, and the
presentation (especially considering the technically-heavy content) hurts the
message.

~~~
luisrudge
Keep in mind that english is not the author's native language.

~~~
eyko
I'm not a native english speaker, but I felt the same. You would expect misuse
of expressions or some sentences being strangely constructed / difficult to
understand, but overall the structure of the article should be more or less
clear.

------
spion
I'd like for the observable community to finally settle on a minimal common
interface (like Promises/A+ and later ES6 promises did) for observables. Maybe
[https://github.com/zenparsing/es-
observable](https://github.com/zenparsing/es-observable)

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
([https://github.com/Reactive-
Extensions/RxJS/blob/master/doc/...](https://github.com/Reactive-
Extensions/RxJS/blob/master/doc/gettingstarted/categories.md))

~~~
fuzionmonkey
[https://github.com/motorcyclejs](https://github.com/motorcyclejs)

~~~
spion
Awesome, most.js was exactly what I was hoping for! Still, it would be best if
all those operators were a separate library dependant on a single common
interface (using ES7 bind operator for nice chainability maybe?)

~~~
robwormald
That's how RxJS 5 is set up, fwiw.

~~~
spion
Oh, cool. I think I'm finally sold on RxJS then. My only remaining beef with
cycle.js is that components behave so differently from DOM nodes (which are
not treated the same way as components), but I guess I can still give it a
try.

------
rco8786
> Components that expect “onlyChild”

> Some React components have an invariant: “Invariant Violation: onlyChild
> must be passed a children with exactly one child”. Which means this is an
> error:

I'm surprise the author called this out as a negative of React while saying
the compile time type safety is a positive of Elm.

If I have something that expects one child, I expect one child, not an array
that has 1 element.

~~~
Scriptor
Agreed, the benefits of type safety are often thrown around but this is sort
of what type safety looks like. Yes, as the author says it makes things
"annoying to develop". This is because the developer now has to read the docs
and be aware of this invariant for the particular component they're using.
They'll go, "Damn, guess I can't use a list here," and fix their code.

However, let's say later down the line a new engineer comes in and is tasked
with a bug fix. If they're using Cycle.js and see an array, they might think,
"Oh, I can easily solve this by adding another element to this one-element
array." Without any invariants they'll run into subtler bugs and errors trying
to figure out what went wrong.

But with the invariant, if they tried to jam an array there they would
immediately get an error and know what's wrong.

This isn't something that will crop up in a simple one-day project like the
author was creating with his coworker. It's instead a great example of how a
little annoyance can make future maintainability way easier.

------
moogleii
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.

~~~
city41
How do you find Redux complex? I found I got the gist of Redux in a few
minutes, and was very productive with it a couple hours. I find it much
simpler than flux. What do you not like about it?

~~~
icebraining
Glancing at the documentation, it seems to be essentially an implementation of
the Memento Pattern, as described in the Gang of Four's book. I have to agree,
it's fairly straightforward.

------
betenoire
I've enjoyed React immensely, so I expected to dislike this article, but there
are a lot of good points in there.

This part confused me: > I can confirm React/Redux is an inferior paradigm...

But all the examples don't show a "different paradigm", let alone a superior
one. To me, they show the same paradigm, done better? The conclusion seems to
support that interpretation as well.

~~~
Lazare
The bulk of his argument seemed to focus on how he really prefers hyperscript
to JSX, which is fair enough I guess...but no, really not a "different
paradigm".

Especially since he talks a lot about how much he loves Elm, and Redux went
out of their way to copy Elm. The Elm/Redux distinction is basically syntax.

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

~~~
luisrudge
vanilla flux has WAAAAAAAAAAAAAAAAAY more boilerplate than redux

~~~
vdnkh
I'd gladly trade more boilerplate for stability and confidence of non-breaking
updates. You can also write higher-order components to DRY things up.

~~~
jxm262
It's not the boilerplate that get's me. It's just easier to reason about the
state using Redux (imho). The idea of 1 single global state which mutates and
pushes down (instead of managing observables all over), makes it easier to see
when/where something changes. The idea isn't new (check react-cursor for
example).

That said, there's nothing wrong with vanilla flux. Just that I find redux
much easier to understand and follow.

~~~
luisrudge
Also that!

------
Keats
And what do people think of something like
[http://mweststrate.github.io/mobservable/](http://mweststrate.github.io/mobservable/)
?

------
baddox
It seems like the author is defining "quality of paradigm" to mean little more
than the terseness of syntax. I agree that Redux is pretty rough
aesthetically. It's definitely verbose, and I agree that this is a problem. I
just don't agree that this is really a complaint about the _paradigm_.

------
ufo
I didn't really get why he thinks Elm is better than React. Can someone shine
a light here?

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 "clicked" 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?

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

------
bahador
I won't disagree. But from a business point of view, it makes a lot of sense
to use React. It'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.

As for Redux, I'm more of a Alt.js kind of engineer. All that being said,
Cycle and Elm are totally cool.

~~~
addicted
Being backed by a huge organization did not stop Angular from basically
throwing away their stack with 2.0.

Although, to be fair, unlike Google with Angular, FB (more often Instagram) is
actually dogfooding React and using it on their own stack. And with react-
native they've invested a lot more in React tech than Google has in Angular.

~~~
ry_ry
Isn't react the actual result of FB's development, whilst angular (1 granted)
was at least partially built prior to bring picked up by Google?

------
lewisl9029
I just started working with Redux fairly recently, and I definitely felt that
handling async effects in Redux wasn'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].

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?

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'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.

[1]
[https://twitter.com/dan_abramov/status/689639582120415232](https://twitter.com/dan_abramov/status/689639582120415232)

[2] [https://github.com/ubolonton/js-csp](https://github.com/ubolonton/js-csp)

------
zB0hs
The conclusion of this article is great because the author says "we need to
continue seeking improvements." This is true of anything. Nothing is ever
perfect.

My problem was the way in which the author got to this conclusion. Addressing
React as "inferior" 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.

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.

------
crimsonalucard
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.

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.

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.

Will such a man please stand up?

------
pacomerh
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't. Judge for yourself, use these tools before you
decide from another person. In some cases (I'm not kidding) you're better off
just using lodash and a package bundler. I'd say stop thinking in Uni-
directional flow for all problems.

------
haberman
> 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

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're using positional parameters,
they should be positional parameters. Otherwise I'm always having to guess how
much magic is actually supported, and what each function call actually means.

------
temuze
I was skeptical at first, but this is really cool:

> 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:
    
    
        ul([
            li('Foo'),
            li('Bar'),
        ])
    

That's a lot cleaner than JSX. Kudos.

~~~
bphogan
Yea. That's kinda like what Elm does for its views.

    
    
        ul [] [
          li [] text "Foo"],
          li [] text "Bar"]
        ]
    

Took a while to "get" it, but now I really like it.

(`ul` and `li` are functions that take two lists - the first is a list of
attributes like class or ID or whatnot, and the second is the inner content...
text or other elements.)

~~~
guidopallemans
you forgot some braces:

    
    
        ul [] [
          li [] [text "Foo"],
          li [] [text "Bar"]
        ]

~~~
bphogan
Hah! I did. Thanks!

------
kendallpark
I feel like I've been hopping from bandwagon to bandwagon. First Angular, then
React (liked React more), and now I'm like, "ehhhh, some of this React stuff
is fairly tedious."

I feel like I'm still waiting for the Holy Grail of JS frameworks/libraries.

~~~
jaequery
Well, you aren't the only one. Welcome to front-end hell. :)

------
nijiko
> 7 hours > 5 hours

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)

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

------
bribri
Big shoutout to Cycle.js, it's small, simple, and wonderful. Composing
reactive streams is great.

------
amelius
The two biggest problems with React:

1\. Updates are O(N), where N is the size of your virtual dom tree.

2\. You have to manually keep track of dependencies within your code, in order
to trigger updates.

~~~
timdorr
React doesn't have to be O(N). You can short circuit rendering with
shouldComponentUpdate checks.

~~~
grayrest
shouldComponentUpdate only prunes the size of the vdom tree, updates are still
O(n_virtual_dom). I've always thought this was an advantage compared to
alternative approaches I know about since pruning the size of the vdom tends
to be fairly easy compared to, say, optimizing a KVO chain.

------
oldmanjay
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.

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.

------
jorgecurio
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.

I find it odd that after 5 years developing multiple products with npm,
node.js, meteor.js, flask + uwsgi, angularjs & react that now I'm back to just
using Laravel + jQuery to build my single page application with REST api. It's
easier and cheaper to find skilled php developers and learning jQuery is not a
problem.

It'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.

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.

~~~
codesculptor
You are probably doing it wrong.

------
hasenj
In terms of paradigm, I still, to this day, find the Knockout.js MVVM paradigm
best for most scenarios.

They don't get much hype but to me it's just a very mature and feature
complete library with many "plugin" points to plug your own custom behaviour
when you need to.

I did use React and I do find it unnecessarily confusing. In terms of
performance gains, it doesn'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's "Virtual DOM" or some other custom templating engine doesn't seem to
really make much of a difference.

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.

------
puppetmaster3
I heard over 30 and you are out.

