My recent article How React is not reactive, and why you shouldn't care opened up a much larger debate on the definition of reactive programming in...
For further actions, you may consider blocking this person and/or reporting abuse
The "should I say DCTP" sent me down a crazy rabbit hole
Hi Ryan, could you elaborate on what you meant by:
Have no idea about the streams statement, but isn't reactivity in general always about responding to asynchronous events, and updating data based on that async event?
Yes but some reactive systems are async in nature and others are not. Like RxJS/Observable streams view everything a sequence of values over time that go through transforms. An Observable is not defined by its value but rather is an event emitter, something that passes values through. They even have a notion of being done or completed.
Whereas like the Signals you find in Solid or Vue's Ref are a different sort of thing. They are the value. Their value might change over time but their identity is associated with that value and it is always accessible. There is always a current value. These systems aren't really concerned with time and only with everything being perfectly in sync, glitch-free. Ie.. when you update this Signal everything downstream immediately reflects that. These systems propagate change synchronously generally. They are never "done" because they aren't a sequence, they are the thing.
To be fair RxJS has a concept similar called BehaviorSubject. But I just wanted to point out that the Rx definition doesn't cover the whole landscape.
I've never had to delve into "reactive programming" or any such higher paradigms to describe a style or principle.... but the title caught my eye as to how I could understand this. I feel none-the-wiser alas, but here's what I'm getting out of it...
If I borrow clumisly a notation from logic/mathematics, I am seeing your statement as
That is, whatever
bandc, their processing engendersa. We could even claim them to be states. And then, the question is, what to do witha, how to respond, or react to it, when either component changes the value, or statea. Which dovetails neatly into the assertion, "(Real-time) programs are usually reactive", since we depend on knowing what happened toato further proceed...But then, I recently discovered the existence of "real time operating systems" and am confused as to the nature of those as opposed to more "usual" operating systems. What is meant by "real-time"?
I feel to a certain extent there is a problem of terminology - in the desire to re-use words for the benefit of succinctness (or marketability), the fast breakdown of analogy seems to just muddy the ability to understand what was actually meant.
So... what is reactive programming? I am still confused.
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.
I read somewhere that what distinguishes imperative and declarative programming is that imperative programming expresses relative truth, while declarative programming expresses the absolute truth, and that's what makes declarative programming much easier to reason about (for declarative use-cases).
Great article, thanks for sharing 👍🏻
Perhaps the distinction between Reactive Programming and Declarative is about rules for transformations to data, Reactive is about rules for transformations to state.
Yeah, I called out the relationship between values because that represents the potential for transformation. As soon as you derive a value or establish a data-driven side effect it's reactive. A declarative identity declaration is very much like a tree falling in the woods when no one is around.
I think the transformation often gets instantly pointed at the Rx meaning like operator transforms. But Signal based systems do transformations too they just aren't as in your face explicit. Back to my example.
arepresents the combining transformation of inputsbandc. So it still holds.Of course. I only mean to say that reactive programming extends declarative programming inasmuch that declarative programming doesn't necessarily deal with state.
How would you fit state charts/machines into this? On the basis that libraries like XState allow you to use transitions to regulate UI app states.
It's interesting. Because state machines/charts represent potential states, moments in time. They represent discrete snapshots (I realize charts can represent a range but it still holds as a specific moment in time). And then on event dispatch we transfer from one state to the next through a defined transformation.
So stepping back with a given sequence of state changes from inputs isn't unlike a coarse grain stream. You transform data through a series of inputs. The representation might differ but you are essentially driving defined paths through your state logic.
Each one feels like it could be seen as a reactive atom/primitive. It's the driving event system + the declarative representation that aligns. I can picture imperative systems with state machines I wouldn't call reactive, but I can also picture reactive systems living inside an otherwise non-reactive system and have the same categorization.
So it's more by the definition that when one calls a Promise a state machine. Reactive streams are similarly state machines. I'm not sure that signals are in that while they hold different values they generally only have a single observable state.
But this is my current thinking.
state machines by themselves have nothing to do with reactivity. They defines how a group of pure states (as plain objects) would change under different function calls.
Only after plugging in with things like xstate-react or xstate-vue etc. then they have ability of "change propagation". Changes of these states automatically causing outer things to run (effect functions, or the whole render function). Now they become the starting point of a reactive system as a whole.
Such are pure functions. Then a reactive system is one that given a user-specified pure function from model to view automatically handles translating changes in the model into changes in the view.