[Retozi]

From my experience, it is not about the FRP kool-aid. It's about the robustness of the concepts of React (DOM diff-ing, favor immutability, declarative views etc.)

Adopting something like elm might have its advantages, but also comes with practical disadvantages that, depending on your team and your project might be simply too big make the jump.

React got a lot of things right in my opinion. So much that to go from apple to fruit salad, you need roughly 200-300 additional LOCs, and you have a very robust Frontend system that, once you wrapped your head around React, has a very low knowledge barrier.

However, the good traits of React are not attributable to one concept like "FRP" but are simply "good concepts" that seem to influence other Frameworks to do "the same, a little different".

The adoption, the somewhat small API, the support from a large company, the possibility to integrate it easily in existing codebases that use other frameworks and react native has a much stronger pull than FRP in my opinion.

[tracker1]

I think a lot of attention is given tot he DOM diffing... I don't think it really means that much in practice as far as understanding the flux-like workflows and how applications come together.

To me, the unidirectional data flow, optionally immutable data structures and even tooling around redux (and similar) are what are nice. You have predictable, testable output without excessive complexity.

The need to understand a certain level of complexity in React+Redux in getting started is indeed a bit higher. But as features are added, that complexity doesn't grow nearly as much as with Angular.

I find the simpler node-like requires/es6-imports are easier to reason with than dealing with angular's weird DI system (though better in v2). Testing injection is supported via tooling (proxyquire and the like), and you can do full unit testing of your UI without firing up a browser.

I agree that full on FRP isn't needed... but will say that having data flowing in one direction, and events in the other can simplify things a lot. I'm also not sold on static typing for JS, as someone who really likes C#. I also think the use of classes in JS should generally be very limited.