[discreteevent]

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.

[lhorie]

Sure there are those who get by w/ Google/StackOverflow/copy+paste (and hey, everyone has to start somewhere), but also remember that not everyone is a full stack dev. Lots of people make a living programming exclusively on the frontend.

There are also those that understand the concept of filtering at a basic level when reading tutorials about it, but still write for/if loops when it comes to producing actual code and it doesn't occur to them that it's possible to take the anonymous function out of the filter() call and give it a name to start building up a compositional foundation in their codebases.

My point though is that the benefits of FRP are somewhat out of line with the types of problems that people face in the real world.

[staltz]

I use a simple example of how Rx (not FRP, that's something completely different) benefits in programming: the traditional use case of analytics events is to spread Analytics.sendEvent() calls in many places of your codebase. Using Rx to solve this problem, things get inverted: you have all analytics events defined in one module, they are listening to events happening throughout the codebase. Sometimes the platform (mobile or whatnot, think beyond JS) provides convenient lifecycle events for this. In conclusion: the only place you see analytics events in your codebase is in the Analytics module.

To me, it's about separation of concerns most of the times, and about handy event operators sometimes (e.g. https://github.com/Reactive-Extensions/RxJS/blob/master/doc/...).