[kuni-toko-tachi]

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 frontend development it would be wise to pay attention.

[robteix]

> People are really missing the point here. Follow staltz on twitter, he really knows his stuff.

Whether he's brilliant on twitter or not is irrelevant. People are judging the presentation. Even if he's the most brilliant mind in the 21st century, that doesn't shield his work from scrutiny.

[marrs]

Not bashing React? Are we reading different presentations?

[aikah]

> He's not bashing React

I quote him

> React sucks

How do you call it? a constructive criticism ?

[kuni-toko-tachi]

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 reasoned about much better than other approaches.

[crossre]

You mean jQuery I suppose?

[kuni-toko-tachi]

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.

[crossre]

Yes exactly, just keep the state in css classes and html forms and tool yourself for reuse.

[btown]

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.