Hacker News new | ask | show | jobs
by danr4 4186 days ago
Okay, so React is not fully reactive. But to say people shouldn't use it because it's not reactive? because it abstracts virtual-dom? because it should be more reactive-friendly?!

Seems like the author was offended they said they are reactive, and made a non-informative presentation, that comes off as a rant because of the rising popularity.

Edit: looking at his Cycle framework's "Why?" on github, besides the part of 'Rendering separated from View' (arguably, you could say that React's render returns React elements which are virtual-DOM elements equiv), you can use the same approach with React.

My current project's component almost never update themselves, except minor UI changes, which is understandable. apart from that, all the data flow comes from above, and my components change according to it. oh and it's immutable (immutable-js another great fb lib).

That's the thing about React, there's quite a diversity in approaches for handling data, events, user actions, etc.

2 comments

He makes a weak case by focusing on the terminology. Quibble if you ask me.
Its not hairsplitting, maybe you read the FRP papers by Conal Eliot.
"Reactive" architecture and "Functional Reactive Programming (FRP)" are totally different things.
Actually you are wrong. Follow him and others on twitter and you will see that they are some of the most forward thinking people on these types of frontend technologies.

om and elm.are the future, which is functional and immutable. React is the gateway to those technologies, which have a long and strong academic foundation.

The days of hacking together things on the frontend are over, more sound approaches are needed, and those developers who embrace them will have their pick of jobs and a fistful of cash.

I've been following the "virtual-dom movement" since I started using React, which is a few months by now, including Mercury, Mithril and it's not the first time I run into Cycle. I agree they are taking these ideas further and actually am excited about the progress they are making, but the approach of "Don't Use This" and "Actually you are wrong", and "Those days are over" does not serve their cause.
Om is built on top of React. I'm not sure how you reconcile "React sucks" with "Om is the future" given that.
Om will also always have limited reach because it uses Clojurescript. I know that some people love it but I personally don't, and if nothing else it is an extra barrier for entry that some just won't get past.
>I'm not sure how you reconcile "React sucks" with "Om is the future" given that.

Maybe it fixes all the sucky parts?

Not really. It's basically just a means of using ClojureScript with React. That comes with some great stuff (immutability, for one), but AFAIK it doesn't change anything too dramatically.
Have you used Om?

It completely changes the way you think about modelling applications and their events. It's closer to Flux on steroids rather than a thin wrapper on top of React.

When do the academic implementations become successful? Rarely. The practical ones do, that use the important ideas and make them palatable. Usually the academic versions require one giant step off what people ever want to do. In the presentation, code goes off the direct path with intermediary objects. React's component approach is straightforward. The presentation fails to make a straightforward case of why its concepts are important. It just sounds petulant.