It's been around in various forms, and implemented on top of various languages, for quite some time.

The earliest full-fledged FRP implementation for JavaScript was Flapjax – work on it dates all the way back to 2006!

http://www.flapjax-lang.org/

The paper Flapjax: A Programming Language for Ajax Applications is worth reading.

http://cs.brown.edu/~sk/Publications/Papers/Published/mgbcgb...

The principal designer and maintainer of the Elm Language (a functional reactive lang that compiles to JS) did his Master's Thesis on FRP, and that's a great resource if you want the big picture:

https://www.seas.harvard.edu/sites/default/files/files/archi...

See also Controlling Time and Space: understanding the many formulations of FRP, by the same author:

https://www.youtube.com/watch?v=Agu6jipKfYw

If you ignore the whole thing about how frp is not FRP, and how javascript developers really only mean frp, then a good place to start would be learning about RxJS.

FRP is deterministic and referentially transparent, frp is not. Key concepts in FRP are behaviors, events, signals; key concepts in frp is streams, observables, subscriptions. Although I'm not expert with either, there's a lot of overlap and term overloading, and I might be explaining this all badly anyway.

AFAICT, the simplest way of explaining the difference between FRP and "popular frp" is that in FRP things are described as functions of time, whereas in popular frp they are streams of events.

The "real" FRP is great for describing non-interactive things. They can be used to describe anumations: e.g. a FRP behavior can describe the position of a ball as a function of time:

  ballPosition :: t -> Position

whereas in "quasi" frp, the ballPosition is a stream of Position values:

  ballPosition :: (Stream Position)

Basically, quasi FRP is what you get when you sample real FRP at certain times :)

A small part of it is that your events are basically constant streams of data (think arrays) you can map, reduce, and filter (among other functions) and then present. Here is a short article on it:

https://medium.com/@andrestaltz/2-minute-introduction-to-rx-...

This is a discussion over the controversy of calling stuff FRP in academia vs. real world:

https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-j...

It's a way to write applications as declarative code that defines the UI in terms of sequences of events and streams.

Basically: something incredibly powerful and clever that will not be adopted by the wider developer community until someone figures out how to present it in a way that makes it accessible to someone who isn't deeply interested in academia.

I don't think it's so much that it requires an interest in academia, but that it requires a shift in thinking towards abstractions that still aren't mainstream, relative to OOP (in its various forms) and unadorned events/listeners. Principally, that shift is toward higher-order functions. Yes, those same HOF abstractions are popular subjects for academic research and teaching, but they're not inherently academic subjects.

True, but this paradigm shift has been pending for nearly half a century and there doesn't seem to be any progress, just periodic rediscoveries.

A way to handle sequences of events - which is really powerful abstraction. Look at this (shameless self-promotion) presentation https://slides.com/bahmutov/javascript-journey-boston-code-c... and the companion blog post http://glebbahmutov.com/blog/journey-from-procedural-to-reac... plus repo of the code that shows every style of JS, including Redux and Reactive https://github.com/bahmutov/javascript-journey

> What is this FRP thing

https://en.wikipedia.org/wiki/Functional_reactive_programmin...