Sorry I was trying to end on an ambiguous note because even if I am fairly content where I landed it feels not like it is a worthwhile distinction. This started in the article I mentioned in the introduction where it has become common to call the JS Framework React not reactive. And from every encompassing definition, I could find it was in fact reactive.
I was looking for some sort of commonality for why these things are called reactive programming. And while there is a lot of reactivity around especially in UX design, monitoring real-time systems, etc..., I wanted to focus on the programming paradigm. Unfortunately, it ended up being that the commonality still boiled down to something very generic. So much that even the first paper that coined the term wasn't any clearer.
I realize throwing that at the end only serves to muddle everything. I'm content enough with my definitions up to that point. It was just that it is likely some other definition exists that loosely fits. That paper considered reactive programming to be about a program that ran at the pace of the outside inputs rather than its internal environment. By that definition pretty much any browser UI programming driven off DOM events fits this.
I still like my definitions and differentiate reactive programming the paradigm, from reactive programs, or systems. But arguably a pretty arbitrary position to be taking.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sorry I was trying to end on an ambiguous note because even if I am fairly content where I landed it feels not like it is a worthwhile distinction. This started in the article I mentioned in the introduction where it has become common to call the JS Framework React not reactive. And from every encompassing definition, I could find it was in fact reactive.
I was looking for some sort of commonality for why these things are called reactive programming. And while there is a lot of reactivity around especially in UX design, monitoring real-time systems, etc..., I wanted to focus on the programming paradigm. Unfortunately, it ended up being that the commonality still boiled down to something very generic. So much that even the first paper that coined the term wasn't any clearer.
I realize throwing that at the end only serves to muddle everything. I'm content enough with my definitions up to that point. It was just that it is likely some other definition exists that loosely fits. That paper considered reactive programming to be about a program that ran at the pace of the outside inputs rather than its internal environment. By that definition pretty much any browser UI programming driven off DOM events fits this.
I still like my definitions and differentiate reactive programming the paradigm, from reactive programs, or systems. But arguably a pretty arbitrary position to be taking.