Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't React (Presentation - Use arrows to navigate)

staltz.com

Post reply on HN
Print view View original

81–90 of 105 posts

Re: Don't React (Presentation - Use arrows to navigate)

#81

Post by discreteevent »

lhorie wrote: post #75

Disclaimer: I wrote Mithril (one of the vdom frameworks mentioned in the presentation) I like the idea of reactive programming, but it tends to add a lot of indirection. This is theoretically desirable, but not necessarily pragmatic in reality. A lot of frontend code in the wild is of the throw-away-in-a-few-years nature and it's hard to get mindshare among developers if they're required to learn stuff that feels aca…

If they don't grok filter then they cannot even interact with a relational database at the simplest level (a select, where). I think there is a certain level below which you are not obliged to dumb it down further.

Re: Don't React (Presentation - Use arrows to navigate)

#82

Post by zghst »

> Testing worse, through DOM

If you're writing proper tests for React, you don't test directly through the DOM. Using Jest you can mock the DOM to test parts of your component. In my view, a component should not contain everything, only the most essential parts to get a working example of how it functions. Reusable/general functionality is pulled in from mixins or other js modules, which should be testable, without the structure of React, on its own.

> Cannot have post processing steps

This is incorrect, you can create a post processing step in React with a parent component. I used this for a pointer events polyfill in React where it replaces `onPointerEvent` with the appropriate mouse or touch event on a child component.

> Cannot delay rendering after state/props change

You can delay a render by returning false from shouldComponentUpdate, and when you get to the point where you want to render you can use this.forceUpdate().

That being said, React is somewhat misleading as far as Reactive programming goes.

Re: Don't React (Presentation - Use arrows to navigate)

#83

Post by platz »

kuni-toko-tachi wrote: post #25
Kiro wrote: post #23

Earlier quoted context omitted.

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.

Re: Don't React (Presentation - Use arrows to navigate)

#84

Post by jeremiep »

hackerboos wrote: post #48
coding4all wrote: post #43

Clearly the author has never heard of ClojureScript's Om.

How does Om not suffer from the same problems? It's just an Clojurescript interface to React.

Om is not an interface to React but rather React is the backend to Om.

I wouldn't use React out of the box, for pretty much the very same reasons outlined in the slides.

Re: Don't React (Presentation - Use arrows to navigate)

#85

Post by btown »

kuni-toko-tachi wrote: post #20

People are really missing the point here. Follow staltz on twitter, he really knows his stuff. React is very good, however it missing a few key things that would make it awesome and more consistent - namely compositional event processing. Where React falls short from perfect is by using imperative code for its lifecycle functions. He's not bashing React, he's educating you about an even better way. If you care about…

The interesting thing about React is that it's not at all incompatible with compositional event processing and true FRP. All it requires is that there be some concept of a "store" whose changes can be subscribed to, and the view and its children update automatically. That "store" can be a huge imperatively-driven series of Backbone.Collections, or it can simply be the end of a chain of compositional events using whatever structure or programming model you want. In many ways, it's a way for an application to decouple its view logic from its choice of event processing model. So you can start with a very simple view structure, and then with minimal refactoring you can swap out your event processing model for FRP as you need it. And it doesn't require your programmers to start thinking about type systems and immutability at the very beginning.

Do I have some gripes with React's API? Sure. But it's a good start.

Re: Don't React (Presentation - Use arrows to navigate)

#86

Post by jeremiep »

nkohari wrote: post #78
coldtea wrote: post #36

Earlier quoted context omitted.

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

Re: Don't React (Presentation - Use arrows to navigate)

#87

Post by crossre »

kuni-toko-tachi wrote: post #29
aikah wrote: post #22

Earlier quoted context omitted.

> He's not bashing React I quote him > React sucks How do you call it? a constructive criticism ?

If you look at the source code of React vs Mercury you might agree with him. Sucks is a strong word, however. He's passionate about this stuff because there is a very simple mathematics to frontend development (both declarative UI and immutable state as a function of mutational events) that has been hiding in academic papers and haskell minds that is now coming to the forefront. There is a better way, and it can reas…

You mean jQuery I suppose?

Re: Don't React (Presentation - Use arrows to navigate)

#88

Post by joelhooks »

staltz wrote: post #59

Presentation author here. I should have taken this down before it popped up on HN or elsewhere. The video of this presentation is worth watching, because it's tongue-in-cheek through-out. But the slides are not worth reading, otherwise people take it seriously like it's happening here now. Cycle isn't the solution to everything, it's just one guy's ongoing experiment.

The slides read great, and the concepts are important. It's something I'm personally intrigued by[1]. Very interested in Cycle and your experiments. Thanks!

[1] https://github.com/joelhooks/react-rxjs-angular-di-todomvc

Re: Don't React (Presentation - Use arrows to navigate)

#89

Post by kuni-toko-tachi »

crossre wrote: post #87
kuni-toko-tachi wrote: post #29

Earlier quoted context omitted.

If you look at the source code of React vs Mercury you might agree with him. Sucks is a strong word, however. He's passionate about this stuff because there is a very simple mathematics to frontend development (both declarative UI and immutable state as a function of mutational events) that has been hiding in academic papers and haskell minds that is now coming to the forefront. There is a better way, and it can reas…

You mean jQuery I suppose?

Not even the same things. I love React, use it everyday, however from a denotional semantic standpoint it is impure.

view m0 = r0

view (m1 = handler e0 m0) = r1

view (m2 = handler e1 m1) = r2

This is the essence of MVC. Mathematically pure and beautiful.

React and Flux are so close to this conceptually, but fall far short of it in actuality.

View is a function of state. State is an argument to view, and should not be mated to view in any other way except as a function call argument to the view - point free preferably.

If you look at the source code of React, there is an important object called Transaction. Transaction is basically AOP. AOP is not needed in JavaScript! Transaction reinvents functional composition. That is why things like Mercury, Mithrill, and Cycle are better,smaller, easier to read and reason about.

I love React, but it is a gateway to an even brighter future. Rejoice that the days of blind monkeys (myself included) writing UI code is coming to an end.

Post reply on HN