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.

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 academic when all they really care about is getting stuff shipped the next day. Being able (forced?) to tightly couple a controller and a view in Angular is one reason a lot of people like it.

I was giving a workshop on FP recently, and you'd be surprised at the number of people who still don't grok `filter`. FRP is still way over a lot of people's heads. Hopefully the industry will warm up more to the concept as React, Mithril, Meteor, etc get more popular.

@staltz WRT Cycle.js itself:

I took a look at the TodoMVC example and was surprised to see intents reading data from DOM element data attributes (e.g. https://github.com/staltz/todomvc-cycle/blob/master/js/inten... ). How does one go about doing non-string parameterized intents? For example, I often need to reference an entity from an event handler and searching for it in a collection by ID seems wasteful. In Mithril, for example, handlers can receive parameters as inputs either via closures from the view or via partial application (i.e. Function::bind). This is especially useful for event handlers that deal with relationships between two or more different entities. Is there a similar mechanism in Cycle.js?

I fully agree: of course React gets a lot wrong, being a pioneer and all. The way JS often goes, I bet one of the many alternatives that pop up actually will turn out like something. But attacking it like that isn't going to get you many friends.

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.

However, if this is the case, then the criticism here against React shouldn't be that they're not reactive, but that they've used "reactive" wrong in their documentation.

Like other commentors, I also don't like the message in the slides and do not think that criticizing a competitor is a good form of marketing. But, I do think we should remember that it's hard to get the full context from slides and to not judge too quickly.

It reminds me a lot of Gabriel's divide between the New Jersey approach versus the MIT approach---React is far more viral in its current form, but better technology certain lives further down the path.

I went to the Boston React meetup a few nights ago to hear Pete Hunt speak about React. He was a wonderful speaker and described nicely how React learned some of the same lessons that REST did making it superior to basic message passing and bloated/leaky distributed object mechanisms (blech). He also projected a very pragmatic POV from the React dev team---they want things to be right, but they also want things to be functional in the perspective of the way most applications are built today.

I was eager and jumped on some of the problems he suggested the React time was facing trying to integrate something like animation into React. At this point we jump from a sequence of instantaneous updates to a more game-like continuous redraw effort. Pete mentioned that the current effort here was to try to use technology like RxJS observers to get more reactivity and this seems aligned with the OP here.

Personally, I think animation lives most nicely in the domain of continuous time, "true" FRP which is mostly ignored by the current wave of Javascript FRP libraries. Perhaps for good reason since most modern implementations ideas of (again, "true") FRP are challenging to implement efficiently and the semantic model is probably far too large (Zeno processes, difficulty with infinitesimal delay).

But the advantage of FRP is that you can specify things like animation independently of the icky details like event passing and sampling rate and let those be determined at a later time when your FRP eDSL gets compiled into a more refined event-passing network. In other words, FRP languages hide a vast number of irrelevant and muddying details in a way that has a consistent denotation and can (perhaps!) be compiled efficiently into a push/pull message passing network.

Since you do, I cannot take anything you say about web development seriously.

[1] http://docs.meteor.com/#/full/reactivity

This blog post from the same author gives a bit more detail than the presentation slides: http://futurice.com/blog/reactive-mvc-and-the-virtual-dom

Looking forward to seeing the presentation video

If it sucked nobody would be using it.

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.

http://computationallyendowed.com/blog/2014/07/20/reactive-m...

Basically: view m0 = r0 view (m1 = handler e0 m0) = r1 view (m2 = handler e1 m1) = r2

Or just down vote and learn nothing.

From yesterday, it's now possible to have stateful custom elements, as if they were Web Components: https://github.com/staltz/cycle/blob/fbae9c6610043ef6e46941a... This brings Cycle a bit closer to React, in that a "component" can handle its own events. The overall approach is still different than React, because in React you are encouraged to use components for anything, while custom elements exist in Cycle only when a pure component (i.e. a function returning a virtual DOM element, in React terms, props-only component) is not enough. Hence TodoMVC could be rewritten to use <todo> custom elements.

Using DOM attributes to register IDs is just one technique. Things are evolving fast, and I haven't myself tried to publish/share Cycle just yet, because it's not ready.

PS: I have a lot of respect for Mithril. Unfortunately not reactive as I would appreciate, but Mithril is very fast and very simple to understand.

We had this discussion a while back:

http://lambda-the-ultimate.org/node/2913