Developers handbook to Reactive Programming
First, what is Reactive? At least these 3 things:
Since you’re here you’re probably interested in the third item. So, what is Reactive Programming? Depending on who you ask it can be:
<your language of choice here> collection API, but for asynchronous streamsIn this blog I will try to give you some background on the different kinds of Reactive Programming, and provide you with samples to understand the concept and the use cases for each of the above kinds of Reactive Programming. You can read this as a whole, or jump straight to the specific section you’re interested in. My favorite kind is Reactive Extensions - the best tool in my programming toolbox - so if you are looking for my recommendation, read that section.
Very different things are called reactive programming nowadays, but they do share some ideas. When your write your programs to be reactive you program what will happen when new input arrives at your program. Your program could be anything from a small web application, to a Slack bot, or the next big cloud platform. The input can be generated by users, for example mouse clicks in the browser, or some external program, like Slack or other microservices in a cloud architecture.
Input => [ Your program ] => Output
Key to reactive programming is that all that input might not come at once, but rather over time and that you are expected to respond quickly to this input when it finally comes. Consider mouse clicks: the user first needs to click before you can handle that event, and then expects the UI to update quickly.
While you could handle the use cases for reactive programming in other ways like with callbacks or promises, the different kinds of reactive programming all try to make your life as a developer easier, with features that require you to write less code and/or more comprehensible code than what would otherwise be required.
At least in terms of computer science the term reactive programming has been around for a very long time: since the 1980s. Gérard Berry and his team created Esterel, and wrote what he thinks a reactive program is:
Reactive programs continuously interact with their environment, at a speed determined by the environment instead of the program itself.
- Gérard Berry, 1989
Berry noted that then existing General Purpose Languages (GPL’s) alone were not suitable for those systems, and that development could benefit from better abstractions and primitives available in Special Purpose Languages, like Esterel. He argues for synchronity as it allows focussing on the logic of reactions, instead of dealing with the problems that arise with asynchronity. Synchronity makes deterministic and concurrent programs possible and causes performance to be predictable, which is necessary for real time systems. He concludes that GPL’s and SPL’s respective advantages are complementary and can be combined in larger systems.
Since then lots of research has been done in the academic world until at some point several implementations arose that became very popular outside academia. Examples are Flapjax (JavaScript), Elm, Reactive Extensions (or Rx.NET) and more recently RxJava. Then the web community took off with the term “reactive” and frameworks like Meteor, React, Vue and Angular where created.